Hi Sean, The previous fix for JDK-8193255 already made the creation date useless. Before that, each time cacerts was regenerated the date changed. I compared cacerts of different releases and the same cert have difference creation dates.
The only other solution I can think of is to look at make/autoconf/version-numbers and use the DEFAULT_VERSION_DATE=2019-09-17 there. Have you reviewed the code changes? You can see I stored the hash of the whole file into the test. This means anyone updating the CA certs will have to create cacerts and calculate the correct hash and update this test. I suppose this won't be a hassle. Thanks, Max > On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > On 6/12/19 4:01 PM, Erik Joelsson wrote: >> Hello, >> We cannot rely on querying mercurial at build time. The source must be >> buildable from a source distribution. > > I had a feeling it wouldn't work but thought I would ask anyway. > > Well, offhand I can't think of any better solution than notBefore then, > unless we included it as a comment in the PEM file, and then extracted it. > With notBefore, someone might be curious about why some keystore entries were > created so long ago (ex: the earliest notBefore date is 1996). But the > creationDate doesn't really have any usefulness for cacerts, so it's probably > ok. > > --Sean > >> /Erik >> On 2019-06-12 11:39, Sean Mullan wrote: >>> Using the certificate's notBefore date as the KeyStore entry creation date >>> is misleading since many of these root certs were not integrated into the >>> JDK until after they were created by the CA. Can we somehow extract the >>> last revision time of each PEM file instead? That is more aligned with the >>> previous creation date that we used. >>> >>> --Sean >>> >>> On 6/12/19 12:38 PM, Erik Joelsson wrote: >>>> Hello Max, >>>> >>>> Much appreciated! I will need to have this fixed one way or other in JDK >>>> 13, so depending on if you get your fix there in time, I will retract my >>>> proposal. If your fix only hits 14, I will push mine to 13. >>>> >>>> /Erik >>>> >>>> On 2019-06-12 08:41, Weijun Wang wrote: >>>>> This is my version of the fix: >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8225392/webrev.00/ >>>>> >>>>> Now you can still compare cacerts bit by bit. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.w...@oracle.com> wrote: >>>>>> >>>>>> Hi Erik, >>>>>> >>>>>> Are you going to fix this bug soon? >>>>>> >>>>>> I am inspired by Martin's words and would like to update >>>>>> GenerateCacerts.java so that as long as the certs and their aliases are >>>>>> unchanged, the output cacerts will always be the same. I can send out a >>>>>> code review today. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.w...@oracle.com> >>>>>>> wrote: >>>>>>> >>>>>>> Good idea about the creation time. >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <marti...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Google culture really likes build output determinism, and we recently >>>>>>>> built our own cacerts generator. >>>>>>>> >>>>>>>> To get determinism, we are using cert digest as alias (must have a >>>>>>>> unique alias, but value doesn't seem to matter much), and using cert >>>>>>>> notBefore instead of current (build) timestamp. >>>>>>>> >>>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson >>>>>>>> <erik.joels...@oracle.com> wrote: >>>>>>>> Since JDK-8193255, when we started generating the cacerts file in the >>>>>>>> build, the build compare baseline builds have started failing. It seems >>>>>>>> the cacerts binary file has some non determinism built in so it doesn't >>>>>>>> get generated exactly the same given the same input. This patch adds >>>>>>>> special handling when comparing that file by comparing the output of >>>>>>>> "keytool -list" on the files instead. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>>>>>> >>>>>>>> /Erik >>>>>>>>
