RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Sean Mullan]

On 6/12/19 9:52 PM, Weijun Wang wrote:
> 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.

Yes, a possibility, use the GA release date, which maybe "makes more 
sense" as a creation date, although a bit odd to have creation dates in 
the future before GA.

I'll leave it up to you. I think nobody really looks at the creationDate.

> 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.

Not really, since you had to update VerifyCACerts anyway whenever a 
change to cacerts was made, but what's the benefit of the hash? Are you 
worried the cacerts binary will be corrupted somehow, or you just want 
extra assurance something didn't go wrong?

It might be useful to run older versions of keytool against the cacerts 
binary you created - this would give you more assurance that your 
hand-coded format is correct. I would also try various commands, etc.

--Sean

> 
> Thanks,
> Max
> 
>> On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mullan at 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.wang at 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.wang at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Good idea about the creation time.
>>>>>>>>
>>>>>>>> --Max
>>>>>>>>
>>>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at 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.joelsson at 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
>>>>>>>>>
>