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