Re: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset

Hi Xuelei, Thanks for your review! The fix just was pushed. I adjusted the following longer lines:  129 System.out.println("Client got UNEXPECTED SSLHandshakeException:");  134 System.out.println("Client got expected SSLHandshakeException:"); In addition, the

Re: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized

Hi Valerie About "it *may* return", do you mean it could also return null? My understanding is no. Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? Also, I am a little confused by "default and

Re: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)"

Thanks for the review~ Valerie On 7/10/2018 11:16 AM, Anthony Scarpino wrote: Ok, I'm fine with what you have here. thanks Tony On 07/09/2018 05:42 PM, Valerie Peng wrote: Hi Tony, The purpose of the if-block is to ensure that ArrayIndexOutOfBoundsException is thrown instead of

Re: (Open) RFR: 8205967: Remove sun/security/krb5/auto/UnboundSSL.java from ProblemList.txt

Looks fine to me. Thanks, Xuelei > On Jul 10, 2018, at 12:11 PM, Andrew Wong wrote: > > Dear Security Developer, > > Please review the following fix for bug id 8205967. The test associated with > UnboundSSL.java was removed in a previous fix but is still listed in > ProblemList.txt.

(Open) RFR: 8205967: Remove sun/security/krb5/auto/UnboundSSL.java from ProblemList.txt

Dear Security Developer, Please review the following fix for bug id 8205967. The test associated with UnboundSSL.java was removed in a previous fix but is still listed in ProblemList.txt. ProblemList.txt has been updated accordingly by removing the test.

Re: JDK 11+21 SSLSocket.close() deadlock?

Hi Simone, Thank you for reporting this issue. Now it is tracked in JBS: https://bugs.openjdk.java.net/browse/JDK-8207004 In the following stacks, only one lock (on 0xac) can be observed. Can I understand that the read() is blocked, and then the close() is blocked as well? Did you have

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

Will do tomorrow latest. Thanks for the quick reply. Bye Norman > Am 10.07.2018 um 18:53 schrieb Xuelei Fan : > > Hi Norman, > > It's an interesting user case of the TrustManagerFactory. Please file a bug. > > Thanks, > Xuelei > >> On 7/10/2018 9:57 AM, Alan Bateman wrote: >> Forwarding

Re: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)"

Ok, I'm fine with what you have here. thanks Tony On 07/09/2018 05:42 PM, Valerie Peng wrote: Hi Tony, The purpose of the if-block is to ensure that ArrayIndexOutOfBoundsException is thrown instead of IndexOutOfBoundsException.  Objects.checkFromIndexSize(...) API is specified to throw

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

Hi Norman, It's an interesting user case of the TrustManagerFactory. Please file a bug. Thanks, Xuelei On 7/10/2018 9:57 AM, Alan Bateman wrote: Forwarding to security-dev. On 10/07/2018 17:47, Norman Maurer wrote: Hi all, I just tried to run netty[1] testsuite with the latest jdk11 EA

JDK 11+21 SSLSocket.close() deadlock?

Hi, Please look at the stack traces below. The server code accept() a SSLSocket, then calls startHandshake() in a different thread. The client code sends the TLS handshake bytes very slowly. The server code waits for a bit for the handshake to finish, then attempts to close the socket, but it

Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

Hi, Webrev 04 for JDK-8029661 is ready: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04.zip * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04/ New: * Rebased to latest JDK revision (after TLS 1.3 merge) * Rev 1acfd2f56d72 * ProtocolVersion

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

Forwarding to security-dev. On 10/07/2018 17:47, Norman Maurer wrote: Hi all, I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation Caused by: java.lang.ClassCastException: class

Re: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset

Looks fine to me. Please limit each line in 80 characters. Thanks, Xuelei On 7/10/2018 2:27 AM, sha.ji...@oracle.com wrote: Hi, javax/net/ssl/SSLSession/TestEnabledProtocols.java may have some problem on sync between server and client. And it would be better to refactor this test with

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Erik, After some trial edits, I'm not so sure if moving the event & logger commit code into the class where it's used works too well after all. In the code you suggested, there's an assumption that calls such as EventHelper.certificateChain(..) are low cost. While that might be the case

RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset

Hi, javax/net/ssl/SSLSession/TestEnabledProtocols.java may have some problem on sync between server and client. And it would be better to refactor this test with SSLSocketTemplate.java. Webrev: http://cr.openjdk.java.net/~jjiang/8199645/webrev.00/ JBS: