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 <erik.joels...@oracle.com> 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 <https://aka.ms/o0ukef>



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" <david.hol...@oracle.com 
<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 >>>>> >> >