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