Re: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError

I will change those additional spots in the code.  Glad you caught those.  I think also your suggestion about a comment on those locations in the code makes sense. --Jamil On 12/5/2018 8:20 PM, Xue-Lei Fan wrote: Hi Jamil, For a defense in depth fix, as you are already there, I may suggest

Fwd: My current jdk12 changes

Hi All Currently, I have 4 code changes out for review and I wish they can make JDK 12 (RDP1 is 12/13) 8076190: Customizing the generation of a PKCS12 keystore https://cr.openjdk.java.net/~weijun/8076190/webrev.05/ 6722928: Support SSPI as a native GSS-API provider https://cr.openjdk.ja

Re: RFR 8213009: Refactoring existing SunMSCAPI classes

Webrev updated at https://cr.openjdk.java.net/~weijun/8213009/webrev.03 I reset messageDigest/messageDigestAlgorithm/needsReset and check for "key instanceof RSAPublicKey" in RSA::engineInitVerify. Thanks Max > On Nov 27, 2018, at 10:13 PM, Weijun Wang wrote: > > > >> On Nov 27, 201

Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Wed, Dec 05, 2018 at 11:41:44AM +0800, Weijun Wang wrote: > Java's GSSName::isMN always returns true, therefore to my observation, the > GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. That *would* be a valid design choice (per RFCs 2743 and 2744), but it requires

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

On Mon, Dec 03, 2018 at 05:10:26PM +, Seán Coffey wrote: > I made further edits to update the DNSName comment code to reference RFC > 5280 rather than the obsoleted RFC 2459. I also updated the test case with a > few extra tests per suggestion from Chris and others. Moved the dataprovider > int

RFR 8214688: TLS 1.3 session resumption with hello retry request failed with "illegal_parameter"

Webrev: http://cr.openjdk.java.net/~apetcher/8214688/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8214688 The last session resumption bug fix[1] I made introduced a new issue when the server sends a HelloRetryRequest message. The proposed fix is pretty simple: when the client select

Re: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError

Hello everyone, Updates from Xuelei's comments have been folded into an updated webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/ Thank you, --Jamil On 12/5/18 3:59 PM, Jamil Nimeh wrote: Hello all, This fix covers an issue where large numbers of TLS 1.2 session resumpt

Re: RFR 6722928: Support SSPI as a native GSS-API provider

Looking at how to fix the incorrect isMN() implementation... The lowest cost route to fixing that would start with this sort of change: diff --git a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.j

Re: RFR JDK-8214129: SSL session resumption/SNI with TLS1.2 causes StackOverflowError

Looks fine to me. Thanks, Xuelei On 12/6/2018 1:09 PM, Jamil Nimeh wrote: Hello everyone, Updates from Xuelei's comments have been folded into an updated webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8214129/webrev.02/ Thank you, --Jamil On 12/5/18 3:59 PM, Jamil Nimeh wrote: Hello a

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hi Smita, Great, the numbers look better. I'll run the regression tests and push it if all goes well. Tony On 12/6/18 11:19 AM, Kamath, Smita wrote: Hi Tony, I have updated my code to address the performance regression in smaller data sizes. Please find the updated webrev and JBS link atta

Re: RFR 8213009: Refactoring existing SunMSCAPI classes

Hi, Max, CSignature.java: one last nit, line 98 and 102 can be replaced by just one line outside the if-block. Thanks, Valerie On 12/6/2018 6:33 AM, Weijun Wang wrote: Webrev updated at https://cr.openjdk.java.net/~weijun/8213009/webrev.03 I reset messageDigest/messageDigestAlgorithm/

Re: RFR 8213009: Refactoring existing SunMSCAPI classes

Hi Valerie, I'll fix it in my local repo, run some test, and push the changeset. Thanks, Max > On Dec 7, 2018, at 6:58 AM, Valerie Peng wrote: > > Hi, Max, > > CSignature.java: one last nit, line 98 and 102 can be replaced by just one > line outside the if-block. > > Thanks, > > Valerie >

Re: RFR 6722928: Support SSPI as a native GSS-API provider

I filed https://bugs.openjdk.java.net/browse/JDK-8214988. Thanks, Max > On Dec 7, 2018, at 5:33 AM, Nico Williams wrote: > > Looking at how to fix the incorrect isMN() implementation... The lowest cost > route to fixing that would start with this sort of change: > >diff --git > a/src/jav

Re: RFR 8208648: ECC Field Arithmetic Enhancements

Hi Adam, comments/questions below (mostly simple stuff, nothing major): * IntegerPolynomial.java o The comment block for multByInt should reflect your changes you made, namely the removal of "r" from the signature. o 88: In the case of multiplying two very large long values woul

Re: RFR 6913047: SunPKCS11 memory leak

Hi Martin, I suppose the changes in this update is just the system property renaming? I looked at the relevant files and they look fine. If you made more changes than this, please let me know and I will take a closer look at them. Don't forget to add a release note subtask for JDK-6913047 as

Re: RFR 6722928: Support SSPI as a native GSS-API provider

Hi Nico, Your detailed analysis is very valuable and I've included the whole text into https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was complicated at the beginning and I remember I've especially asked you to look at it in my initial code review request. I think I have a bet

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

Hi, Max, In  my first prototype, I got rid of the Entries classes (for both SUN and SunRsaSign provider) and adds the Services inside the Provider. Later, when I saw VerificationProvider class and its dependency on the Entries class, I have to revert back to the original approach of having th

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

Right, thanks for catching this. Will fix it in next webrev. Valerie On 12/5/2018 7:28 PM, Weijun Wang wrote: Hi Valerie -map.put("CertPathBuilder.PKIX ValidationAlgorithm", -"RFC5280"); -map.put("CertPathValidator.PKIX ValidationAlgorithm", -"RFC5280");

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

> On Dec 7, 2018, at 10:52 AM, Valerie Peng wrote: > > Hi, Max, > > In my first prototype, I got rid of the Entries classes (for both SUN and > SunRsaSign provider) and adds the Services inside the Provider. Later, when I > saw VerificationProvider class and its dependency on the Entries c

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

Hi Sean, Thanks for your review, I have removed the stale comment from the VerificationProvider. As for your concern on race condition, legacyChanged and the String/String legacy mapping are still synchronized on the provider object. Only the service mapping is managed by the ConcurrentHashM

Re: RFR 8208698: Improved ECC Implementation

On 11/30/18 12:01 PM, Adam Petcher wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8208698 webrev: http://cr.openjdk.java.net/~apetcher/8208698/webrev.00/ This is a re-implementation of ECDH and ECDSA that is designed to be resilient against side-channel attacks. The implementation only su

Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Fri, Dec 07, 2018 at 10:45:02AM +0800, Weijun Wang wrote: > Your detailed analysis is very valuable and I've included the whole text into > https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was > complicated at the beginning and I remember I've especially asked you to look > at it