Hi,
java/net/httpclient/ssltest/CertificateTest.java shouldn't use a
specific TLS version.
And it would be better not to use binary key store files.
Since DSA is not supported by TLSv1.3, this fix also updates the
certificates to use RSA.
Webrev: http://cr.openjdk.java.net/~jjiang/8238677/web
Hi John,
Looks good to me. Thanks for taking care of this!
I'm glad to see the binary files go away :-)
Would it be possible to include a comment in Cert.java that contains
the command you used to generate the certificates?
That will be a great help to future maintainers if the certificates
eve
Hi,
Could you please review this patch. Default server role mode was flipped in
SSLEngine, to client role mode as part of SSL package code refactoring for
TLSv1.3, this patch flips back default client role to server role in SSLEngine.
webrev: http://cr.openjdk.java.net/~pkoppula/8237474/w
Hi Daniel,
On 2020/2/7 19:29, Daniel Fuchs wrote:
Hi John,
Looks good to me. Thanks for taking care of this!
I'm glad to see the binary files go away :-)
Thanks for your review!
Would it be possible to include a comment in Cert.java that contains
the command you used to generate the certifi
Looks ok to me Prasad. This may also be worthy of highlighting via
release note. You might be able to expand test coverage to capture the
TLSContext scenario. Something like below patch might work ?
---
a/test/jdk/sun/security/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
+++
b/test/jdk/
This is very complete.
Thanks,
Max
> On Feb 7, 2020, at 5:40 AM, Sean Mullan wrote:
>
> On 2/5/20 8:53 PM, Weijun Wang wrote:
>> sun/security/provider/ConfigFile.java:
>>private boolean expandProp = true;
>>...
>>String expand = Security.getProperty("policy.expandProperties");
>>
Thanks for review Sean, I will add test changes.
Thanks,
Prasad.K
From: Seán Coffey
Sent: Friday, February 7, 2020 6:20 PM
To: Prasadrao Koppula ;
security-dev@openjdk.java.net
Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role
Looks ok to me Prasad. This m
Hi Prasad,
On 07/02/2020 14:28, Prasadrao Koppula wrote:
Thanks for review Sean, I will add test changes.
Not a review - but I just wanted to double check that
you have run the :jdk_net tests too - especially the
httpclient tests (which are part of :jdk_net) as the
httpclient is a heavy user o
In general, cancelOperation() is not needed if the object went through
the whole cycle, e.g. Cipher object and init/update/doFinal(...) calls.
Same goes for signature object if it's called to verify the bytes.
The cancelOperation is often called when the supplied data is incomplete
or even
On 2/5/2020 9:40 PM, Andrew John Hughes wrote:> First of all, thanks
again for posting these patches and also for the
> comprehensive list of issues for both of them. They pretty much matched
> up with what I saw when reviewing the patches
Great.
> The ALPN one looks pretty clean. My only conce
Got it. Thanks! I have no more comment.
Xuelei
On 2/7/2020 2:49 PM, Valerie Peng wrote:
In general, cancelOperation() is not needed if the object went through
the whole cycle, e.g. Cipher object and init/update/doFinal(...) calls.
Same goes for signature object if it's called to verify the
Thanks for the review~
The issue is reported externally, there is the answer to your question. ;)
Valerie
On 2/6/2020 10:14 PM, Xuelei Fan wrote:
On 2/6/2020 7:02 PM, Valerie Peng wrote:
Anyone can help reviewing this?
There is a bug in RSASSA-PSS signature verification when the key size
is
Hi Daniel,
Would it be possible to include a comment in Cert.java that contains
the command you used to generate the certificates?
That will be a great help to future maintainers if the certificates
ever needs to be re-generated (e.g. to update the expiry date
etc...)
I'll do that.
Please re
13 matches
Mail list logo
