> On Jun 14, 2019, at 5:00 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
>
> 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.
I'll use notBefore, it does not change forever.
>
>> 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?
I just want extra assurance that the output is indeed consistent.
>
> 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.
I can hack only 3 lines of JavaKeyStore.java itself and generate the identical
cacerts. Therefore it should be a genuine JKS file.
BTW, something not related but similar: Do you like me to also sort aliases
alphabetically in the output of "keytool -list"?
Thanks,
Max
>
> --Sean
>
>> 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
>>>>>>>>>>
