Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Sean Mullan]

On 6/14/19 11:33 AM, Weijun Wang wrote:

Here is the updated webrev

   http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.


Looks fine.

--Sean



Thanks,
Max


On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?


Yes, I think that is useful.

--Sean

Re: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts file

[Erik Joelsson]

I'm happy with this.

/Erik

On 2019-06-14 08:33, Weijun Wang wrote:

Here is the updated webrev

   http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.

Thanks,
Max


On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?

Yes, I think that is useful.

--Sean

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

[Weijun Wang]

Here is the updated webrev

  http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.

Thanks,
Max

> On Jun 14, 2019, at 7:55 PM, Sean Mullan  wrote:
> 
> On 6/14/19 1:49 AM, Weijun Wang wrote:
>> BTW, something not related but similar: Do you like me to also sort aliases 
>> alphabetically in the output of "keytool -list"?
> 
> Yes, I think that is useful.
> 
> --Sean

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

[Sean Mullan]

On 6/14/19 1:49 AM, Weijun Wang wrote:

BTW, something not related but similar: Do you like me to also sort aliases 
alphabetically in the output of "keytool -list"?


Yes, I think that is useful.

--Sean

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

[Weijun Wang]

> On Jun 14, 2019, at 5:00 AM, Sean Mullan  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  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  
 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  
> wrote:
> 
> Good idea about the creation time.
> 
> --Max
> 
>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz  
>> 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 
>>  wrote:
>> Since JDK-8193255, when we started generating the cacerts file in the
>> 

Re: 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  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  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  wrote:

Good idea about the creation time.

--Max


On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  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

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

[Weijun Wang]

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  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  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  
>>> wrote:
>>> 
>>> Good idea about the creation time.
>>> 
>>> --Max
>>> 
 On Jun 12, 2019, at 10:53 AM, Martin Buchholz  
 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 
  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
 

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

[Weijun Wang]

> On Jun 13, 2019, at 12:16 AM, Martin Buchholz  wrote:
> 
> I'm not a security engineer, but:
> - consider creating static finals for e.g. "Mighty Aphrodite" just to give it 
> a symbolic name.

That method is copied from JavaKeyStore.java. Keeping it 100% unchanged gives 
me more confidence I'm write the file correctly.

> - VerifyCACerts probably fails when the jdk is configured with a different 
> cacerts file (but the JDK doesn't preserve configuration information - how 
> could one fix it?)
> Many downstream organizations will configure a different cacerts.

I don't have a solution. Maybe in your repo you can @ignore this test.

Thanks,
Max

> 
> On Wed, Jun 12, 2019 at 8:42 AM 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  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  wrote:
> >> 
> >> Good idea about the creation time.
> >> 
> >> --Max
> >> 
> >>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  
> >>> 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
> >>> 
> >> 
> > 
> 

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

[Weijun Wang]

I plan to fix it in JDK 13. --Max

> On Jun 13, 2019, at 12:38 AM, 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

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

[Erik Joelsson]

Hello,

We cannot rely on querying mercurial at build time. The source must be 
buildable from a source distribution.


/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  
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  
wrote:


Good idea about the creation time.

--Max

On Jun 12, 2019, at 10:53 AM, Martin Buchholz 
 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 
 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

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

[Sean Mullan]

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


Good idea about the creation time.

--Max

On Jun 12, 2019, at 10:53 AM, Martin Buchholz  
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 
 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

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

[Erik Joelsson]

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

Good idea about the creation time.

--Max


On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  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

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

[Martin Buchholz]

I'm not a security engineer, but:
- consider creating static finals for e.g. "Mighty Aphrodite" just to give
it a symbolic name.
- VerifyCACerts probably fails when the jdk is configured with a different
cacerts file (but the JDK doesn't preserve configuration information - how
could one fix it?)
Many downstream organizations will configure a different cacerts.

