Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as public. We may need to re-org the code later, but it is out of the scope of this update. Here is the new webrev (only AbstractDelegateHttpsURLConnection updated): http://cr.openjdk.java.net/~xuelei/8215430/w

Re: CSR Review Request, JDK-8160247 Mark deprecated javax.security.cert APIs with forRemoval=true

All comments make sense to me. I have updated the CSR accordingly. Thanks, Xuelei On 2/25/2019 1:23 PM, Sean Mullan wrote: The diffs seem out of date. The @Deprecated annotations already have @since="9". There are a few JSSE APIs that reference these deprecated APIs that should also be mark

Re: Java SSLSocketChannel/SSLSelector?

> > I am beginning to think we might be on different pages here. Someone from > outside the selector calls selector.select(), and all selector's > functionality is handled within the context of the calling thread. So where > is the need for the extra thread here? More specifically, in the > SSLSele

Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

(I'd suggest cross-posting to net-dev since some classes in the networking area are also changed). - AbstractDelegateHttpsURLConnection It might be less risky to leave the methods as public just in case some code out there is using them (even though they are not supposed to). The rest of thi

Re: CSR Review Request, JDK-8160247 Mark deprecated javax.security.cert APIs with forRemoval=true

The diffs seem out of date. The @Deprecated annotations already have @since="9". There are a few JSSE APIs that reference these deprecated APIs that should also be marked forRemoval and included in the CSR: HandshakeCompletedEvent.getPeerCertificateChain() SSLSession.getPeerCertificateChain()

Re: [13] RFR JDK-8218780 "Update MUSCLE PCSC-Lite header files"

Looks fine to me Valerie. regards, Sean. On 15/02/2019 20:04, Valerie Peng wrote: Hi Sean (Coffey), Can you please help reviewing this fix? It's about updating the PC/SC lite header files under the MUSCLE directory inside smartcardio module. The header files are from https://pcsclite.apdu.fr

RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11

In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]). After unsuccessfully trying to pat

RFR [13] JDK-8219658: Deadlock in sun.security.ssl.SSLSocketImpl

Hi, Please review the following update: http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/ There could be a deadlock if different threads are used for socket closing and reading. The update is similar to the bug reported proposed fix, and has been verified. No new regression test. T

CSR Review Request JDK-816826, Use server cipher suites preference by default

Hi, Could I have the following CSR reviewed? https://bugs.openjdk.java.net/browse/JDK-8219657 It is proposing to use server cipher suite preference by default for TLS connections in JDK. In the current implementation, the server honors the client cipher suite preference by default. It is ea

Re: RFR[13] JDK-8215524: Finished message validation failure should be decrypt_error alert

Looks fine to me. Thanks, Xuelei On 2/25/2019 4:01 AM, sha.ji...@oracle.com wrote: Hi, When Finished message is validated failed, illegal_parameter is raised currently. But per RFC 8446 section 6.2, this error should alert decrypt_error. And according to the same section, if the length of ver

RFR[13] JDK-8215524: Finished message validation failure should be decrypt_error alert

Hi, When Finished message is validated failed, illegal_parameter is raised currently. But per RFC 8446 section 6.2, this error should alert decrypt_error. And according to the same section, if the length of verify_data in Finished is incorrect, it should alert decode_error rather than illegal_