Re: [10] RFR 8068024 : Null pointer dereference in jdk/src/macosx/native/apple/security/KeystoreImpl.m

This looks fine to me. Thanks Max > On Nov 22, 2017, at 9:47 AM, Ivan Gerasimov wrote: > > Hello! > > Here's a simple fix to correctly handle the malloc call returning NULL. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024 > WEBREV:

[11] RFR JDK-8146293: Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2

Anyone who can help reviewing this enhancement? RFE: https://bugs.openjdk.java.net/browse/JDK-8146293 Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8190180 Quick summary on the changes: 1) Enhanced SunRsaSign provider with the

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Sure, webrev updated  and CSR moved to finalized state. http://cr.openjdk.java.net/~valeriep/8182484/webrev.02/ Thanks, Valerie On 11/21/2017 9:28 AM, Sean Mullan wrote: One more small comment:   51  * Check if the returned key pair generator is an instance of the   52  *

[10] RFR 8068024 : Null pointer dereference in jdk/src/macosx/native/apple/security/KeystoreImpl.m

Hello! Here's a simple fix to correctly handle the malloc call returning NULL. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068024 WEBREV: http://cr.openjdk.java.net/~igerasim/8068024/00/webrev/ Would you please help review? -- With kind regards, Ivan Gerasimov

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

One more small comment: 51 * Check if the returned key pair generator is an instance of the 52 * DSAKeyPairGenerator interface before casting the result to a I would just say "... instance of DSAKeyPairGenerator before ..." --Sean On 11/16/17 7:39 PM, Valerie Peng wrote: Thanks for

Re: [10] RFR : 8186628 : SSL session cache can cause a scalability bottleneck

Thanks Xuelei for the comment! On 11/20/17 8:50 PM, Xuelei Fan wrote: Hi Ivan, I understand the desire of performance improvement. But I don't think avoiding the use of cache is the price we want to pay for. Besides, avoiding using of session cache is not something improving the

Re: Eliminating the security overhead when not running with a security manager

On Tue, Nov 21, 2017 at 5:41 AM, Alan Bateman wrote: > On 21/11/2017 00:48, David Lloyd wrote: >> >> One thing that springs to mind. Some allowance would have to be made >> for domain combiners and JAAS Subject propagation: this mechanism also >> uses access control

Re: Eliminating the security overhead when not running with a security manager

On 21/11/2017 00:48, David Lloyd wrote: One thing that springs to mind. Some allowance would have to be made for domain combiners and JAAS Subject propagation: this mechanism also uses access control contexts, to its own great detriment. Are you thinking about usages where there is no security