On 6/12/19 9:52 PM, Weijun Wang wrote:
Hi Sean,
The previous fix for JDK-8193255 already made the creation date useless. Before
that, each time cacerts was regenerated the date changed. I compared cacerts of
different releases and the same cert have difference creation dates.
The only other solution I can think of is to look at
make/autoconf/version-numbers and use the DEFAULT_VERSION_DATE=2019-09-17 there.
Yes, a possibility, use the GA release date, which maybe "makes more
sense" as a creation date, although a bit odd to have creation dates in
the future before GA.
I'll leave it up to you. I think nobody really looks at the creationDate.
Have you reviewed the code changes? You can see I stored the hash of the whole
file into the test. This means anyone updating the CA certs will have to create
cacerts and calculate the correct hash and update this test. I suppose this
won't be a hassle.
Not really, since you had to update VerifyCACerts anyway whenever a
change to cacerts was made, but what's the benefit of the hash? Are you
worried the cacerts binary will be corrupted somehow, or you just want
extra assurance something didn't go wrong?
It might be useful to run older versions of keytool against the cacerts
binary you created - this would give you more assurance that your
hand-coded format is correct. I would also try various commands, etc.
--Sean
Thanks,
Max
On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
On 6/12/19 4:01 PM, Erik Joelsson wrote:
Hello,
We cannot rely on querying mercurial at build time. The source must be
buildable from a source distribution.
I had a feeling it wouldn't work but thought I would ask anyway.
Well, offhand I can't think of any better solution than notBefore then, unless
we included it as a comment in the PEM file, and then extracted it. With
notBefore, someone might be curious about why some keystore entries were
created so long ago (ex: the earliest notBefore date is 1996). But the
creationDate doesn't really have any usefulness for cacerts, so it's probably
ok.
--Sean
/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
