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