On 6/14/19 11:33 AM, Weijun Wang wrote:
Here is the updated webrev
http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
The only change is ordering in 'keytool -list' and its test.
Looks fine.
--Sean
Thanks,
Max
On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote:
On 6/14/19 1:49 AM,
I'm happy with this.
/Erik
On 2019-06-14 08:33, Weijun Wang wrote:
Here is the updated webrev
http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
The only change is ordering in 'keytool -list' and its test.
Thanks,
Max
On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote:
On 6/14/19 1:49
Here is the updated webrev
http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
The only change is ordering in 'keytool -list' and its test.
Thanks,
Max
> On Jun 14, 2019, at 7:55 PM, Sean Mullan wrote:
>
> On 6/14/19 1:49 AM, Weijun Wang wrote:
>> BTW, something not related but similar:
On 6/14/19 1:49 AM, Weijun Wang wrote:
BTW, something not related but similar: Do you like me to also sort aliases
alphabetically in the output of "keytool -list"?
Yes, I think that is useful.
--Sean
> On Jun 14, 2019, at 5:00 AM, Sean Mullan wrote:
>
> 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
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
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
> On Jun 13, 2019, at 12:16 AM, Martin Buchholz wrote:
>
> I'm not a security engineer, but:
> - consider creating static finals for e.g. "Mighty Aphrodite" just to give it
> a symbolic name.
That method is copied from JavaKeyStore.java. Keeping it 100% unchanged gives
me more confidence
I plan to fix it in JDK 13. --Max
> On Jun 13, 2019, at 12:38 AM, 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,
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
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
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
I'm not a security engineer, but:
- consider creating static finals for e.g. "Mighty Aphrodite" just to give
it a symbolic name.
- VerifyCACerts probably fails when the jdk is configured with a different
cacerts file (but the JDK doesn't preserve configuration information - how
could one fix it?)
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 wrote:
>
> Hi Erik,
>
> Are you going to fix this bug soon?
>
> I am inspired by Martin's words and
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,
Good idea about the creation time.
--Max
> On Jun 12, 2019, at 10:53 AM, Martin Buchholz 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,
Hi Erik,
On 12/06/2019 12:48 am, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02
Filtering out the date and adding a sort. All my builds yesterday
resulted in cacerts files with the same order of the keys, but today the
order changed. Looking through the
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
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
New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02
Filtering out the date and adding a sort. All my builds yesterday
resulted in cacerts files with the same order of the keys, but today the
order changed. Looking through the source (JavaKeyStore.engineStore()),
the store method
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
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],
But you should see the date on the same line as the alias and the type.
—Max
获取 Outlook for iOS
On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes"
wrote:
Hi Max,
On 11/06/2019 11:05 am, Weijun Wang wrote:
> keytool -keystore ..
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
keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
would exclude the date (which has its own line).
--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
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
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
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
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
29 matches
Mail list logo
