RFR 8193255: Root Certificates should be stored in text format and assembled at build time

Weijun Wang weijun.wang at oracle.com
Fri May 31 03:00:36 UTC 2019


New webrev at

   https://cr.openjdk.java.net/~weijun/8193255/webrev.01

Changes:

1. Textual info at the beginning of each cert

2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir

Thanks,
Max

> On May 31, 2019, at 1:34 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> On 2019-05-30 08:32, Weijun Wang wrote:
>> 
>>> On May 30, 2019, at 10:01 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> 
>>> In my experience, using directories for dependencies in make does not work well. Since all the files in make/data/cacerts are in a flat structure, I would recommend expressing the prerequisites as:
>>> 
>>> $(wildcard $(GENDATA_CACERTS_SRC)/*)
>>> 
>>> This will not cover the case where a file is removed, but that case is rarely handled well in make based build systems.
>> But in my experiment, using the directory name does detect the file removal.
> 
> It believe that worked well on your machine, but directory timestamp updates are file system dependent. I'm not sure we can count on all filesystems to accurately reflect time stamps based on file modification. It's also possible that an OS would touch directory timestamps for other reasons, which should not affect the build. I haven't tried having source directories as prerequisites before, so I simply don't know how reliable it is. My experience is rather with directories as targets, which certainly doesn't work. If you verified that it worked as expected on all supported OSes, I would be less worried.
> 
>> Or, can I list *both* the files and the directory to get maximum awareness?
> 
> The directory modification time will usually not change when a file in it is modified, only when adding or removing files (and possibly some other operations), so adding the files is certainly a must. If you go with both, then I would just be worried about potential false positives.
> 
> /Erik
> 




More information about the security-dev mailing list