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