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

Sean Mullan sean.mullan at oracle.com
Wed Jun 12 20:15:23 UTC 2019


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



More information about the security-dev mailing list