I've filed https://bugs.openjdk.java.net/browse/JDK-8225687.
> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote:
>
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>>
>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
> -
> src/java.security.jgss/s
Like this?
http://cr.openjdk.java.net/~weijun/8225180/webrev.01/
Thanks,
Max
> On Jun 12, 2019, at 5:00 AM, Sean Mullan wrote:
>
> On 6/11/19 12:00 AM, Weijun Wang wrote:
>> Oops, forgot to add the bug title in the subject.
>>> On Jun 11, 2019, at 11:56 AM, Weijun Wang wrote:
>>>
>>> Plea
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
mak
> 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'
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, I
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
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 i
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
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 fi
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?)
M
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 w
Hi Xuelei,
I am not an expert of the field so please get another
reviewer for this change:
656 if (!super.isOutputShutdown() &&
...
661 } else if (!super.isOutputShutdown()) {
I think it might be clearer with a nested if:
if
On 6/11/19 7:19 PM, Bradford Wetmore wrote:
Just noticed a couple things so far:
Is there more coming? I plan to putback tomorrow to make RDP1. We can
do an RFE during RDP1->RDP2 if you find something.
I'm done. Could you add a release note to the issue? I just skimmed thru
the rest and h
ping ...
On 6/4/2019 11:10 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8224829/webrev.00/
If using one thread for closing, one thread for writing. Closing and
writing threads are synchronized in order to delivery close_notify TL
Thanks! I have no more comments.
Xuelei
On 6/11/2019 4:19 PM, Bradford Wetmore wrote:
Updated webrev:
http://cr.openjdk.java.net/~wetmore/8171279/webrev.01/
Xuelei wrote:
> ECDHClientKeyExchange.java
> --
> The enum builtin method valueOf(String) is used. There i
15 matches
Mail list logo