Re: RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl handshake [v2]

2021-10-01 Thread Alexey Bakhtin
> Please review the patch for JDK-8274524 > > The fix just adds locks around InputStream read and skip operations to > prevent concurrent read from socket. > sun/security/ssl jtreg tests passed > api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed Alexey Bakhtin has updated the pull req

Re: RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

2021-10-01 Thread Alexey Bakhtin
On Thu, 30 Sep 2021 23:04:20 GMT, Clive Verghese wrote: > Hi @alexeybakhtin, > > Thank you for the PR. > > I have a question regarding the lock, Would adding a > `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve this > issue? Hi Clive, Thank you for your review. I thin

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v3]

2021-10-01 Thread Weijun Wang
> Extra parameters need to be set for RSASSA-PSS signatures. We already have a > helper method for that. > > Some other cleanups: > 1. When using GET for OCSP, make sure no double slash. > 2. Several throws clauses are not necessary. > > No regression test. OCSP needs to access an external serve

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v2]

2021-10-01 Thread Weijun Wang
On Fri, 1 Oct 2021 03:32:11 GMT, Weijun Wang wrote: >> Extra parameters need to be set for RSASSA-PSS signatures. We already have a >> helper method for that. >> >> Some other cleanups: >> 1. When using GET for OCSP, make sure no double slash. >> 2. Several throws clauses are not necessary. >>

Re: RFR: 8274524: SSLSocket.close() hangs if it is called during the ssl handshake

2021-10-01 Thread Clive Verghese
On Fri, 1 Oct 2021 10:49:00 GMT, Alexey Bakhtin wrote: >> Hi @alexeybakhtin, >> >> Thank you for the PR. >> >> I have a question regarding the lock, Would adding a >> `appInput.readLock.lock()` in `SSLSocketImpl:decode(ByteBuffer)` resolve >> this issue? > >> Hi @alexeybakhtin, >> >> Thank

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v5]

2021-10-01 Thread Weijun Wang
> This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the CSR as well. Weijun Wang has updated the pull request incrementally

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v4]

2021-10-01 Thread Weijun Wang
On Tue, 28 Sep 2021 14:24:01 GMT, Weijun Wang wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as wel

RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

2021-10-01 Thread Weijun Wang
Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java. - Commit messages: - 8274656: Remove default_checksum and safe_checksum_type from krb5.conf Changes: https://git.openjdk.java.net/jdk/pull/5788/files Webr

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Wed, 29 Sep 2021 22:40:10 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the nativ

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Wed, 29 Sep 2021 23:56:07 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the nativ

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Thu, 30 Sep 2021 23:05:44 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the nativ

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Thu, 30 Sep 2021 02:32:33 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the nativ

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v3]

2021-10-01 Thread Hai-May Chao
On Fri, 1 Oct 2021 14:43:24 GMT, Weijun Wang wrote: >> Extra parameters need to be set for RSASSA-PSS signatures. We already have a >> helper method for that. >> >> Some other cleanups: >> 1. When using GET for OCSP, make sure no double slash. >> 2. Several throws clauses are not necessary. >>

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Thu, 30 Sep 2021 19:14:10 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the nativ

Re: RFR: 8264849: Add KW and KWP support to PKCS11 provider

2021-10-01 Thread Valerie Peng
On Fri, 1 Oct 2021 00:51:27 GMT, Anthony Scarpino wrote: >> Anyone has time to review this RFE for adding AES cipher with KW, KWP modes >> support to SunPKCS11 provider? >> >> The main changes are in only one new class, i.e. P11KeyWrapCipher.java, >> which is the CipherSpi impl for the native

RFR: 8274308: Improve efficiency for HandshakeContext initialization.

2021-10-01 Thread Clive Verghese
Hi, We have identified that the `HandshakeContext` initialization takes up a close to 50% of the flame graph for startHandshake. I have moved the computation of the `activeProtocols` and `activeCipherSuites` from the HandshakeContext constructor to SSLConfiguration class because the values used