The old code
265 prng = "SHA1PRNG";
266 this.secureRandomSpi = new
sun.security.provider.SecureRandom();
267 this.provider = Providers.getSunProvider();
always works since that class is always there.
Now, it's
282 prngService =
Providers.ge
Hai-May has a similar function as a by-product in
https://cr.openjdk.java.net/~hchao/8244148/webrev.02/
See FilePaths.java and MyOwnCacerts.java for the detail. Her code change is in
code review now.
Please coordinate with her on how to get this done nicely.
Thanks,
Max
> On Jun 11, 2020,
"to a self-signed certificate in the keystore". This is not correct. What we
look for is a TrustedCertificateEntry.
"It emits warning when a certificate is not trusted and uses weak algorithms".
Precisely, it's "uses a weak signature algorithm".
--Max
> On Jun 10, 2020, at 5:31 PM, Hai-May Ch
Hi,
This patch contains a patched version for class
sun.security.util.AnchorCertificates.
It allows to add CAs to cacerts at runtime for testing purpose.
Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8245520
Best regards,
John Jia
Updated webrev after incorporating Sean's feedbacks:
http://cr.openjdk.java.net/~valeriep/8246613/webrev.03/
Main changes are code refactoring in SecureRandom class and changed
Provider class to store SecureRandom services in their order of
registration instead of only the algorithm name.
Th
Thank you for taking care of the issue. The update looks good to me. I
added myself as the reviewer in the CSR.
Xuelei
On 6/10/2020 4:12 PM, Joe Darcy wrote:
Hello,
Please review the addition of several explicit constructors to abstract
classes in javax.net.ssl to remove the use of implici
Hello,
Please review the addition of several explicit constructors to abstract
classes in javax.net.ssl to remove the use of implicit default
constructors; CSR link and patch below:
JDK-8247374: Remove default constructors from javax.net.ssl
CSR: https://bugs.openjdk.java.net/browse/J
Thanks Valerie!
If I understand you correctly, I think you are saying the fix for
https://bugs.openjdk.java.net/browse/JDK-8246613 will mean the first
SecureRandom in the provider will be used as the default (which will make it
equivalent to JDK 11.06 and previous versions).If that is the
Hi John,
As you may have noticed, we are progressing a fix for
https://bugs.openjdk.java.net/browse/JDK-8246613 for returning the same
default SecureRandom algo for 3rd party providers as in pre-JDK7092821
releases. Thus, the chance of observing JDK-8246613 should be lowered
significantly. Gi
Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/
Key changes in this revision are in the Delegate.of() method in
java.security.MessageDigest class.
Comments?
Thanks,
Valerie
On 6/8/2020 1:42 PM, Valerie Peng wrote:
"md instanceof Cloneable && md is not from PKCS11" i
It may be not needed to update the handleException() method.
- 440handleException(iioe);
+ 440if (resumable) {
+throw iioe;
+} else {
+handleException(iioe);
+}
Otherwise, looks good to me.
Xuelei
O
Hi,
found it: https://bugs.openjdk.java.net/browse/JDK-8237876
Thanks,
Tigran.
- Original Message -
> From: "Daniel Fuchs"
> To: "Sean Mullan" , "Tigran Mkrtchyan"
> , "security-dev"
>
> Cc: "core-libs-dev"
> Sent: Wednesday, June 10, 2020 4:29:36 PM
> Subject: Re: Thread leak by
On 09/06/2020 23:21, Sean Mullan wrote:
The issue is not observed with java-14, thus I assume that the fix is
related to commit
http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4
As java-11 is LTS, what is the procedure to get it fix back-ported?
Hi,
AFAICS the fix has already been backpor
> On Jun 9, 2020, at 5:58 PM, Weijun Wang wrote:
>
> Good to see both -keystore and -trustcacerts mentioned. Some comments:
>
> 1. I think there is no need to say "from -file cert_file". Or, do you mean
> the new function does not apply to those from -sslserver and -jarfile? If so,
> that m
Hello Sean,
The link to CSR for this feature :
https://bugs.openjdk.java.net/browse/JDK-8247311
Regards
Alexey
> On 9 Jun 2020, at 19:50, Sean Mullan wrote:
>
> On 6/9/20 12:40 PM, Xuelei Fan wrote:
>> About the prefix, it may follow RFC 5056 (See page 7, section 2.1).
>>o Specifications
15 matches
Mail list logo