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 6722928: Support SSPI as a native GSS-API provider

[Weijun Wang]

Oops, I almost wanted to push my changeset yesterday and saw your mail.

Non of your comment are showstoppers. I'd like to push my current change and 
file a follow on bug on them.

And DLLs have been in bin all the time.

Thanks,
Max

> On Jun 11, 2019, at 7:56 AM, Nico Williams  wrote:
> 
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>> 
>>   http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
> 
> - 
> src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
> 
>   Ugh, I never noticed GSSUtil.useMSInterop().  This really should not
>   be needed.  I believe a proper implementation of RFC4178 wouldn't
>   need it.
> 
>   I can't expect you to do that, but can we have a bug opened for this?
> 
> - 
> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
> 
>   Shouldn't the sspi_bridge.dll be in the lib directory?
> 
> - src/java.security.jgss/share/native/libj2gss/NativeFunc.h
> - src/java.security.jgss/share/native/libj2gss/gssapi.h
> 
>   These continue to have improper constification.
> 
>   There should be no function arguments of type "const gss_...".
> 
>   I've a PR for Heimdal to fix this in Heimdal.  It was very
>   mechanical: search the prototypes and function definitions for
> 
>   \ 
>   then change that to gss_const_... then fix all the warnings and
>   errors that came up when building the result.
> 
> - All remaining commentary will be about
>   src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
> 
>  - CHECK_*() macros
> 
>Macro bodies should not end in a semi-colon.
> 
>If these were public and since these macro bodies are all if
>statements, you should wrap them in do { } while (0), but since
>they're private we can make sure that all uses are correct.
> 
>  - gss_import_name() doesn't check that the first two bytes of the
>input buffer are the expected token ID when the name-type is
>GSS_C_NT_EXPORTED_NAME.
> 
>  - gss_import_name() doesn't check that the third byte of the input
>buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME.
> 
>  - gss_compare_name(), this code will not distinguish a name of the
>form 'foo@' from 'foo\@'
> 
>   434 if (l1 < l2 && n2[l1] != L'@'
>   435 || l2 < l1 && n1[l2] != L'@') {
>   436 return GSS_S_COMPLETE; // different
>   437 }
> 
>Honestly, this is not the most serious problem because nothing
>really should be using gss_compare_name(), but you do use it... and
>anyways, it's wrong.
> 
>Perhaps the gss_name_struct struct should have a length of realm or
>length-of-not-realm-part field to make this check easier.
> 
>  - gss_compare_name(), do not use NORM_IGNORECASE
> 
>  - gss_canonicalize_name() should check that mech_type is Kerberos
> 
> I'll continue later.  I'm in gss_init_sec_context(), about 58% of the
> way through.
> 
> Nico
> -- 

PING? Re: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u

[Severin Gehwolf]

Hi!

Any more thoughts on this? It would be nice to get this reviewed :)

Thanks,
Severin

On Thu, 2019-05-23 at 11:53 +0200, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Thu, 2019-05-23 at 09:34 +0100, Andrew Dinn wrote:
> > Hi Severin,
> > 
> > On 22/05/2019 17:34, Severin Gehwolf wrote:
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
> > > (includes changes to top/hotspot/jdk/langtools repos)
> > > 
> > > Example excerpt from a run:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
> > > 
> > > Thoughts?
> > Unfortunately, my makefile fu is too limited to provide a reliable
> > review of the patch (I'm mostly just surprised it took so few changes to
> > achieve). However, I can still wholeheartedly applaud this endeavour and
> > its present outcome.
> 
> :) Great.
> 
> > As you say tuning the test group can be done over time as a follow-up.
> > The important thing is to quickly place devs in a position to easily
> > check that fixes have no unintended side-effects. Very nice!
> 
> Thanks for looking this over!
> 
> Cheers,
> Severin

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