On Wed, Jun 12, 2019 at 8:42 AM 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 
> 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 
> wrote:
> >>
> >> Good idea about the creation time.
> >>
> >> --Max
> >>
> >>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz 
> 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
> >>>
> >>
> >
>
>

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

[Weijun Wang]

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  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  wrote:
>> 
>> Good idea about the creation time.
>> 
>> --Max
>> 
>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  
>>> 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
>>> 
>> 
> 

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

[Weijun Wang]

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  wrote:
> 
> Good idea about the creation time.
> 
> --Max
> 
>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  
>> 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
>> 
> 

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

[Weijun Wang]

Good idea about the creation time.

--Max

> On Jun 12, 2019, at 10:53 AM, Martin Buchholz  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  
> 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
> 

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

[David Holmes]

Hi Erik,

On 12/06/2019 12:48 am, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02

Filtering out the date and adding a sort. All my builds yesterday 
resulted in cacerts files with the same order of the keys, but today the 
order changed. Looking through the source (JavaKeyStore.engineStore()), 
the store method just iterates over the keys of a Hashtable, so the 
order is indeed random. I think it would be a good idea to add a sort 
there to make our tools better at reproducible output.


Seems quite reasonable.

Thanks,
David

I also fixed a bug in compare.sh which prevented me from running a 
compare of just the cacerts files using the filter functionality.


/Erik

On 2019-06-10 19:17, David Holmes wrote:

On 11/06/2019 12:11 pm, Oracle wrote:

But you should see the date on the same line as the alias and the type.


Ah I see. I was looking at the output from an old version of cacerts 
that shows things like:


verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, 
so can't say if this is an issue.


Thanks,
David


—Max

获取 Outlook for iOS 



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
mailto:david.hol...@oracle.com>> wrote:


    Hi Max,

    On 11/06/2019 11:05 am, Weijun Wang wrote:
    > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
"Creation date"

    >     > would exclude the date (which has its own line).

    I don't see any "Creation Date" entry when I run the tool:

  > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/support/interim-image/lib/security/cacerts
    -storepass changeit | grep Creat
  >

    It only appears with the -rfc option which Erik hasn't used.

    David
    -

    > --Max
    >     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
