Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Hi Johh, thank you for the review! On 04/13/2015 09:50 PM, John Rose wrote: On Apr 13, 2015, at 4:51 AM, Zoltán Majó > wrote: please review the following patch. Good. This line has a typo ("encrypBlock" = gang member induction party foul?): + * AESCrypt.en

Re: [9] RFR: 8076221: Disable RC4 cipher suites

Looks fine to me. Thanks, Xuelei On 4/14/2015 1:54 PM, Artem Smotrakov wrote: > Hello, > > RFC 7465 [1] has been published to prohibit RC4. > > Please review this fix which disables RC4 cipher suites in JDK 9 by > adding "RC4" to "jdk.tls.disabledAlgorithms" security property. > > Webrev: http

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Sorry for later notice. Can you also list initialCounterBlk.length value in exception message? Thanks, Vladimir On 4/14/15 12:44 AM, Zoltán Majó wrote: Hi Johh, thank you for the review! On 04/13/2015 09:50 PM, John Rose wrote: On Apr 13, 2015, at 4:51 AM, Zoltán Majó mailto:zoltan.m...@or

Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension

Hi, the point is simple. The description for the code say that TLSv1.2 should not have an valid PRF. But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2. But since obsoleted is set to TLSv1.2 the code part: if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } Does no

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Hi Vladimir, On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: Sorry for later notice. Can you also list initialCounterBlk.length value in exception message? thank you for the feedback! I extended the error message in the exception, here is the updated webrev: http://cr.openjdk.java.net/~zmaj

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Good. Thanks, Vladimir On 4/14/15 10:54 AM, Zoltán Majó wrote: Hi Vladimir, On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: Sorry for later notice. Can you also list initialCounterBlk.length value in exception message? thank you for the feedback! I extended the error message in the excep

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Thank you, John and Vladimir, for the review! Best regards, Zoltan On 14.04.2015 18:59, Vladimir Kozlov wrote: Good. Thanks, Vladimir On 4/14/15 10:54 AM, Zoltán Majó wrote: Hi Vladimir, On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: Sorry for later notice. Can you also list initialCoun

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

The updated changes look good to me.. Tony On 04/14/2015 12:44 AM, Zoltán Majó wrote: Hi Johh, thank you for the review! On 04/13/2015 09:50 PM, John Rose wrote: On Apr 13, 2015, at 4:51 AM, Zoltán Majó mailto:[email protected]>> wrote: please review the following patch. Good. Thi

Re: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal

Thank you, Tony, for the review! Best regards, Zoltan On 14.04.2015 19:11, Anthony Scarpino wrote: The updated changes look good to me.. Tony On 04/14/2015 12:44 AM, Zoltán Majó wrote: Hi Johh, thank you for the review! On 04/13/2015 09:50 PM, John Rose wrote: On Apr 13, 2015, at 4:51

Re: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation

On 04/13/2015 07:40 PM, Jason Uh wrote: Thanks, Sean. Here is a revision: http://cr.openjdk.java.net/~juh/8076117/02/ Looks good. Just one other comment: the type field in Validator should be private since it isn't referenced by any other code in that package. No need to post an updated web

Re: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation

On 4/14/15 11:58 AM, Sean Mullan wrote: On 04/13/2015 07:40 PM, Jason Uh wrote: Thanks, Sean. Here is a revision: http://cr.openjdk.java.net/~juh/8076117/02/ Looks good. Just one other comment: the type field in Validator should be private since it isn't referenced by any other code in that p

Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension

Hi, the point is simple. The description for the code say that TLSv1.2 should not have an valid PRF. But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2. But since obsoleted is set to TLSv1.2 the code part: if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } Does no

Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension

I see. I filed a new bug: https://bugs.openjdk.java.net/browse/JDK-8077806 Thanks for looking into this issue. Xuelei On 4/15/2015 12:25 AM, Thomas Lußnig wrote: > Hi, > > the point is simple. The description for the code say that TLSv1.2 > should not have an valid PRF. > But for example SSL