The "keytool -list" output contains a creation data (I

    know it's useless now), so if THIS_FILE and THAT_FILE happen to be
    created on different dates then you will see difference. >> >> --Max
 >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
 >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
  On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
    a reasonable approach.  > Bug:
    https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
    http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
    changes seem fine. >>> Thanks!  I'm assuming this formulation
    doesn't run into the:   Warning: use -cacerts option to
    access cacerts keystore   that you get if you actually point
    keytool to the cacerts files in the JDK image:  >
    ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
    build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
    changeit > certs.1  Warning: use -cacerts option to access
    cacerts keystore  >>> I did not see that. I would guess it's
    because I'm not running keytool from the images/jdk/bin dir, but in
    most cases from the jdk/bin dir (the exploded image), or in the
    cross compilation case, it's running from the buildjdk. I just tried
    it manually, and it seems the warning is only printed if trying to
    list the cacerts file from the same image. >>> >>> /Erik >>> 
    Thanks,  David  -  > /Erik > >> >

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

[Erik Joelsson]

On 2019-06-11 07:53, Weijun Wang wrote:

In JKS the certs are stored in a Hashtable so there is no defined order. If we 
migrate it to another store type (we are planning for it) there can be another 
order. Maybe this won;t be an issue, the order is at least not random.


Hm, I thought the Hashtable would be random, but perhaps it stable as 
long as elements the elements are added in a stable order? In that case, 
then adding a sort when reading the files in the build tool would be 
enough to guarantee a stable order.


Note that it's OK for the order to change with future changes to the 
implementation. What we like to avoid is just different output from the 
same sources.



Or maybe I can update keytool to always list the entries in alphabetical order.


That would be appreciated. From a build point of view, we like to 
minimize any randomness in the build results.


/Erik


--Max


On Jun 11, 2019, at 10:06 PM, Erik Joelsson  wrote:

Thanks Max, I will incorporate that.

Removing the date will make the comparison more flexible for sure. Most of the 
time, both builds are generated on the same day, but if a build happens to run 
across midnight (which may more common than one thinks considering that many 
build machines are in UTC and I'm working in PT), this could certainly become 
an issue. Another common use case for me is creating a baseline build, then 
working on a fix over a few days, comparing to the same baseline.

/Erik

On 2019-06-10 19:17, David Holmes wrote:

On 11/06/2019 12:11 pm, Oracle wrote:

But you should see the date on the same line as the alias and the type.

Ah I see. I was looking at the output from an old version of cacerts that shows 
things like:

verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, so can't 
say if this is an issue.

Thanks,
David


—Max

获取 Outlook for iOS 



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" mailto:david.hol...@oracle.com>> wrote:

 Hi Max,

 On 11/06/2019 11:05 am, Weijun Wang wrote:
 > keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation 
date"
 > > would exclude the date (which has its own line).

 I don't see any "Creation Date" entry when I run the tool:

   > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/support/interim-image/lib/security/cacerts
 -storepass changeit | grep Creat
   >

 It only appears with the -rfc option which Erik hasn't used.

 David
 -

 > --Max
 > >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The "keytool 
-list" output contains a creation data (I
 know it's useless now), so if THIS_FILE and THAT_FILE happen to be
 created on different dates then you will see difference. >> >> --Max
  >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
  >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
   On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
 a reasonable approach.  > Bug:
 https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
 http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
 changes seem fine. >>> Thanks!  I'm assuming this formulation
 doesn't run into the:   Warning: use -cacerts option to
 access cacerts keystore   that you get if you actually point
 keytool to the cacerts files in the JDK image:  >
 ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
 build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
 changeit > certs.1  Warning: use -cacerts option to access
 cacerts keystore  >>> I did not see that. I would guess it's
 because I'm not running keytool from the images/jdk/bin dir, but in
 most cases from the jdk/bin dir (the exploded image), or in the
 cross compilation case, it's running from the buildjdk. I just tried
 it manually, and it seems the warning is only printed if trying to
 list the cacerts file from the same image. >>> >>> /Erik >>> 
 Thanks,  David  -  > /Erik > >> >

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

[Weijun Wang]

In JKS the certs are stored in a Hashtable so there is no defined order. If we 
migrate it to another store type (we are planning for it) there can be another 
order. Maybe this won;t be an issue, the order is at least not random.

Or maybe I can update keytool to always list the entries in alphabetical order.

--Max

> On Jun 11, 2019, at 10:06 PM, Erik Joelsson  wrote:
> 
> Thanks Max, I will incorporate that.
> 
> Removing the date will make the comparison more flexible for sure. Most of 
> the time, both builds are generated on the same day, but if a build happens 
> to run across midnight (which may more common than one thinks considering 
> that many build machines are in UTC and I'm working in PT), this could 
> certainly become an issue. Another common use case for me is creating a 
> baseline build, then working on a fix over a few days, comparing to the same 
> baseline.
> 
> /Erik
> 
> On 2019-06-10 19:17, David Holmes wrote:
>> On 11/06/2019 12:11 pm, Oracle wrote:
>>> But you should see the date on the same line as the alias and the type.
>> 
>> Ah I see. I was looking at the output from an old version of cacerts that 
>> shows things like:
>> 
>> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>> 
>> but now all those old dates are the current build date:
>> 
>> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>> 
>> I'm not sure exactly what gets compared with these comparison builds, so 
>> can't say if this is an issue.
>> 
>> Thanks,
>> David
>> 
>>> —Max
>>> 
>>> 获取 Outlook for iOS 
>>> 
>>> 
>>> 
>>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
>>> mailto:david.hol...@oracle.com>> wrote:
>>> 
>>> Hi Max,
>>> 
>>> On 11/06/2019 11:05 am, Weijun Wang wrote:
>>> > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
>>> "Creation date"
>>> > > would exclude the date (which has its own line).
>>> 
>>> I don't see any "Creation Date" entry when I run the tool:
>>> 
>>>   > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>>> -storepass changeit | grep Creat
>>>   >
>>> 
>>> It only appears with the -rfc option which Erik hasn't used.
>>> 
>>> David
>>> -
>>> 
>>> > --Max
>>> > >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The 
>>> "keytool -list" output contains a creation data (I
>>> know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>>> created on different dates then you will see difference. >> >> --Max
>>>  >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>>>  >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
>>>   On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
>>> a reasonable approach.  > Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
>>> http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
>>> changes seem fine. >>> Thanks!  I'm assuming this formulation
>>> doesn't run into the:   Warning: use -cacerts option to
>>> access cacerts keystore   that you get if you actually point
>>> keytool to the cacerts files in the JDK image:  >
>>> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>> build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>>> changeit > certs.1  Warning: use -cacerts option to access
>>> cacerts keystore  >>> I did not see that. I would guess it's
>>> because I'm not running keytool from the images/jdk/bin dir, but in
>>> most cases from the jdk/bin dir (the exploded image), or in the
>>> cross compilation case, it's running from the buildjdk. I just tried
>>> it manually, and it seems the warning is only printed if trying to
>>> list the cacerts file from the same image. >>> >>> /Erik >>> 
>>> Thanks,  David  -  > /Erik > >> >
>>> 

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

[Erik Joelsson]

New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02

Filtering out the date and adding a sort. All my builds yesterday 
resulted in cacerts files with the same order of the keys, but today the 
order changed. Looking through the source (JavaKeyStore.engineStore()), 
the store method just iterates over the keys of a Hashtable, so the 
order is indeed random. I think it would be a good idea to add a sort 
there to make our tools better at reproducible output.


I also fixed a bug in compare.sh which prevented me from running a 
compare of just the cacerts files using the filter functionality.


/Erik

On 2019-06-10 19:17, David Holmes wrote:

On 11/06/2019 12:11 pm, Oracle wrote:

But you should see the date on the same line as the alias and the type.


Ah I see. I was looking at the output from an old version of cacerts 
that shows things like:


verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, 
so can't say if this is an issue.


Thanks,
David


—Max

获取 Outlook for iOS 



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
mailto:david.hol...@oracle.com>> wrote:


    Hi Max,

    On 11/06/2019 11:05 am, Weijun Wang wrote:
    > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
"Creation date"

    >     > would exclude the date (which has its own line).

    I don't see any "Creation Date" entry when I run the tool:

  > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/support/interim-image/lib/security/cacerts
    -storepass changeit | grep Creat
  >

    It only appears with the -rfc option which Erik hasn't used.

    David
    -

    > --Max
    >     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
The "keytool -list" output contains a creation data (I

    know it's useless now), so if THIS_FILE and THAT_FILE happen to be
    created on different dates then you will see difference. >> >> --Max
 >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
 >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
  On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
    a reasonable approach.  > Bug:
    https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
    http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
    changes seem fine. >>> Thanks!  I'm assuming this formulation
    doesn't run into the:   Warning: use -cacerts option to
    access cacerts keystore   that you get if you actually point
    keytool to the cacerts files in the JDK image:  >
    ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
    build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
    changeit > certs.1  Warning: use -cacerts option to access
    cacerts keystore  >>> I did not see that. I would guess it's
    because I'm not running keytool from the images/jdk/bin dir, but in
    most cases from the jdk/bin dir (the exploded image), or in the
    cross compilation case, it's running from the buildjdk. I just tried
    it manually, and it seems the warning is only printed if trying to
    list the cacerts file from the same image. >>> >>> /Erik >>> 
    Thanks,  David  -  > /Erik > >> >

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

[Erik Joelsson]

Thanks Max, I will incorporate that.

Removing the date will make the comparison more flexible for sure. Most 
of the time, both builds are generated on the same day, but if a build 
happens to run across midnight (which may more common than one thinks 
considering that many build machines are in UTC and I'm working in PT), 
this could certainly become an issue. Another common use case for me is 
creating a baseline build, then working on a fix over a few days, 
comparing to the same baseline.


/Erik

On 2019-06-10 19:17, David Holmes wrote:

On 11/06/2019 12:11 pm, Oracle wrote:

But you should see the date on the same line as the alias and the type.


Ah I see. I was looking at the output from an old version of cacerts 
that shows things like:


verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, 
so can't say if this is an issue.


Thanks,
David


—Max

获取 Outlook for iOS 



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
mailto:david.hol...@oracle.com>> wrote:


    Hi Max,

    On 11/06/2019 11:05 am, Weijun Wang wrote:
    > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
"Creation date"

    >     > would exclude the date (which has its own line).

    I don't see any "Creation Date" entry when I run the tool:

  > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/support/interim-image/lib/security/cacerts
    -storepass changeit | grep Creat
  >

    It only appears with the -rfc option which Erik hasn't used.

    David
    -

    > --Max
    >     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
The "keytool -list" output contains a creation data (I

    know it's useless now), so if THIS_FILE and THAT_FILE happen to be
    created on different dates then you will see difference. >> >> --Max
 >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
 >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
  On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
    a reasonable approach.  > Bug:
    https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
    http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
    changes seem fine. >>> Thanks!  I'm assuming this formulation
    doesn't run into the:   Warning: use -cacerts option to
    access cacerts keystore   that you get if you actually point
    keytool to the cacerts files in the JDK image:  >
    ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
    build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
    changeit > certs.1  Warning: use -cacerts option to access
    cacerts keystore  >>> I did not see that. I would guess it's
    because I'm not running keytool from the images/jdk/bin dir, but in
    most cases from the jdk/bin dir (the exploded image), or in the
    cross compilation case, it's running from the buildjdk. I just tried
    it manually, and it seems the warning is only printed if trying to
    list the cacerts file from the same image. >>> >>> /Erik >>> 
    Thanks,  David  -  > /Erik > >> >

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

[David Holmes]

On 11/06/2019 12:11 pm, Oracle wrote:

But you should see the date on the same line as the alias and the type.


Ah I see. I was looking at the output from an old version of cacerts 
that shows things like:


verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, so 
can't say if this is an issue.


Thanks,
David


—Max

获取 Outlook for iOS 



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
mailto:david.hol...@oracle.com>> wrote:


Hi Max,

On 11/06/2019 11:05 am, Weijun Wang wrote:
> keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation 
date"
> 
> would exclude the date (which has its own line).


I don't see any "Creation Date" entry when I run the tool:

  > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/support/interim-image/lib/security/cacerts
-storepass changeit | grep Creat
  >

It only appears with the -rfc option which Erik hasn't used.

David
-

> --Max
> 
>> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The "keytool -list" output contains a creation data (I

know it's useless now), so if THIS_FILE and THAT_FILE happen to be
created on different dates then you will see difference. >> >> --Max
 >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
 >>> On 2019-06-10 16:23, David Holmes wrote:  Hi Erik, 
  On 11/06/2019 5:37 am, Erik Joelsson 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.   Seems
a reasonable approach.  > Bug:
https://bugs.openjdk.java.net/browse/JDK-8225392 > > Webrev:
http://cr.openjdk.java.net/~erikj/8225392/webrev.01/   Code
changes seem fine. >>> Thanks!  I'm assuming this formulation
doesn't run into the:   Warning: use -cacerts option to
access cacerts keystore   that you get if you actually point
keytool to the cacerts files in the JDK image:  >
./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
changeit > certs.1  Warning: use -cacerts option to access
cacerts keystore  >>> I did not see that. I would guess it's
because I'm not running keytool from the images/jdk/bin dir, but in
most cases from the jdk/bin dir (the exploded image), or in the
cross compilation case, it's running from the buildjdk. I just tried
it manually, and it seems the warning is only printed if trying to
list the cacerts file from the same image. >>> >>> /Erik >>> 
Thanks,  David  -  > /Erik > >> >

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

[Oracle]

But you should see the date on the same line as the alias and the type. 
—Max


获取 Outlook for iOS

  



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
 wrote:










Hi Max,

On 11/06/2019 11:05 am, Weijun Wang wrote:
> keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
> 
> would exclude the date (which has its own line).

I don't see any "Creation Date" entry when I run the tool:

 > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/support/interim-image/lib/security/cacerts 
-storepass changeit | grep Creat
 >

It only appears with the -rfc option which Erik hasn't used.

David
-

> --Max
> 
>> On Jun 11, 2019, at 8:39 AM, Weijun Wang  wrote:
>>
>> The "keytool -list" output contains a creation data (I know it's useless 
>> now), so if THIS_FILE and THAT_FILE happen to be created on different dates 
>> then you will see difference.
>>
>> --Max
>>
>>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson  wrote:
>>>
>>>
>>> On 2019-06-10 16:23, David Holmes wrote:
 Hi Erik,

 On 11/06/2019 5:37 am, Erik Joelsson 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.

 Seems a reasonable approach.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>
> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/

 Code changes seem fine.
>>> Thanks!
 I'm assuming this formulation doesn't run into the:

 Warning: use -cacerts option to access cacerts keystore

 that you get if you actually point keytool to the cacerts files in the JDK 
 image:

> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
> build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit 
> > certs.1
 Warning: use -cacerts option to access cacerts keystore

>>> I did not see that. I would guess it's because I'm not running keytool from 
>>> the images/jdk/bin dir, but in most cases from the jdk/bin dir (the 
>>> exploded image), or in the cross compilation case, it's running from the 
>>> buildjdk. I just tried it manually, and it seems the warning is only 
>>> printed if trying to list the cacerts file from the same image.
>>>
>>> /Erik
>>>
 Thanks,
 David
 -

> /Erik
>
>>
> 

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

[David Holmes]

Hi Max,

On 11/06/2019 11:05 am, Weijun Wang wrote:

keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"

would exclude the date (which has its own line).


I don't see any "Creation Date" entry when I run the tool:

> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/support/interim-image/lib/security/cacerts 
-storepass changeit | grep Creat

>

It only appears with the -rfc option which Erik hasn't used.

David
-


--Max


On Jun 11, 2019, at 8:39 AM, Weijun Wang  wrote:

The "keytool -list" output contains a creation data (I know it's useless now), 
so if THIS_FILE and THAT_FILE happen to be created on different dates then you will see 
difference.

--Max


On Jun 11, 2019, at 7:37 AM, Erik Joelsson  wrote:


On 2019-06-10 16:23, David Holmes wrote:

Hi Erik,

On 11/06/2019 5:37 am, Erik Joelsson 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.


Seems a reasonable approach.


Bug: https://bugs.openjdk.java.net/browse/JDK-8225392

Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/


Code changes seem fine.

Thanks!

I'm assuming this formulation doesn't run into the:

Warning: use -cacerts option to access cacerts keystore

that you get if you actually point keytool to the cacerts files in the JDK 
image:


./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit > 
certs.1

Warning: use -cacerts option to access cacerts keystore


I did not see that. I would guess it's because I'm not running keytool from the 
images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded 
image), or in the cross compilation case, it's running from the buildjdk. I 
just tried it manually, and it seems the warning is only printed if trying to 
list the cacerts file from the same image.

/Erik


Thanks,
David
-


/Erik

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

[Weijun Wang]

keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"

would exclude the date (which has its own line).

--Max

> On Jun 11, 2019, at 8:39 AM, Weijun Wang  wrote:
> 
> The "keytool -list" output contains a creation data (I know it's useless 
> now), so if THIS_FILE and THAT_FILE happen to be created on different dates 
> then you will see difference.
> 
> --Max
> 
>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson  wrote:
>> 
>> 
>> On 2019-06-10 16:23, David Holmes wrote:
>>> Hi Erik,
>>> 
>>> On 11/06/2019 5:37 am, Erik Joelsson 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.
>>> 
>>> Seems a reasonable approach.
>>> 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
 
 Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>> 
>>> Code changes seem fine.
>> Thanks!
>>> I'm assuming this formulation doesn't run into the:
>>> 
>>> Warning: use -cacerts option to access cacerts keystore
>>> 
>>> that you get if you actually point keytool to the cacerts files in the JDK 
>>> image:
>>> 
 ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
 build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit 
 > certs.1
>>> Warning: use -cacerts option to access cacerts keystore
>>> 
>> I did not see that. I would guess it's because I'm not running keytool from 
>> the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded 
>> image), or in the cross compilation case, it's running from the buildjdk. I 
>> just tried it manually, and it seems the warning is only printed if trying 
>> to list the cacerts file from the same image.
>> 
>> /Erik
>> 
>>> Thanks,
>>> David
>>> -
>>> 
 /Erik
 
> 

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

[Weijun Wang]

The "keytool -list" output contains a creation data (I know it's useless now), 
so if THIS_FILE and THAT_FILE happen to be created on different dates then you 
will see difference.

--Max

> On Jun 11, 2019, at 7:37 AM, Erik Joelsson  wrote:
> 
> 
> On 2019-06-10 16:23, David Holmes wrote:
>> Hi Erik,
>> 
>> On 11/06/2019 5:37 am, Erik Joelsson 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.
>> 
>> Seems a reasonable approach.
>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>> 
>> Code changes seem fine.
> Thanks!
>> I'm assuming this formulation doesn't run into the:
>> 
>> Warning: use -cacerts option to access cacerts keystore
>> 
>> that you get if you actually point keytool to the cacerts files in the JDK 
>> image:
>> 
>> > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
>> > build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit 
>> > > certs.1
>> Warning: use -cacerts option to access cacerts keystore
>> 
> I did not see that. I would guess it's because I'm not running keytool from 
> the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded 
> image), or in the cross compilation case, it's running from the buildjdk. I 
> just tried it manually, and it seems the warning is only printed if trying to 
> list the cacerts file from the same image.
> 
> /Erik
> 
>> Thanks,
>> David
>> -
>> 
>>> /Erik
>>> 

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

[Erik Joelsson]

On 2019-06-10 16:23, David Holmes wrote:

Hi Erik,

On 11/06/2019 5:37 am, Erik Joelsson 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.


Seems a reasonable approach.


Bug: https://bugs.openjdk.java.net/browse/JDK-8225392

Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/


Code changes seem fine.

Thanks!

I'm assuming this formulation doesn't run into the:

Warning: use -cacerts option to access cacerts keystore

that you get if you actually point keytool to the cacerts files in the 
JDK image:


> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass 
changeit > certs.1

Warning: use -cacerts option to access cacerts keystore

I did not see that. I would guess it's because I'm not running keytool 
from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the 
exploded image), or in the cross compilation case, it's running from the 
buildjdk. I just tried it manually, and it seems the warning is only 
printed if trying to list the cacerts file from the same image.


/Erik


Thanks,
David
-


/Erik

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

[David Holmes]

Hi Erik,

On 11/06/2019 5:37 am, Erik Joelsson 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.


Seems a reasonable approach.


Bug: https://bugs.openjdk.java.net/browse/JDK-8225392

Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/


Code changes seem fine. I'm assuming this formulation doesn't run into the:

Warning: use -cacerts option to access cacerts keystore

that you get if you actually point keytool to the cacerts files in the 
JDK image:


> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass 
changeit > certs.1

Warning: use -cacerts option to access cacerts keystore

Thanks,
David
-


/Erik

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

[Erik Joelsson]

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