From bradford.wetmore at oracle.com Wed Jun 1 00:46:49 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 31 May 2016 17:46:49 -0700 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: Message-ID: <92463cc3-c084-ae37-468a-7817be04dbc5@oracle.com> JSSE uses the JCA/JCE libraries (javax.crypto/java.security) for most crypto routines. Brad On 5/29/2016 11:02 PM, Ayaskant Swain wrote: > Hi, > > Can anyone please help me know about this - Does JSSE library implement > the Ciphers or Algorithms of a SSL protocol ? I see the jsse.jar library > shipped with the JDK. I read the the Oracle document about JSSE > - http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction > > So my question is - does the JSSE implement the Ciphers or Algorithms > that are used for a successful SSL handshake , server authentication, > data integrity & data confidentiality (Application data encryption). > > Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* > * > * > So is the coding of the above ciphers have been done in the JSSE library? > > Thanks > Ayaskant > Bangalore From jim.manico at owasp.org Wed Jun 1 02:42:12 2016 From: jim.manico at owasp.org (Jim Manico) Date: Tue, 31 May 2016 16:42:12 -1000 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: Message-ID: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> I think this is the right answer. From https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE suites *IF there is an available (JCE) provider* for needed ECC primitives. *Java 1.6 OOTB does NOT* include such an ECC provider, but you can add one. *Java 7 and 8 do* include SunECC provider. - Jim On 5/29/16 8:02 PM, Ayaskant Swain wrote: > Hi, > > Can anyone please help me know about this - Does JSSE library > implement the Ciphers or Algorithms of a SSL protocol ? I see the > jsse.jar library shipped with the JDK. I read the the Oracle document > about JSSE > - http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction > > So my question is - does the JSSE implement the Ciphers or Algorithms > that are used for a successful SSL handshake , server authentication, > data integrity & data confidentiality (Application data encryption). > > Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* > * > * > So is the coding of the above ciphers have been done in the JSSE library? > > Thanks > Ayaskant > Bangalore -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Jun 1 07:52:09 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Jun 2016 08:52:09 +0100 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> Message-ID: On 01/06/2016 03:42, Jim Manico wrote: > > I think this is the right answer. > > From > https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support > > The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE > suites*IF there is an available (JCE) provider*for needed ECC > primitives.*Java 1.6 OOTB does NOT*include such an ECC provider, but > you can add one.*Java 7 and 8 do*include SunECC provider. > I don't believe Ayaskant's query was specific to ECC. In any case, the above answer isn't accurate. ECC support is available OOTB in JDK 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC provider was added in JDK 7: http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC regards, Sean. > > - Jim > > > On 5/29/16 8:02 PM, Ayaskant Swain wrote: >> Hi, >> >> Can anyone please help me know about this - Does JSSE library >> implement the Ciphers or Algorithms of a SSL protocol ? I see the >> jsse.jar library shipped with the JDK. I read the the Oracle document >> about JSSE - >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >> >> So my question is - does the JSSE implement the Ciphers or Algorithms >> that are used for a successful SSL handshake , server authentication, >> data integrity & data confidentiality (Application data encryption). >> >> Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or >> **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >> * >> * >> So is the coding of the above ciphers have been done in the JSSE library? >> >> Thanks >> Ayaskant >> Bangalore > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Jun 1 08:20:50 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 1 Jun 2016 09:20:50 +0100 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> Message-ID: <7a8b6fae-f6a3-c4ff-68d1-86be6c245f8f@oracle.com> The JDK pulls crypto operations from different providers to complete operations (like TLS handshakes). The jsse.jar file is primarily tasked with handling TLS operations but will call into other providers (jars) where necessary. That's all controlled by the security provider framework. If you're interested in seeing exactly what providers are in use, you can use the -Djava.security.debug=provider property. It'll print that information in verbose detail. That extra output is available in 7u80, 8u40 and later JDKs : https://bugs.openjdk.java.net/browse/JDK-8056026 Regards, Sean. On 01/06/2016 09:06, Ayaskant Swain wrote: > Hi All, > > My question was not specific to those two cipher suites that I had > pasted in my query. I had just pasted them as examples. Rather my > question was generic. > > I want to know which library or packages in JDK implement the > Algorithms/Ciphers that are used for SSL communication? > > If java provides the implementation of those cryptographic Algos > through the *java.security , java.net.ssl & javax.crypto* packages > then what is the role of the *jsse.jar* library that ships in as part > of the *JAVA_HOME/ jre/lib* directory? > > I could clearly see the *jsse.jar *has classes like *Handshaker.class, > SSLContextImpl.class, HandShakeMessage.class* inside the > sun.security.ssl package which do the actual SSL Handshake. There are > many more classes inside this package. > > So wanted clarification on this. > > Thanks > Ayas > > On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey > wrote: > > > On 01/06/2016 03:42, Jim Manico wrote: >> >> I think this is the right answer. >> >> From >> https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support >> >> The SSL/TLS implementation "JSSE" in Java 1.6 and later supports >> ECDHE suites*IF there is an available (JCE) provider*for needed >> ECC primitives.*Java 1.6 OOTB does NOT*include such an ECC >> provider, but you can add one.*Java 7 and 8 do*include SunECC >> provider. >> > I don't believe Ayaskant's query was specific to ECC. In any case, > the above answer isn't accurate. ECC support is available OOTB in JDK > 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC > provider was added in JDK 7: > http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC > > regards, > Sean. >> >> - Jim >> >> >> On 5/29/16 8:02 PM, Ayaskant Swain wrote: >>> Hi, >>> >>> Can anyone please help me know about this - Does JSSE library >>> implement the Ciphers or Algorithms of a SSL protocol ? I see >>> the jsse.jar library shipped with the JDK. I read the the Oracle >>> document about JSSE - >>> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >>> >>> So my question is - does the JSSE implement the Ciphers or >>> Algorithms that are used for a successful SSL handshake , server >>> authentication, data integrity & data confidentiality >>> (Application data encryption). >>> >>> Example of cipher suites - >>> *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or >>> **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >>> * >>> * >>> So is the coding of the above ciphers have been done in the JSSE >>> library? >>> >>> Thanks >>> Ayaskant >>> Bangalore >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jun 1 14:03:36 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Jun 2016 10:03:36 -0400 Subject: RFR: 8154009: Some methods of java.security.Security require more permissions, than necessary In-Reply-To: <574C3A37.7010607@oracle.com> References: <574C3A37.7010607@oracle.com> Message-ID: <574EEB38.50209@oracle.com> I think it would be helpful to add a comment to EmptyPolicy.policy so it contains something, ex: // empty policy file for testing Otherwise, looks fine. --Sean On 05/30/2016 09:03 AM, Artem Kosarev wrote: > Hello. > > Could you please review the proposed fix issue which is NOT applicable > for JDK 9: > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154009 > WEBREV: http://cr.openjdk.java.net/~akosarev/8154009/webrev.00/ > > PROBLEM: > **/AddProvider/, /RemoveProvider///& /GetProviders///methods > of*//**/java.security.Security/* class results in calling > /doLoadProvider /method of *ProviderConfig *class for each Security > Provider. > And in this method we have a problem that it catches and processes > *Exception*, but doesn't process *ExceptionInInitializerError *which is > thrown in case of missing permissions: > permission java.lang.RuntimePermission "loadLibrary.*"; > permission java.io.FilePermission "<>", "read"; > permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.*"; > Those permissions are unavailable if we switch-off > *jre/lib/security/java.policy* file by running program with option: > /-Djava.security.policy==/ > > FIX: > In JDK9 *ProviderConfig *class is changed in the scope of > JDK-8043406 > enhancement (that is why JDK-8154009 is not applicable for JDK 9). > And in order to fix above problem in JDK 8 we just require to take > same changes for *ProviderConfig *class in JDK 9: > See changeset from JDK 9: > http://hg.openjdk.java.net/jdk9/dev/jdk/diff/7f8294841146/src/share/classes/sun/security/jca/ProviderConfig.java > > REGRESSION TESTS: > 2 existing tests (*AddProvider*, *RemoveStaticProvider*) were used > and modified so that they provide testing for fixed situation > (additional permissions are not required any longer for /AddProvider > /&**/RemoveProvider /methods.) > 1 new test was written for checking /GetProviders /method under > restricted permissions. > > Changes were successfully tested by JPRT. > > Best regards, > Artem Kosarev. From artem.kosarev at oracle.com Wed Jun 1 14:56:27 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Wed, 1 Jun 2016 17:56:27 +0300 Subject: RFR: 8154009: Some methods of java.security.Security require more permissions, than necessary In-Reply-To: <574EEB38.50209@oracle.com> References: <574C3A37.7010607@oracle.com> <574EEB38.50209@oracle.com> Message-ID: Hi Sean. Thanks for suggestion. New WebRev: http://cr.openjdk.java.net/~akosarev/8154009/webrev.01/ There are only 2 changes from original one: 1) *test/java/security/Security/EmptyPolicy.policy* was updated in the way you proposed. 2) I removed 2 tests from *test/ProblemList.txt*, which were marked as failed due to JDK-8154009 (current fix). Best regards, Artem Kosarev. ** On 01.06.2016 17:03, Sean Mullan wrote: > I think it would be helpful to add a comment to EmptyPolicy.policy so > it contains something, ex: > > // empty policy file for testing > > Otherwise, looks fine. > > --Sean > > On 05/30/2016 09:03 AM, Artem Kosarev wrote: >> Hello. >> >> Could you please review the proposed fix issue which is NOT applicable >> for JDK 9: >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154009 >> WEBREV: http://cr.openjdk.java.net/~akosarev/8154009/webrev.00/ >> >> PROBLEM: >> **/AddProvider/, /RemoveProvider///& /GetProviders///methods >> of*//**/java.security.Security/* class results in calling >> /doLoadProvider /method of *ProviderConfig *class for each Security >> Provider. >> And in this method we have a problem that it catches and processes >> *Exception*, but doesn't process *ExceptionInInitializerError *which is >> thrown in case of missing permissions: >> permission java.lang.RuntimePermission "loadLibrary.*"; >> permission java.io.FilePermission "<>", "read"; >> permission java.lang.RuntimePermission >> "accessClassInPackage.sun.security.*"; >> Those permissions are unavailable if we switch-off >> *jre/lib/security/java.policy* file by running program with option: >> /-Djava.security.policy==/ >> >> FIX: >> In JDK9 *ProviderConfig *class is changed in the scope of >> JDK-8043406 >> enhancement (that is why JDK-8154009 is not applicable for JDK 9). >> And in order to fix above problem in JDK 8 we just require to take >> same changes for *ProviderConfig *class in JDK 9: >> See changeset from JDK 9: >> http://hg.openjdk.java.net/jdk9/dev/jdk/diff/7f8294841146/src/share/classes/sun/security/jca/ProviderConfig.java >> >> >> REGRESSION TESTS: >> 2 existing tests (*AddProvider*, *RemoveStaticProvider*) were used >> and modified so that they provide testing for fixed situation >> (additional permissions are not required any longer for /AddProvider >> /&**/RemoveProvider /methods.) >> 1 new test was written for checking /GetProviders /method under >> restricted permissions. >> >> Changes were successfully tested by JPRT. >> >> Best regards, >> Artem Kosarev. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayaskant.swain at gmail.com Wed Jun 1 08:06:20 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Wed, 1 Jun 2016 13:36:20 +0530 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> Message-ID: Hi All, My question was not specific to those two cipher suites that I had pasted in my query. I had just pasted them as examples. Rather my question was generic. I want to know which library or packages in JDK implement the Algorithms/Ciphers that are used for SSL communication? If java provides the implementation of those cryptographic Algos through the *java.security , java.net.ssl & javax.crypto* packages then what is the role of the *jsse.jar* library that ships in as part of the *JAVA_HOME/ jre/lib* directory? I could clearly see the *jsse.jar *has classes like *Handshaker.class, SSLContextImpl.class, HandShakeMessage.class* inside the sun.security.ssl package which do the actual SSL Handshake. There are many more classes inside this package. So wanted clarification on this. Thanks Ayas On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey wrote: > > On 01/06/2016 03:42, Jim Manico wrote: > > I think this is the right answer. > > From > https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support > > The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE > suites *IF there is an available (JCE) provider* for needed ECC > primitives. *Java 1.6 OOTB does NOT* include such an ECC provider, but > you can add one. *Java 7 and 8 do* include SunECC provider. > > I don't believe Ayaskant's query was specific to ECC. In any case, the > above answer isn't accurate. ECC support is available OOTB in JDK > 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC provider > was added in JDK 7: > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC > > regards, > Sean. > > - Jim > > On 5/29/16 8:02 PM, Ayaskant Swain wrote: > > Hi, > > Can anyone please help me know about this - Does JSSE library implement > the Ciphers or Algorithms of a SSL protocol ? I see the jsse.jar library > shipped with the JDK. I read the the Oracle document about JSSE - > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction > > So my question is - does the JSSE implement the Ciphers or Algorithms that > are used for a successful SSL handshake , server authentication, data > integrity & data confidentiality (Application data encryption). > > Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or * > *TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* > > So is the coding of the above ciphers have been done in the JSSE library? > > Thanks > Ayaskant > Bangalore > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayaskant.swain at gmail.com Wed Jun 1 08:30:13 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Wed, 1 Jun 2016 14:00:13 +0530 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: <7a8b6fae-f6a3-c4ff-68d1-86be6c245f8f@oracle.com> References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> <7a8b6fae-f6a3-c4ff-68d1-86be6c245f8f@oracle.com> Message-ID: Thank you Sean. :-) I will try it out. Ayas On Wed, Jun 1, 2016 at 1:50 PM, Se?n Coffey wrote: > The JDK pulls crypto operations from different providers to complete > operations (like TLS handshakes). The jsse.jar file is primarily tasked > with handling TLS operations but will call into other providers (jars) > where necessary. That's all controlled by the security provider framework. > > If you're interested in seeing exactly what providers are in use, you can > use the -Djava.security.debug=provider property. It'll print that > information in verbose detail. That extra output is available in 7u80, 8u40 > and later JDKs : https://bugs.openjdk.java.net/browse/JDK-8056026 > > Regards, > Sean. > > On 01/06/2016 09:06, Ayaskant Swain wrote: > > Hi All, > > My question was not specific to those two cipher suites that I had pasted > in my query. I had just pasted them as examples. Rather my question was > generic. > > I want to know which library or packages in JDK implement the > Algorithms/Ciphers that are used for SSL communication? > > If java provides the implementation of those cryptographic Algos through > the *java.security , java.net.ssl & javax.crypto* packages then what is > the role of the *jsse.jar* library that ships in as part of the *JAVA_HOME/ > jre/lib* directory? > > I could clearly see the *jsse.jar *has classes like *Handshaker.class, > SSLContextImpl.class, HandShakeMessage.class* inside the sun.security.ssl > package which do the actual SSL Handshake. There are many more classes > inside this package. > > So wanted clarification on this. > > Thanks > Ayas > > On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey > wrote: > >> >> On 01/06/2016 03:42, Jim Manico wrote: >> >> I think this is the right answer. >> >> From >> https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support >> >> The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE >> suites *IF there is an available (JCE) provider* for needed ECC >> primitives. *Java 1.6 OOTB does NOT* include such an ECC provider, but >> you can add one. *Java 7 and 8 do* include SunECC provider. >> >> I don't believe Ayaskant's query was specific to ECC. In any case, the >> above answer isn't accurate. ECC support is available OOTB in JDK >> 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC provider >> was added in JDK 7: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC >> >> regards, >> Sean. >> >> - Jim >> >> On 5/29/16 8:02 PM, Ayaskant Swain wrote: >> >> Hi, >> >> Can anyone please help me know about this - Does JSSE library implement >> the Ciphers or Algorithms of a SSL protocol ? I see the jsse.jar library >> shipped with the JDK. I read the the Oracle document about JSSE - >> >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >> >> So my question is - does the JSSE implement the Ciphers or Algorithms >> that are used for a successful SSL handshake , server authentication, data >> integrity & data confidentiality (Application data encryption). >> >> Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or * >> *TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >> >> So is the coding of the above ciphers have been done in the JSSE library? >> >> Thanks >> Ayaskant >> Bangalore >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Wed Jun 1 18:43:41 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 1 Jun 2016 11:43:41 -0700 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> Message-ID: <1388ea66-1c40-04c1-a97b-e7a93c39968b@oracle.com> Hopefully this makes it clear. For JSSE, javax.net/javax.net.ssl (in rt.jar) contains the APIs which call into JSSE providers. sun.security.ssl (contained in jsse.jar) is one such provider. The JSSE implementation contains routines specific to TLS, but eventually calls into JCA/JCE for specific crypto algorithms (e.g. RSA/AES/SHA/DH/ECDH/etc). The JCA/JCE framework consults its list of installed providers, and finds the first available implementation of whatever is needed. If it can't find something, that ciphersuite has to be disabled. Going back to the followup question, on JDK 6, if JCA/JCE can't find a registered ECC provider, then it must disable the ECC-based suites. As Sean said, Solaris has ECC through PKCS11, so OOTB ECC-based suites should work on JDK 6 if you're on Solaris. If on something else, you need to install an ECC provider to get ECC-based suite. Brad On 6/1/2016 1:06 AM, Ayaskant Swain wrote: > Hi All, > > My question was not specific to those two cipher suites that I had > pasted in my query. I had just pasted them as examples. Rather my > question was generic. > > I want to know which library or packages in JDK implement the > Algorithms/Ciphers that are used for SSL communication? > > If java provides the implementation of those cryptographic Algos through > the *java.security , java.net.ssl & javax.crypto* packages then what is > the role of the *jsse.jar* library that ships in as part of the > *JAVA_HOME/ jre/lib* directory? > > I could clearly see the *jsse.jar *has classes like *Handshaker.class, > SSLContextImpl.class, HandShakeMessage.class* inside the > sun.security.ssl package which do the actual SSL Handshake. There are > many more classes inside this package. > > So wanted clarification on this. > > Thanks > Ayas > > On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey > wrote: > > > On 01/06/2016 03:42, Jim Manico wrote: >> >> I think this is the right answer. >> >> From >> https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support >> >> The SSL/TLS implementation "JSSE" in Java 1.6 and later supports >> ECDHE suites *IF there is an available (JCE) provider* for needed >> ECC primitives. *Java 1.6 OOTB does NOT* include such an ECC >> provider, but you can add one. *Java 7 and 8 do* include SunECC >> provider. >> > I don't believe Ayaskant's query was specific to ECC. In any case, > the above answer isn't accurate. ECC support is available OOTB in JDK > 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC > provider was added in JDK 7: > http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC > > regards, > Sean. >> >> - Jim >> >> >> On 5/29/16 8:02 PM, Ayaskant Swain wrote: >>> Hi, >>> >>> Can anyone please help me know about this - Does JSSE library >>> implement the Ciphers or Algorithms of a SSL protocol ? I see the >>> jsse.jar library shipped with the JDK. I read the the Oracle >>> document about JSSE >>> - http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >>> >>> So my question is - does the JSSE implement the Ciphers or >>> Algorithms that are used for a successful SSL handshake , server >>> authentication, data integrity & data confidentiality >>> (Application data encryption). >>> >>> Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>> or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >>> * >>> * >>> So is the coding of the above ciphers have been done in the JSSE >>> library? >>> >>> Thanks >>> Ayaskant >>> Bangalore >> > > From sha.jiang at oracle.com Thu Jun 2 06:11:19 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 2 Jun 2016 14:11:19 +0800 Subject: [9] RFR: JDK-8158462: CipherTest should get rid of race condition Message-ID: Hi, Please review this patch on resolving possible race condition for the following tests: javax/net/ssl/sanity/interop/CipherTest.java sun/security/pkcs11/fips/CipherTest.java sun/security/pkcs11/sslecc/CipherTest.java Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8158462 Best regards, John Jiang From tiantian.du at oracle.com Thu Jun 2 10:16:24 2016 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 2 Jun 2016 18:16:24 +0800 Subject: [9] RFR:JDK-8143305:sun/security/ec/TestEC.java fails intermittently Message-ID: <57500778.2080307@oracle.com> Hi, Please help to review the path for JDK-8143305 TestEC.java test for ECC algorithms in SSL/TLS with different cipher suites. It failed with javax.net.ssl.SSLException: Unsupported or unrecognized SSL message intermittently. The exception was threw at step of handshaking, I was not able to reproduce this failures. Suggesting to enable the debug option,so that it could print more information to logs. Hope get helpful information and do future evaluation in next failures. JBS: https://bugs.openjdk.java.net/browse/JDK-8143305 webrev: http://cr.openjdk.java.net/~tidu/8143305/webrev.01/ Regards Tim From sha.jiang at oracle.com Thu Jun 2 12:54:45 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 2 Jun 2016 20:54:45 +0800 Subject: [9] RFR: JDK-8158462: CipherTest should get rid of race condition In-Reply-To: References: Message-ID: Hi, Please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.01 I just updated the year in copyright notice. Best regards, John Jiang On 2016/6/2 14:11, John Jiang wrote: > Hi, > Please review this patch on resolving possible race condition for the > following tests: > javax/net/ssl/sanity/interop/CipherTest.java > sun/security/pkcs11/fips/CipherTest.java > sun/security/pkcs11/sslecc/CipherTest.java > > Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8158462 > > Best regards, > John Jiang > > From simone.bordet at gmail.com Thu Jun 2 14:34:12 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 2 Jun 2016 16:34:12 +0200 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565E3599.3060201@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565E3599.3060201@oracle.com> Message-ID: Hi, On Wed, Dec 2, 2015 at 1:04 AM, Bradford Wetmore wrote: > Filling in a few more details [for server parsing] > > SSLContext.getInstance("protocol"); // returns a context with > // "protocol" and possibly > // other protocols enabled. > SSLEngine ssle = SSLContext.createSSLEngine(...); > > Read ClientHello from Socket/SocketChannel/AsynchronousSocketChannel/etc. > > Parse ClientHello for requested protocol/alpn/ciphersuites > > choose protocol/alpn/ciphersuite value(s) I'm trying to give this a go in Jetty and I stumbled into this problem: when Jetty parses the ClientHello, it parses the ciphers in the TLS format of 2 bytes. For example, the ClientHello contains the cipher (0x00, 0x00). I would need a way to convert the 2-bytes duple into the corresponding cipher string. For this example, it would be: "TLS_NULL_WITH_NULL_NULL". Turns out that the JDK can do this via: CipherSuite cipher = sun.security.ssl.CipherSuite.valueOf(byte1, byte2); String name = cipher.name; Unfortunately, class CipherSuite is package local, and in sun.* package. Would be great if there was a standard way of going from the duple to the string. Having the cipher string would allow applications to compare what parsed with application configurations strings, and it would match with methods such as SSLEngine.getEnabledCipherSuites(), etc. which handle String[]. Having the JDK to provide this facility would guarantee that the naming is always consistent, and that it is always up-to-date with the JDK in use. Looking forward to your comments. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Thu Jun 2 16:09:23 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jun 2016 12:09:23 -0400 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> Message-ID: <57505A33.6030509@oracle.com> For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? Otherwise this looks good, though may I suggest you adjust the bug synopsis to be less generic? How about: "Make AbstractDrbg non-Serializable". --Sean On 05/23/2016 06:39 PM, Wang Weijun wrote: > Ping again. > >> ? 2016?5?19??16:21?Wang Weijun ??? >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ >> >> Now that DRBG does not save any internal state during >> serialization, all DRBG implementations (HashDrbg, HmacDrbg, >> CtrDrbg) still extends SecureRandomSpi and contain quite some >> @serial fields. If some of them is corrupted a deserialized DRBG >> may run expectedly, it also prevents class evolution. >> >> The fix is to make AbstractDrbg no more a SecureRandomSpi child so >> no more serializable. DRBG is still a SecureRandomSpi child and its >> only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is >> also made serializable. >> >> One new test is added. Since AbstractDrbg is no longer a >> SecureRandomSpi, its child class can no longer be registered in a >> SecureRandom provider, and the AbstractDrbgSpec.java test is >> removed. >> >> Thanks Max >> > From ayaskant.swain at gmail.com Thu Jun 2 14:55:39 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Thu, 2 Jun 2016 20:25:39 +0530 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: <1388ea66-1c40-04c1-a97b-e7a93c39968b@oracle.com> References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> <1388ea66-1c40-04c1-a97b-e7a93c39968b@oracle.com> Message-ID: Thanks a lot Brad ! You have nailed it & I was looking for this answer only :-). So is *jsse.jar* the default security provider for Java? Can you also give some examples of other security providers? Is it the security providers who actually implement the underlying Ciphers or crytographic Algorithms? Thanks Ayas On Thu, Jun 2, 2016 at 12:13 AM, Bradford Wetmore < bradford.wetmore at oracle.com> wrote: > Hopefully this makes it clear. > > For JSSE, javax.net/javax.net.ssl (in rt.jar) contains the APIs which > call into JSSE providers. sun.security.ssl (contained in jsse.jar) is one > such provider. The JSSE implementation contains routines specific to TLS, > but eventually calls into JCA/JCE for specific crypto algorithms (e.g. > RSA/AES/SHA/DH/ECDH/etc). The JCA/JCE framework consults its list of > installed providers, and finds the first available implementation of > whatever is needed. If it can't find something, that ciphersuite has to be > disabled. > > Going back to the followup question, on JDK 6, if JCA/JCE can't find a > registered ECC provider, then it must disable the ECC-based suites. As > Sean said, Solaris has ECC through PKCS11, so OOTB ECC-based suites should > work on JDK 6 if you're on Solaris. If on something else, you need to > install an ECC provider to get ECC-based suite. > > Brad > > > > > On 6/1/2016 1:06 AM, Ayaskant Swain wrote: > >> Hi All, >> >> My question was not specific to those two cipher suites that I had >> pasted in my query. I had just pasted them as examples. Rather my >> question was generic. >> >> I want to know which library or packages in JDK implement the >> Algorithms/Ciphers that are used for SSL communication? >> >> If java provides the implementation of those cryptographic Algos through >> the *java.security , java.net.ssl & javax.crypto* packages then what is >> the role of the *jsse.jar* library that ships in as part of the >> *JAVA_HOME/ jre/lib* directory? >> >> I could clearly see the *jsse.jar *has classes like *Handshaker.class, >> SSLContextImpl.class, HandShakeMessage.class* inside the >> sun.security.ssl package which do the actual SSL Handshake. There are >> many more classes inside this package. >> >> So wanted clarification on this. >> >> Thanks >> Ayas >> >> On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey > > wrote: >> >> >> On 01/06/2016 03:42, Jim Manico wrote: >> >>> >>> I think this is the right answer. >>> >>> From >>> >>> https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support >>> >>> The SSL/TLS implementation "JSSE" in Java 1.6 and later supports >>> ECDHE suites *IF there is an available (JCE) provider* for needed >>> ECC primitives. *Java 1.6 OOTB does NOT* include such an ECC >>> provider, but you can add one. *Java 7 and 8 do* include SunECC >>> provider. >>> >>> I don't believe Ayaskant's query was specific to ECC. In any case, >> the above answer isn't accurate. ECC support is available OOTB in JDK >> 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC >> provider was added in JDK 7: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC >> >> regards, >> Sean. >> >>> >>> - Jim >>> >>> >>> On 5/29/16 8:02 PM, Ayaskant Swain wrote: >>> >>>> Hi, >>>> >>>> Can anyone please help me know about this - Does JSSE library >>>> implement the Ciphers or Algorithms of a SSL protocol ? I see the >>>> jsse.jar library shipped with the JDK. I read the the Oracle >>>> document about JSSE >>>> - < >>>> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >>>> > >>>> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >>>> >>>> So my question is - does the JSSE implement the Ciphers or >>>> Algorithms that are used for a successful SSL handshake , server >>>> authentication, data integrity & data confidentiality >>>> (Application data encryption). >>>> >>>> Example of cipher suites - *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>>> or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >>>> * >>>> * >>>> So is the coding of the above ciphers have been done in the JSSE >>>> library? >>>> >>>> Thanks >>>> Ayaskant >>>> Bangalore >>>> >>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Thu Jun 2 17:36:29 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 2 Jun 2016 10:36:29 -0700 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> <1388ea66-1c40-04c1-a97b-e7a93c39968b@oracle.com> Message-ID: <3c4ca21b-4f46-9a04-bdf3-894f3257bafa@oracle.com> > So is *jsse.jar* the default security provider for Java? Can you also > give some examples of other security providers? > > Is it the security providers who actually implement the underlying > Ciphers or crytographic Algorithms? There are many Oracle providers that provide different algorithms. I think you may not have grasped the Provider-based mechanism yet. Please see the documentation: http://docs.oracle.com/javase/8/docs/technotes/guides/security/ Specifically: Java Cryptography Architecture (JCA) Reference Guide specifically the "Cryptographic Service Providers" section. Standard Algorithm Names Oracle Providers Brad > > Thanks > Ayas > > On Thu, Jun 2, 2016 at 12:13 AM, Bradford Wetmore > > wrote: > > Hopefully this makes it clear. > > For JSSE, javax.net/javax.net.ssl > (in rt.jar) contains the APIs which call into JSSE providers. > sun.security.ssl (contained in jsse.jar) is one such provider. The > JSSE implementation contains routines specific to TLS, but > eventually calls into JCA/JCE for specific crypto algorithms (e.g. > RSA/AES/SHA/DH/ECDH/etc). The JCA/JCE framework consults its list > of installed providers, and finds the first available implementation > of whatever is needed. If it can't find something, that ciphersuite > has to be disabled. > > Going back to the followup question, on JDK 6, if JCA/JCE can't find > a registered ECC provider, then it must disable the ECC-based > suites. As Sean said, Solaris has ECC through PKCS11, so OOTB > ECC-based suites should work on JDK 6 if you're on Solaris. If on > something else, you need to install an ECC provider to get ECC-based > suite. > > Brad > > > > > On 6/1/2016 1:06 AM, Ayaskant Swain wrote: > > Hi All, > > My question was not specific to those two cipher suites that I had > pasted in my query. I had just pasted them as examples. Rather my > question was generic. > > I want to know which library or packages in JDK implement the > Algorithms/Ciphers that are used for SSL communication? > > If java provides the implementation of those cryptographic Algos > through > the *java.security , java.net.ssl & javax.crypto* packages then > what is > the role of the *jsse.jar* library that ships in as part of the > *JAVA_HOME/ jre/lib* directory? > > I could clearly see the *jsse.jar *has classes like > *Handshaker.class, > SSLContextImpl.class, HandShakeMessage.class* inside the > sun.security.ssl package which do the actual SSL Handshake. > There are > many more classes inside this package. > > So wanted clarification on this. > > Thanks > Ayas > > On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey > > >> > wrote: > > > On 01/06/2016 03:42, Jim Manico wrote: > > > I think this is the right answer. > > From > > https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support > > The SSL/TLS implementation "JSSE" in Java 1.6 and later > supports > ECDHE suites *IF there is an available (JCE) provider* > for needed > ECC primitives. *Java 1.6 OOTB does NOT* include such an ECC > provider, but you can add one. *Java 7 and 8 do* include > SunECC > provider. > > I don't believe Ayaskant's query was specific to ECC. In any > case, > the above answer isn't accurate. ECC support is available > OOTB in JDK > 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC > provider was added in JDK 7: > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC > > regards, > Sean. > > > - Jim > > > On 5/29/16 8:02 PM, Ayaskant Swain wrote: > > Hi, > > Can anyone please help me know about this - Does > JSSE library > implement the Ciphers or Algorithms of a SSL > protocol ? I see the > jsse.jar library shipped with the JDK. I read the > the Oracle > document about JSSE > - > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction > > So my question is - does the JSSE implement the > Ciphers or > Algorithms that are used for a successful SSL > handshake , server > authentication, data integrity & data confidentiality > (Application data encryption). > > Example of cipher suites - > *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* > * > * > So is the coding of the above ciphers have been done > in the JSSE > library? > > Thanks > Ayaskant > Bangalore > > > > > From bradford.wetmore at oracle.com Thu Jun 2 18:20:50 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 2 Jun 2016 11:20:50 -0700 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565E3599.3060201@oracle.com> Message-ID: <46280649-e5a8-8615-b02c-58379cde5226@oracle.com> Hi Simone, I agree with you, it would be handy. As part of the HTTPS 2.0 prohibited suites for ALPN, I wanted to do just such a convenience mapping in javax.net.ssl.StandardConstants.java: http://cr.openjdk.java.net/~wetmore/8051498/webrev.16/src/java.base/share/classes/javax/net/ssl/StandardConstants.java.frames.html public static final Map cipherSuiteIntToString but was shot down and finally gave up. We'd need to consider more how to expose some of the TLS internals that we don't currently do right now. (e.g. at the API layer or as a provider (SPI) call.) One of the problems you may not have noticed is also historical, in that JSSE was first released around the time of the finalization of TLSv1, so there is a mix of SSL_/TLS_ prefix for the older algorithms. The TLS standard name String "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is actually the SSLv3/Java Standard Name "SSL_RSA_WITH_3DES_EDE_CBC_SHA", which was set during the original SSLv3 spec, which later became the "Historic" RFC 6101. FYI, in JDK 9, you will lose the ability to call valueOf() due to modular encapsulation. We can file a RFE to do this. Since JDK 9 just went FC last week, it will likely need to be a JDK 10 RFE. My workaround/suggestion for now is to implement your own: 1. Grab the section http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 2. Compare with StandardConstants.java above to get the SSL_/TLS_ standard names. The names in StandardConstants.java was complete through the end of 2015. I hope to add this when I rework the SSLExplorer sample code for the JDK 9 docs. Cheers, Brad On 6/2/2016 7:34 AM, Simone Bordet wrote: > Hi, > > On Wed, Dec 2, 2015 at 1:04 AM, Bradford Wetmore > wrote: >> Filling in a few more details [for server parsing] >> >> SSLContext.getInstance("protocol"); // returns a context with >> // "protocol" and possibly >> // other protocols enabled. >> SSLEngine ssle = SSLContext.createSSLEngine(...); >> >> Read ClientHello from Socket/SocketChannel/AsynchronousSocketChannel/etc. >> >> Parse ClientHello for requested protocol/alpn/ciphersuites >> >> choose protocol/alpn/ciphersuite value(s) > > I'm trying to give this a go in Jetty and I stumbled into this > problem: when Jetty parses the ClientHello, it parses the ciphers in > the TLS format of 2 bytes. > > For example, the ClientHello contains the cipher (0x00, 0x00). > I would need a way to convert the 2-bytes duple into the corresponding > cipher string. > For this example, it would be: "TLS_NULL_WITH_NULL_NULL". > > Turns out that the JDK can do this via: > > CipherSuite cipher = sun.security.ssl.CipherSuite.valueOf(byte1, byte2); > String name = cipher.name; > > Unfortunately, class CipherSuite is package local, and in sun.* package. > > Would be great if there was a standard way of going from the duple to > the string. > > Having the cipher string would allow applications to compare what > parsed with application configurations strings, and it would match > with methods such as SSLEngine.getEnabledCipherSuites(), etc. which > handle String[]. > > Having the JDK to provide this facility would guarantee that the > naming is always consistent, and that it is always up-to-date with the > JDK in use. > > Looking forward to your comments. > > Thanks ! > From sean.mullan at oracle.com Thu Jun 2 18:53:31 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jun 2016 14:53:31 -0400 Subject: RFR: 8154009: Some methods of java.security.Security require more permissions, than necessary In-Reply-To: References: <574C3A37.7010607@oracle.com> <574EEB38.50209@oracle.com> Message-ID: <575080AB.2070500@oracle.com> Looks good. --Sean On 06/01/2016 10:56 AM, Artem Kosarev wrote: > Hi Sean. > > Thanks for suggestion. > > New WebRev: http://cr.openjdk.java.net/~akosarev/8154009/webrev.01/ > > There are only 2 changes from original one: > 1) *test/java/security/Security/EmptyPolicy.policy* was updated in the > way you proposed. > 2) I removed 2 tests from *test/ProblemList.txt*, which were marked as > failed due to JDK-8154009 (current fix). > > Best regards, > Artem Kosarev. > > ** > On 01.06.2016 17:03, Sean Mullan wrote: >> I think it would be helpful to add a comment to EmptyPolicy.policy so >> it contains something, ex: >> >> // empty policy file for testing >> >> Otherwise, looks fine. >> >> --Sean >> >> On 05/30/2016 09:03 AM, Artem Kosarev wrote: >>> Hello. >>> >>> Could you please review the proposed fix issue which is NOT applicable >>> for JDK 9: >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154009 >>> WEBREV: http://cr.openjdk.java.net/~akosarev/8154009/webrev.00/ >>> >>> PROBLEM: >>> **/AddProvider/, /RemoveProvider///& /GetProviders///methods >>> of*//**/java.security.Security/* class results in calling >>> /doLoadProvider /method of *ProviderConfig *class for each Security >>> Provider. >>> And in this method we have a problem that it catches and processes >>> *Exception*, but doesn't process *ExceptionInInitializerError *which is >>> thrown in case of missing permissions: >>> permission java.lang.RuntimePermission "loadLibrary.*"; >>> permission java.io.FilePermission "<>", "read"; >>> permission java.lang.RuntimePermission >>> "accessClassInPackage.sun.security.*"; >>> Those permissions are unavailable if we switch-off >>> *jre/lib/security/java.policy* file by running program with option: >>> /-Djava.security.policy==/ >>> >>> FIX: >>> In JDK9 *ProviderConfig *class is changed in the scope of >>> JDK-8043406 >>> enhancement (that is why JDK-8154009 is not applicable for JDK 9). >>> And in order to fix above problem in JDK 8 we just require to take >>> same changes for *ProviderConfig *class in JDK 9: >>> See changeset from JDK 9: >>> http://hg.openjdk.java.net/jdk9/dev/jdk/diff/7f8294841146/src/share/classes/sun/security/jca/ProviderConfig.java >>> >>> >>> REGRESSION TESTS: >>> 2 existing tests (*AddProvider*, *RemoveStaticProvider*) were used >>> and modified so that they provide testing for fixed situation >>> (additional permissions are not required any longer for /AddProvider >>> /&**/RemoveProvider /methods.) >>> 1 new test was written for checking /GetProviders /method under >>> restricted permissions. >>> >>> Changes were successfully tested by JPRT. >>> >>> Best regards, >>> Artem Kosarev. >> > From sean.mullan at oracle.com Thu Jun 2 20:38:32 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Jun 2016 16:38:32 -0400 Subject: [9] RFR:JDK-8143305:sun/security/ec/TestEC.java fails intermittently In-Reply-To: <57500778.2080307@oracle.com> References: <57500778.2080307@oracle.com> Message-ID: <57509948.3030203@oracle.com> On 06/02/2016 06:16 AM, Tim Du wrote: > Hi, > > Please help to review the path for JDK-8143305 > > TestEC.java test for ECC algorithms in SSL/TLS with different cipher > suites. It failed with javax.net.ssl.SSLException: Unsupported or > unrecognized SSL message intermittently. > > The exception was threw at step of handshaking, I was not able to > reproduce this failures. Suggesting to enable the debug option,so that > it could print more information to logs. Hope get helpful information > and do future evaluation in next failures. I think a new bug should be opened to add the debug option, since the intermittent failure has not been resolved. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8143305 > webrev: http://cr.openjdk.java.net/~tidu/8143305/webrev.01/ Can you add braces around the if statement on line 74-5? This is preferred style to accidentally avoid bracing mistakes. See also http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces --Sean From simone.bordet at gmail.com Thu Jun 2 20:40:49 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 2 Jun 2016 22:40:49 +0200 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <46280649-e5a8-8615-b02c-58379cde5226@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565E3599.3060201@oracle.com> <46280649-e5a8-8615-b02c-58379cde5226@oracle.com> Message-ID: Hi, On Thu, Jun 2, 2016 at 8:20 PM, Bradford Wetmore wrote: > Hi Simone, > > I agree with you, it would be handy. As part of the HTTPS 2.0 prohibited > suites for ALPN, I wanted to do just such a convenience mapping in > javax.net.ssl.StandardConstants.java: > > > http://cr.openjdk.java.net/~wetmore/8051498/webrev.16/src/java.base/share/classes/javax/net/ssl/StandardConstants.java.frames.html > > public static final Map cipherSuiteIntToString > > but was shot down and finally gave up. We'd need to consider more how to > expose some of the TLS internals that we don't currently do right now. > (e.g. at the API layer or as a provider (SPI) call.) > > One of the problems you may not have noticed is also historical, in that > JSSE was first released around the time of the finalization of TLSv1, so > there is a mix of SSL_/TLS_ prefix for the older algorithms. The TLS > standard name String "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is actually the > SSLv3/Java Standard Name "SSL_RSA_WITH_3DES_EDE_CBC_SHA", which was set > during the original SSLv3 spec, which later became the "Historic" RFC 6101. > > FYI, in JDK 9, you will lose the ability to call valueOf() due to modular > encapsulation. > > We can file a RFE to do this. Since JDK 9 just went FC last week, it will > likely need to be a JDK 10 RFE. Oh, no ! On net-dev we are still talking about changing the APIs for HttpClient and WebSocket client, so can I please ask that this does not get delayed another 5 years ? We explicitly asked on net-dev if there was a freeze, and they replied that it was still possible to change the APIs, so I presume it would be possible to add a simple class to javax.net.ssl ? It's a super simple class to expose, call it CipherNames, whose implementation will be trivial and based on sun.security.ssl.CipherSuite. Right now I am doing the same accessing CipherSuite via reflection on its private members. I don't know if I am late to the party or way too early, but I cannot believe that all others that are interested in ALPN in Java 9 went for a workaround instead of asking here whether the cipher names could have been exposed in a standard way. Considering the historical issue you mention it is important that there are no ambiguities in the cipher names, and having the JDK as the only source is really important. Can I ask you to reconsider this small change for JDK 9 ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From weijun.wang at oracle.com Fri Jun 3 01:42:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 3 Jun 2016 09:42:33 +0800 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <57505A33.6030509@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> <57505A33.6030509@oracle.com> Message-ID: > On Jun 3, 2016, at 12:09 AM, Sean Mullan wrote: > > For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? Not as much as before. I will find a way to add the test back. Thanks Max From weijun.wang at oracle.com Fri Jun 3 06:12:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 3 Jun 2016 14:12:36 +0800 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <57505A33.6030509@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> <57505A33.6030509@oracle.com> Message-ID: <163726B9-8E4A-41F0-A253-92E68C246D8B@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8157308/webrev.01/ AbstractDrbg is an internal class so I have to patch the JDK itself. Thanks Max > On Jun 3, 2016, at 12:09 AM, Sean Mullan wrote: > > For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? > > Otherwise this looks good, though may I suggest you adjust the bug synopsis to be less generic? How about: "Make AbstractDrbg non-Serializable". > > --Sean > > On 05/23/2016 06:39 PM, Wang Weijun wrote: >> Ping again. >> >>> ? 2016?5?19??16:21?Wang Weijun ??? >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ >>> >>> Now that DRBG does not save any internal state during >>> serialization, all DRBG implementations (HashDrbg, HmacDrbg, >>> CtrDrbg) still extends SecureRandomSpi and contain quite some >>> @serial fields. If some of them is corrupted a deserialized DRBG >>> may run expectedly, it also prevents class evolution. >>> >>> The fix is to make AbstractDrbg no more a SecureRandomSpi child so >>> no more serializable. DRBG is still a SecureRandomSpi child and its >>> only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is >>> also made serializable. >>> >>> One new test is added. Since AbstractDrbg is no longer a >>> SecureRandomSpi, its child class can no longer be registered in a >>> SecureRandom provider, and the AbstractDrbgSpec.java test is >>> removed. >>> >>> Thanks Max >>> >> From tiantian.du at oracle.com Fri Jun 3 07:52:20 2016 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 3 Jun 2016 15:52:20 +0800 Subject: [9] RFR:JDK-8143305:sun/security/ec/TestEC.java fails intermittently In-Reply-To: <57509948.3030203@oracle.com> References: <57500778.2080307@oracle.com> <57509948.3030203@oracle.com> Message-ID: <57513734.7060303@oracle.com> Thanks Sean and Xuelei I filed new bug for adding debug option,see https://bugs.openjdk.java.net/browse/JDK-8158620 The codes were also updated follow Sean's suggestion at here: http://cr.openjdk.java.net/~tidu/8158620/webrev.00/ Please help to review again.Thanks. Regards Tim On 2016/6/3 4:38, Sean Mullan wrote: > On 06/02/2016 06:16 AM, Tim Du wrote: >> Hi, >> >> Please help to review the path for JDK-8143305 >> >> TestEC.java test for ECC algorithms in SSL/TLS with different cipher >> suites. It failed with javax.net.ssl.SSLException: Unsupported or >> unrecognized SSL message intermittently. >> >> The exception was threw at step of handshaking, I was not able to >> reproduce this failures. Suggesting to enable the debug option,so that >> it could print more information to logs. Hope get helpful information >> and do future evaluation in next failures. > > I think a new bug should be opened to add the debug option, since the > intermittent failure has not been resolved. > >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8143305 >> webrev: http://cr.openjdk.java.net/~tidu/8143305/webrev.01/ > > Can you add braces around the if statement on line 74-5? This is > preferred style to accidentally avoid bracing mistakes. See also > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces > > --Sean From xuelei.fan at oracle.com Fri Jun 3 09:00:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 3 Jun 2016 17:00:23 +0800 Subject: [9] RFR:JDK-8143305:sun/security/ec/TestEC.java fails intermittently In-Reply-To: <57513734.7060303@oracle.com> References: <57500778.2080307@oracle.com> <57509948.3030203@oracle.com> <57513734.7060303@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/3/2016 3:52 PM, Tim Du wrote: > Thanks Sean and Xuelei > > I filed new bug for adding debug option,see > https://bugs.openjdk.java.net/browse/JDK-8158620 > The codes were also updated follow Sean's suggestion at here: > http://cr.openjdk.java.net/~tidu/8158620/webrev.00/ > Please help to review again.Thanks. > > Regards > Tim > On 2016/6/3 4:38, Sean Mullan wrote: >> On 06/02/2016 06:16 AM, Tim Du wrote: >>> Hi, >>> >>> Please help to review the path for JDK-8143305 >>> >>> TestEC.java test for ECC algorithms in SSL/TLS with different cipher >>> suites. It failed with javax.net.ssl.SSLException: Unsupported or >>> unrecognized SSL message intermittently. >>> >>> The exception was threw at step of handshaking, I was not able to >>> reproduce this failures. Suggesting to enable the debug option,so that >>> it could print more information to logs. Hope get helpful information >>> and do future evaluation in next failures. >> >> I think a new bug should be opened to add the debug option, since the >> intermittent failure has not been resolved. >> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143305 >>> webrev: http://cr.openjdk.java.net/~tidu/8143305/webrev.01/ >> >> Can you add braces around the if statement on line 74-5? This is >> preferred style to accidentally avoid bracing mistakes. See also >> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces >> >> --Sean > From sean.mullan at oracle.com Fri Jun 3 12:54:41 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 3 Jun 2016 08:54:41 -0400 Subject: [9] RFR:JDK-8143305:sun/security/ec/TestEC.java fails intermittently In-Reply-To: <57513734.7060303@oracle.com> References: <57500778.2080307@oracle.com> <57509948.3030203@oracle.com> <57513734.7060303@oracle.com> Message-ID: <57517E11.3090404@oracle.com> A small nit, but the debug field should be private (and final for good measure). I know this is just a test and it doesn't expose a security issue, but I think it is good practice to adhere to secure programming conventions even when writing tests. This field is only used within the test, so it should be private. There is no need to post another review after making this change, please go ahead and push the fix. Thanks, Sean On 06/03/2016 03:52 AM, Tim Du wrote: > Thanks Sean and Xuelei > > I filed new bug for adding debug option,see > https://bugs.openjdk.java.net/browse/JDK-8158620 > The codes were also updated follow Sean's suggestion at here: > http://cr.openjdk.java.net/~tidu/8158620/webrev.00/ > Please help to review again.Thanks. > > Regards > Tim > On 2016/6/3 4:38, Sean Mullan wrote: >> On 06/02/2016 06:16 AM, Tim Du wrote: >>> Hi, >>> >>> Please help to review the path for JDK-8143305 >>> >>> TestEC.java test for ECC algorithms in SSL/TLS with different cipher >>> suites. It failed with javax.net.ssl.SSLException: Unsupported or >>> unrecognized SSL message intermittently. >>> >>> The exception was threw at step of handshaking, I was not able to >>> reproduce this failures. Suggesting to enable the debug option,so that >>> it could print more information to logs. Hope get helpful information >>> and do future evaluation in next failures. >> >> I think a new bug should be opened to add the debug option, since the >> intermittent failure has not been resolved. >> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8143305 >>> webrev: http://cr.openjdk.java.net/~tidu/8143305/webrev.01/ >> >> Can you add braces around the if statement on line 74-5? This is >> preferred style to accidentally avoid bracing mistakes. See also >> http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces >> >> --Sean > From sean.mullan at oracle.com Fri Jun 3 14:02:50 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 3 Jun 2016 10:02:50 -0400 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <163726B9-8E4A-41F0-A253-92E68C246D8B@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> <57505A33.6030509@oracle.com> <163726B9-8E4A-41F0-A253-92E68C246D8B@oracle.com> Message-ID: <57518E0A.1070000@oracle.com> On 06/03/2016 02:12 AM, Wang Weijun wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8157308/webrev.01/ > > AbstractDrbg is an internal class so I have to patch the JDK itself. Hmm, ok, but why didn't you need to do that for the previous version of this test? --Sean > > Thanks > Max > >> On Jun 3, 2016, at 12:09 AM, Sean Mullan wrote: >> >> For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? >> >> Otherwise this looks good, though may I suggest you adjust the bug synopsis to be less generic? How about: "Make AbstractDrbg non-Serializable". >> >> --Sean >> >> On 05/23/2016 06:39 PM, Wang Weijun wrote: >>> Ping again. >>> >>>> ? 2016?5?19??16:21?Wang Weijun ??? >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ >>>> >>>> Now that DRBG does not save any internal state during >>>> serialization, all DRBG implementations (HashDrbg, HmacDrbg, >>>> CtrDrbg) still extends SecureRandomSpi and contain quite some >>>> @serial fields. If some of them is corrupted a deserialized DRBG >>>> may run expectedly, it also prevents class evolution. >>>> >>>> The fix is to make AbstractDrbg no more a SecureRandomSpi child so >>>> no more serializable. DRBG is still a SecureRandomSpi child and its >>>> only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is >>>> also made serializable. >>>> >>>> One new test is added. Since AbstractDrbg is no longer a >>>> SecureRandomSpi, its child class can no longer be registered in a >>>> SecureRandom provider, and the AbstractDrbgSpec.java test is >>>> removed. >>>> >>>> Thanks Max >>>> >>> > From weijun.wang at oracle.com Fri Jun 3 14:13:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 3 Jun 2016 22:13:32 +0800 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <57518E0A.1070000@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> <57505A33.6030509@oracle.com> <163726B9-8E4A-41F0-A253-92E68C246D8B@oracle.com> <57518E0A.1070000@oracle.com> Message-ID: <49FEF5D7-2EE6-4F39-A9DC-07227E2F09A0@oracle.com> > On Jun 3, 2016, at 10:02 PM, Sean Mullan wrote: > > On 06/03/2016 02:12 AM, Wang Weijun wrote: >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8157308/webrev.01/ >> >> AbstractDrbg is an internal class so I have to patch the JDK itself. > > Hmm, ok, but why didn't you need to do that for the previous version of this test? The reason is that the SecureRandomSpi implementation S needs to call impl.engineNextBytes() and this engineNextBytes method is not public. Before this change, there is no need to add this layer because AbstractDrbg itself is a SecureRandomSpi. Therefore, just like DRBG.java, S needs to be put in the same package as AbstractDrbg to be able to call the method. --Max > > --Sean > >> >> Thanks >> Max >> >>> On Jun 3, 2016, at 12:09 AM, Sean Mullan wrote: >>> >>> For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? >>> >>> Otherwise this looks good, though may I suggest you adjust the bug synopsis to be less generic? How about: "Make AbstractDrbg non-Serializable". >>> >>> --Sean >>> >>> On 05/23/2016 06:39 PM, Wang Weijun wrote: >>>> Ping again. >>>> >>>>> ? 2016?5?19??16:21?Wang Weijun ??? >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ >>>>> >>>>> Now that DRBG does not save any internal state during >>>>> serialization, all DRBG implementations (HashDrbg, HmacDrbg, >>>>> CtrDrbg) still extends SecureRandomSpi and contain quite some >>>>> @serial fields. If some of them is corrupted a deserialized DRBG >>>>> may run expectedly, it also prevents class evolution. >>>>> >>>>> The fix is to make AbstractDrbg no more a SecureRandomSpi child so >>>>> no more serializable. DRBG is still a SecureRandomSpi child and its >>>>> only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is >>>>> also made serializable. >>>>> >>>>> One new test is added. Since AbstractDrbg is no longer a >>>>> SecureRandomSpi, its child class can no longer be registered in a >>>>> SecureRandom provider, and the AbstractDrbgSpec.java test is >>>>> removed. >>>>> >>>>> Thanks Max >>>>> >>>> >> From artem.kosarev at oracle.com Fri Jun 3 15:57:03 2016 From: artem.kosarev at oracle.com (Artem Kosarev) Date: Fri, 3 Jun 2016 18:57:03 +0300 Subject: RFR: 8157603 TestCipher.java doesn't check one of the decrypted message as expected Message-ID: Could you please review the proposed fix for regression test BUGURL: https://bugs.openjdk.java.net/browse/JDK-8157603 WEBREV: http://cr.openjdk.java.net/~akosarev/8157603/webrev.00 DESCRIPTION: **Main problem is that we were not performing check that decryption into same buffer went correct. Instead, string created by decryption into another buffer was checked twice. Fix for the above issue was easy, but I also identified one more mistake: Initially, we were not calculating size of encrypted/decrypted messages when they were stored into the same buffer. After my fix their lengths will be calculated using values returned from /update /& /doFinal /methods. Moreover, I applied additional check on the length of crypted/decrypted messages. Changes were successfully tested by JPRT. Best regards, Artem Kosarev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jun 3 18:18:20 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 3 Jun 2016 14:18:20 -0400 Subject: RFR 8157308: DRBG serialization fix In-Reply-To: <49FEF5D7-2EE6-4F39-A9DC-07227E2F09A0@oracle.com> References: <4FC29F4B-6043-4482-9377-3E928227784B@oracle.com> <04FA1BAA-4A1D-429D-A49B-5AB6E3C8F476@oracle.com> <57505A33.6030509@oracle.com> <163726B9-8E4A-41F0-A253-92E68C246D8B@oracle.com> <57518E0A.1070000@oracle.com> <49FEF5D7-2EE6-4F39-A9DC-07227E2F09A0@oracle.com> Message-ID: <5751C9EC.1060508@oracle.com> On 06/03/2016 10:13 AM, Wang Weijun wrote: > >> On Jun 3, 2016, at 10:02 PM, Sean Mullan wrote: >> >> On 06/03/2016 02:12 AM, Wang Weijun wrote: >>> Webrev updated at >>> >>> http://cr.openjdk.java.net/~weijun/8157308/webrev.01/ >>> >>> AbstractDrbg is an internal class so I have to patch the JDK itself. >> >> Hmm, ok, but why didn't you need to do that for the previous version of this test? > > The reason is that the SecureRandomSpi implementation S needs to call impl.engineNextBytes() and this engineNextBytes method is not public. Before this change, there is no need to add this layer because AbstractDrbg itself is a SecureRandomSpi. > > Therefore, just like DRBG.java, S needs to be put in the same package as AbstractDrbg to be able to call the method. Ok, sounds good. --Sean > > --Max > >> >> --Sean >> >>> >>> Thanks >>> Max >>> >>>> On Jun 3, 2016, at 12:09 AM, Sean Mullan wrote: >>>> >>>> For the test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java that was removed, are you still getting adequate test coverage somewhere else on the SecureRandom API tests this test was checking? >>>> >>>> Otherwise this looks good, though may I suggest you adjust the bug synopsis to be less generic? How about: "Make AbstractDrbg non-Serializable". >>>> >>>> --Sean >>>> >>>> On 05/23/2016 06:39 PM, Wang Weijun wrote: >>>>> Ping again. >>>>> >>>>>> ? 2016?5?19??16:21?Wang Weijun ??? >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8157308/webrev.00/ >>>>>> >>>>>> Now that DRBG does not save any internal state during >>>>>> serialization, all DRBG implementations (HashDrbg, HmacDrbg, >>>>>> CtrDrbg) still extends SecureRandomSpi and contain quite some >>>>>> @serial fields. If some of them is corrupted a deserialized DRBG >>>>>> may run expectedly, it also prevents class evolution. >>>>>> >>>>>> The fix is to make AbstractDrbg no more a SecureRandomSpi child so >>>>>> no more serializable. DRBG is still a SecureRandomSpi child and its >>>>>> only @serial field is MoreDrbgParameters mdp. MoreDrbgParamaters is >>>>>> also made serializable. >>>>>> >>>>>> One new test is added. Since AbstractDrbg is no longer a >>>>>> SecureRandomSpi, its child class can no longer be registered in a >>>>>> SecureRandom provider, and the AbstractDrbgSpec.java test is >>>>>> removed. >>>>>> >>>>>> Thanks Max >>>>>> >>>>> >>> > From ayaskant.swain at gmail.com Fri Jun 3 05:09:33 2016 From: ayaskant.swain at gmail.com (Ayaskant Swain) Date: Fri, 3 Jun 2016 10:39:33 +0530 Subject: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ? In-Reply-To: <3c4ca21b-4f46-9a04-bdf3-894f3257bafa@oracle.com> References: <932627b8-fc49-595a-c9e7-ad330f7a7a68@owasp.org> <1388ea66-1c40-04c1-a97b-e7a93c39968b@oracle.com> <3c4ca21b-4f46-9a04-bdf3-894f3257bafa@oracle.com> Message-ID: Hi Brad, Thanks for sending me the link. I had just started going through the JCA document but did not finish reading the doc when i asked my original question :-). I will go through these docs in detail. I saw this line *"Cryptographic implementations in the JDK are distributed through several different providers ("Sun", "SunJSSE", "SunJCE", "SunRsaSign")* " in this doc - http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html. This is a good piece of information. So, now i am able to understand the JCA mechanism better now. Thanks all for your replies. I am now done with my queries. Ayaskant On Thu, Jun 2, 2016 at 11:06 PM, Bradford Wetmore < bradford.wetmore at oracle.com> wrote: > > So is *jsse.jar* the default security provider for Java? Can you also > > give some examples of other security providers? > > > > Is it the security providers who actually implement the underlying > > Ciphers or crytographic Algorithms? > > There are many Oracle providers that provide different algorithms. > > I think you may not have grasped the Provider-based mechanism yet. Please > see the documentation: > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/ > > Specifically: > > Java Cryptography Architecture (JCA) Reference Guide > specifically the "Cryptographic Service Providers" section. > Standard Algorithm Names > Oracle Providers > > Brad > > > > >> Thanks >> Ayas >> >> On Thu, Jun 2, 2016 at 12:13 AM, Bradford Wetmore >> > wrote: >> >> Hopefully this makes it clear. >> >> For JSSE, javax.net/javax.net.ssl >> (in rt.jar) contains the APIs which call into JSSE providers. >> sun.security.ssl (contained in jsse.jar) is one such provider. The >> JSSE implementation contains routines specific to TLS, but >> eventually calls into JCA/JCE for specific crypto algorithms (e.g. >> RSA/AES/SHA/DH/ECDH/etc). The JCA/JCE framework consults its list >> of installed providers, and finds the first available implementation >> of whatever is needed. If it can't find something, that ciphersuite >> has to be disabled. >> >> Going back to the followup question, on JDK 6, if JCA/JCE can't find >> a registered ECC provider, then it must disable the ECC-based >> suites. As Sean said, Solaris has ECC through PKCS11, so OOTB >> ECC-based suites should work on JDK 6 if you're on Solaris. If on >> something else, you need to install an ECC provider to get ECC-based >> suite. >> >> Brad >> >> >> >> >> On 6/1/2016 1:06 AM, Ayaskant Swain wrote: >> >> Hi All, >> >> My question was not specific to those two cipher suites that I had >> pasted in my query. I had just pasted them as examples. Rather my >> question was generic. >> >> I want to know which library or packages in JDK implement the >> Algorithms/Ciphers that are used for SSL communication? >> >> If java provides the implementation of those cryptographic Algos >> through >> the *java.security , java.net.ssl & javax.crypto* packages then >> what is >> the role of the *jsse.jar* library that ships in as part of the >> *JAVA_HOME/ jre/lib* directory? >> >> I could clearly see the *jsse.jar *has classes like >> *Handshaker.class, >> SSLContextImpl.class, HandShakeMessage.class* inside the >> sun.security.ssl package which do the actual SSL Handshake. >> There are >> many more classes inside this package. >> >> So wanted clarification on this. >> >> Thanks >> Ayas >> >> On Wed, Jun 1, 2016 at 1:22 PM, Se?n Coffey >> >> >> >> wrote: >> >> >> On 01/06/2016 03:42, Jim Manico wrote: >> >> >> I think this is the right answer. >> >> From >> >> >> https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support >> >> The SSL/TLS implementation "JSSE" in Java 1.6 and later >> supports >> ECDHE suites *IF there is an available (JCE) provider* >> for needed >> ECC primitives. *Java 1.6 OOTB does NOT* include such an >> ECC >> provider, but you can add one. *Java 7 and 8 do* include >> SunECC >> provider. >> >> I don't believe Ayaskant's query was specific to ECC. In any >> case, >> the above answer isn't accurate. ECC support is available >> OOTB in JDK >> 6 for Solaris. It's provided via the SunPKCS11 provider. SunEC >> provider was added in JDK 7: >> >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC >> >> regards, >> Sean. >> >> >> - Jim >> >> >> On 5/29/16 8:02 PM, Ayaskant Swain wrote: >> >> Hi, >> >> Can anyone please help me know about this - Does >> JSSE library >> implement the Ciphers or Algorithms of a SSL >> protocol ? I see the >> jsse.jar library shipped with the JDK. I read the >> the Oracle >> document about JSSE >> - >> < >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >> > >> http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction >> >> So my question is - does the JSSE implement the >> Ciphers or >> Algorithms that are used for a successful SSL >> handshake , server >> authentication, data integrity & data confidentiality >> (Application data encryption). >> >> Example of cipher suites - >> *TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> or **TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* >> * >> * >> So is the coding of the above ciphers have been done >> in the JSSE >> library? >> >> Thanks >> Ayaskant >> Bangalore >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Jun 3 22:35:02 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 03 Jun 2016 15:35:02 -0700 Subject: RFR: 8157603 TestCipher.java doesn't check one of the decrypted message as expected In-Reply-To: References: Message-ID: <57520616.9010201@oracle.com> Changes look fine. Thanks, Valerie On 6/3/2016 8:57 AM, Artem Kosarev wrote: > > Could you please review the proposed fix for regression test > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8157603 > WEBREV: http://cr.openjdk.java.net/~akosarev/8157603/webrev.00 > > DESCRIPTION: > **Main problem is that we were not performing check that decryption > into same buffer went correct. > Instead, string created by decryption into another buffer was > checked twice. > > Fix for the above issue was easy, but I also identified one more > mistake: > Initially, we were not calculating size of encrypted/decrypted > messages when they were stored into the same buffer. After my fix > their lengths will be calculated using values returned from /update /& > /doFinal /methods. > > Moreover, I applied additional check on the length of > crypted/decrypted messages. > > > Changes were successfully tested by JPRT. > > > Best regards, > Artem Kosarev. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Jun 4 00:32:08 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 4 Jun 2016 08:32:08 +0800 Subject: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout In-Reply-To: References: Message-ID: <1ed32268-fc9c-c779-1346-d5b924d564e9@oracle.com> SupportedDSAParamGen.java ========================= Please use more large timeout. The update from 450 to 550 may be not significant enough to prevent intermittent failure. I may use bigger value, 600 or even bigger? The same comment for TestDSAGenParameterSpec.java. Thanks, Xuelei On 5/31/2016 11:04 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the fix for the following JBS bugs, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157896 > > https://bugs.openjdk.java.net/browse/JDK-8157898 > > > > webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.00/ > > > > Description: > > These Tests takes a lots of time to generate DSA parameter when the > prime and subprime values are greater in some machine with some > platform. The reason is being the operations are CPU intensive, which > causes the Tests to timeout in rare occasion. But the Test performance > can be improved by, instead of generating DSA parameter with all > supported input in a single run, it can be divided for each input as a > separate run, so that each run can complete much before compared to all > input at once. It also provides the flexibility to associate test > options like ?timeout? for specific input type where the execution time > is expected to exceed the default. > > > > Note: The fix won?t give a guarantee that the timeout will never happen > but it can surely help reduce the timeout in greater extent. Please > provide your suggestion, in case any. > > > > > > Thanks, > > Siba > > > From jim.manico at owasp.org Sun Jun 5 00:51:59 2016 From: jim.manico at owasp.org (Jim Manico) Date: Sat, 4 Jun 2016 14:51:59 -1000 Subject: Avoiding LDAP Injection with Java In-Reply-To: References: Message-ID: <198e6844-06d5-8bd1-e4be-152ab37565a2@owasp.org> Hello Java Security folk, OWASP is trying to provide relevant advice to developers about using LDAP securely. Our older wiki page on this topic is a bit out of date and we would love any guidance to help us make it more relevant (and accurate) for today's developers. https://www.owasp.org/index.php/Preventing_LDAP_Injection_in_Java So if your familiar with securely talking to LDAP from Java, do you have a moment to review what we have? Aloha, Jim Manico OWASP Volunteer From bhanu.prakash.gopularam at oracle.com Mon Jun 6 05:40:19 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Sun, 5 Jun 2016 22:40:19 -0700 (PDT) Subject: RFR 8062758: Update java/security/Security/ClassLoaderDeadlock/Deadlock2.sh with the removal of -Djava.ext.dirs In-Reply-To: <7ed9fc84-0ee0-4b4f-9ea0-e6adc1ff4d0f@default> References: <7ed9fc84-0ee0-4b4f-9ea0-e6adc1ff4d0f@default> Message-ID: <9ea80086-52a3-4d26-8b51-7c5ddedf4f2e@default> Hi all, Please review fix for following bug : Bug - https://bugs.openjdk.java.net/browse/JDK-8062758 Issue - Test java/security/Security/ClassLoaderDeadlock/Deadlock2.sh started failing after removal of java.ext.dirs option Actually the test loads two classes SunJCE provider class (uses ExtClassLoader in 8) and java.xml.parsers.DocumentBuilderFactory (loaded by bootstrap classloader) class using two separate threads simultaneously. In jdk-9 the provider classes are part of java.base and loaded by bootstrap loader. The ext classloader is replaced by platform classloader which is confined to load classes from modules only. Removing this particular test as scenario mentioned in it is not possible with new JDK-9 changes. Webrev - http://cr.openjdk.java.net/~bgopularam/8062758/webrev.00 Thank you, Bhanu From weijun.wang at oracle.com Mon Jun 6 06:22:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 6 Jun 2016 14:22:14 +0800 Subject: RFR 8158442: SecureRandomParameters missing "@since 9" Message-ID: I forgot to add "@since 9" in a new interface, please review this trivial change diff --git a/src/java.base/share/classes/java/security/SecureRandomParameters.java b/src/java.base/share/classes/java/security/SecureRandomParameters.java --- a/src/java.base/share/classes/java/security/SecureRandomParameters.java +++ b/src/java.base/share/classes/java/security/SecureRandomParameters.java @@ -33,6 +33,7 @@ * can be passed to those implementations that support them. * * @see DrbgParameters + * @since 9 */ public interface SecureRandomParameters { } Thanks Max From weijun.wang at oracle.com Mon Jun 6 10:34:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 6 Jun 2016 18:34:26 +0800 Subject: RFR 8156471: test/sun/security/krb5/auto/TestHosts should not be modified in-place Message-ID: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> Please review the change at http://cr.openjdk.java.net/~weijun/8156471/webrev.00/ Mark, I noticed a strange "irlga09" host name at the end of TestHosts [1]. Is it happened to be one of your test machines and you've added it with this test? I can remove it in this fix. Thanks Max [1] http://cr.openjdk.java.net/~msheppar/8134577/webrev.10/test/sun/security/krb5/auto/TestHosts.html From sean.mullan at oracle.com Mon Jun 6 12:00:19 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Jun 2016 08:00:19 -0400 Subject: RFR 8158442: SecureRandomParameters missing "@since 9" In-Reply-To: References: Message-ID: <575565D3.60702@oracle.com> Looks good. --Sean On 06/06/2016 02:22 AM, Wang Weijun wrote: > I forgot to add "@since 9" in a new interface, please review this trivial change > > diff --git a/src/java.base/share/classes/java/security/SecureRandomParameters.java b/src/java.base/share/classes/java/security/SecureRandomParameters.java > --- a/src/java.base/share/classes/java/security/SecureRandomParameters.java > +++ b/src/java.base/share/classes/java/security/SecureRandomParameters.java > @@ -33,6 +33,7 @@ > * can be passed to those implementations that support them. > * > * @see DrbgParameters > + * @since 9 > */ > public interface SecureRandomParameters { > } > > Thanks > Max > From sean.mullan at oracle.com Mon Jun 6 15:03:04 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Jun 2016 11:03:04 -0400 Subject: RFR 8062758: Update java/security/Security/ClassLoaderDeadlock/Deadlock2.sh with the removal of -Djava.ext.dirs In-Reply-To: <9ea80086-52a3-4d26-8b51-7c5ddedf4f2e@default> References: <7ed9fc84-0ee0-4b4f-9ea0-e6adc1ff4d0f@default> <9ea80086-52a3-4d26-8b51-7c5ddedf4f2e@default> Message-ID: <575590A8.5@oracle.com> Looks fine to me. Also copying Mandy to see if she is ok with this. --Sean On 06/06/2016 01:40 AM, Bhanu Gopularam wrote: > Hi all, > > Please review fix for following bug : > > Bug - https://bugs.openjdk.java.net/browse/JDK-8062758 > > Issue - Test java/security/Security/ClassLoaderDeadlock/Deadlock2.sh started failing after removal of java.ext.dirs option > > Actually the test loads two classes SunJCE provider class (uses ExtClassLoader in 8) and java.xml.parsers.DocumentBuilderFactory (loaded by bootstrap classloader) class using two separate threads simultaneously. In jdk-9 the provider classes are part of java.base and loaded by bootstrap loader. The ext classloader is replaced by platform classloader which is confined to load classes from modules only. Removing this particular test as scenario mentioned in it is not possible with new JDK-9 changes. > > Webrev - http://cr.openjdk.java.net/~bgopularam/8062758/webrev.00 > > Thank you, > Bhanu > From bradford.wetmore at oracle.com Mon Jun 6 18:42:43 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 6 Jun 2016 11:42:43 -0700 Subject: RFR 8158442: SecureRandomParameters missing "@since 9" In-Reply-To: References: Message-ID: <1b665dae-fcbd-8bd7-3f71-fb11131fa913@oracle.com> +1. All the classes in DrbgParameters are fine. ;) Brad On 6/5/2016 11:22 PM, Wang Weijun wrote: > I forgot to add "@since 9" in a new interface, please review this trivial change > > diff --git a/src/java.base/share/classes/java/security/SecureRandomParameters.java b/src/java.base/share/classes/java/security/SecureRandomParameters.java > --- a/src/java.base/share/classes/java/security/SecureRandomParameters.java > +++ b/src/java.base/share/classes/java/security/SecureRandomParameters.java > @@ -33,6 +33,7 @@ > * can be passed to those implementations that support them. > * > * @see DrbgParameters > + * @since 9 > */ > public interface SecureRandomParameters { > } > > Thanks > Max > From jon.berg at gmail.com Mon Jun 6 22:10:12 2016 From: jon.berg at gmail.com (Jon Berg) Date: Tue, 7 Jun 2016 00:10:12 +0200 Subject: is it possible in openjdk 9 to advertise application protocol in the tls handshake? Message-ID: Hi, Given that you are acting as a server, it would be nice to be able to offer "http/1.1" as application. The purpose of this is to get chrome to do tls false start which require that the server "advertise" http/1.1 in ALPN or NPN. In the tls handshake. To do this it is just and integer and that string that has to be included in the handshake message at the right place... >From looking at the api it seems that this is not supported. And from reading http://openjdk.java.net/jeps/244 it sounds as it does not advertise anything, but for a server socket it is an intersection of what the client sends and what the server is capable of. Can you confirm that this is not supported in openjdk 9? Thanks, Jon Berg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Mon Jun 6 22:43:25 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 7 Jun 2016 06:43:25 +0800 Subject: [9] RFR: JDK-8158462: CipherTest should get rid of race condition In-Reply-To: References: Message-ID: <596c2004-c504-235e-11ba-58c007dee7da@oracle.com> Hi, Please review this patch. Thanks! John Jiang On 2016/6/2 20:54, John Jiang wrote: > Hi, > Please review this updated webrev: > http://cr.openjdk.java.net/~jjiang/8158462/webrev.01 > I just updated the year in copyright notice. > > Best regards, > John Jiang > > On 2016/6/2 14:11, John Jiang wrote: >> Hi, >> Please review this patch on resolving possible race condition for the >> following tests: >> javax/net/ssl/sanity/interop/CipherTest.java >> sun/security/pkcs11/fips/CipherTest.java >> sun/security/pkcs11/sslecc/CipherTest.java >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8158462 >> >> Best regards, >> John Jiang >> >> > > From bradford.wetmore at oracle.com Mon Jun 6 23:52:32 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 6 Jun 2016 16:52:32 -0700 Subject: is it possible in openjdk 9 to advertise application protocol in the tls handshake? In-Reply-To: References: Message-ID: <881deaaa-fd1c-ba4c-dc25-203df96c7b86@oracle.com> JEP 244/ALPN, aka JDK-8144083/JDK-8051498 went into JDK 9 late last year. The API/design is at: https://bugs.openjdk.java.net/browse/JDK-8062848 In a nutshell, the client application sets the strings to send. The server application can parse the ClientHello if desired, and can do any SSLSocket/SSLEngine preconfiguration before starting the handshake. During handshaking, the server library code iterates its set values, and compares with what was received (i.e. server-preference) and chooses the first supported value. While the API could support either ALPN or NPN, OpenJDK only has ALPN support as NPN was on its way out at the time of the writing. Brad On 6/6/2016 3:10 PM, Jon Berg wrote: > Hi, > > Given that you are acting as a server, it would be nice to be able to offer > "http/1.1" as application. > > The purpose of this is to get chrome to do tls false start which require > that the server "advertise" http/1.1 in ALPN or NPN. In the tls handshake. > To do this it is just and integer and that string that has to be included > in the handshake message at the right place... > > From looking at the api it seems that this is not supported. > And from reading http://openjdk.java.net/jeps/244 it sounds as it does > not advertise anything, but for a server socket it is an intersection of > what > the client sends and what the server is capable of. > > Can you confirm that this is not supported in openjdk 9? > > Thanks, > Jon Berg. From xuelei.fan at oracle.com Tue Jun 7 01:44:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Jun 2016 09:44:48 +0800 Subject: [9] RFR: JDK-8158462: CipherTest should get rid of race condition In-Reply-To: <596c2004-c504-235e-11ba-58c007dee7da@oracle.com> References: <596c2004-c504-235e-11ba-58c007dee7da@oracle.com> Message-ID: <137a609d-7e72-1d70-aa89-6dc935d5b9ab@oracle.com> Hi John, If I understand correctly, you have the client side wait for a while so that the server can get run. This update may mitigate the race condition, but cannot get rid of the race condition. After the timeout, the server may still not ready. Did you catch a testing failure of the race condition? I was wondering after the server socket is created, it would be ready to accept client connections even the server thread does not call socket.accept() yet. It may be not necessary to have client wait for server thread ready in this context. A testing failure of the race condition would be helpful for further evaluation. Thanks, Xuelei On 6/7/2016 6:43 AM, John Jiang wrote: > Hi, > Please review this patch. Thanks! > > John Jiang > > > On 2016/6/2 20:54, John Jiang wrote: >> Hi, >> Please review this updated webrev: >> http://cr.openjdk.java.net/~jjiang/8158462/webrev.01 >> I just updated the year in copyright notice. >> >> Best regards, >> John Jiang >> >> On 2016/6/2 14:11, John Jiang wrote: >>> Hi, >>> Please review this patch on resolving possible race condition for the >>> following tests: >>> javax/net/ssl/sanity/interop/CipherTest.java >>> sun/security/pkcs11/fips/CipherTest.java >>> sun/security/pkcs11/sslecc/CipherTest.java >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158462 >>> >>> Best regards, >>> John Jiang >>> >>> >> >> > From weijun.wang at oracle.com Tue Jun 7 01:51:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 7 Jun 2016 09:51:33 +0800 Subject: RFR 8151836: keytool -importkeystore -help does not list option -destprotected Message-ID: I forgot to list (enum Option) DESTPROTECTED as an option of (enum Command) IMPORTKEYSTORE. Here is the fix. Please take a review: diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java @@ -206,7 +206,7 @@ IMPORTKEYSTORE("Imports.one.or.all.entries.from.another.keystore", SRCKEYSTORE, DESTKEYSTORE, SRCSTORETYPE, DESTSTORETYPE, SRCSTOREPASS, DESTSTOREPASS, - SRCPROTECTED, SRCPROVIDERNAME, DESTPROVIDERNAME, + SRCPROTECTED, DESTPROTECTED, SRCPROVIDERNAME, DESTPROVIDERNAME, SRCALIAS, DESTALIAS, SRCKEYPASS, DESTKEYPASS, NOPROMPT, PROVIDERCLASS, PROVIDERARG, PROVIDERPATH, V), Will be labeled noreg-trivial. Thanks Max From xuelei.fan at oracle.com Tue Jun 7 02:22:33 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Jun 2016 10:22:33 +0800 Subject: RFR 8151836: keytool -importkeystore -help does not list option -destprotected In-Reply-To: References: Message-ID: <4dad8dbe-a145-a4e2-56f0-7bb795f2f7de@oracle.com> Looks fine to me. Thanks, Xuelei On 6/7/2016 9:51 AM, Wang Weijun wrote: > I forgot to list (enum Option) DESTPROTECTED as an option of (enum Command) > IMPORTKEYSTORE. Here is the fix. Please take a review: > > diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java > --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java > +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java > @@ -206,7 +206,7 @@ > IMPORTKEYSTORE("Imports.one.or.all.entries.from.another.keystore", > SRCKEYSTORE, DESTKEYSTORE, SRCSTORETYPE, > DESTSTORETYPE, SRCSTOREPASS, DESTSTOREPASS, > - SRCPROTECTED, SRCPROVIDERNAME, DESTPROVIDERNAME, > + SRCPROTECTED, DESTPROTECTED, SRCPROVIDERNAME, DESTPROVIDERNAME, > SRCALIAS, DESTALIAS, SRCKEYPASS, DESTKEYPASS, > NOPROMPT, PROVIDERCLASS, PROVIDERARG, PROVIDERPATH, > V), > > Will be labeled noreg-trivial. > > Thanks > Max > From weijun.wang at oracle.com Tue Jun 7 03:52:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 7 Jun 2016 11:52:18 +0800 Subject: RFR 8158589: Possible integer overflow issues for DRBG Message-ID: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. I added a label noreg-cleanup, or maybe noreg-hard is better? Thanks Max From jon.berg at gmail.com Tue Jun 7 04:45:51 2016 From: jon.berg at gmail.com (Jon Berg) Date: Tue, 7 Jun 2016 06:45:51 +0200 Subject: is it possible in openjdk 9 to advertise application protocol in the tls handshake? In-Reply-To: <881deaaa-fd1c-ba4c-dc25-203df96c7b86@oracle.com> References: <881deaaa-fd1c-ba4c-dc25-203df96c7b86@oracle.com> Message-ID: I have some basic TLS stuff running that seems OK, but I am not able to get ALPN working. I am using the binary version for linux ( https://jdk9.java.net/download/). * Looking at wireshark, firefox sends in "Client Hello" with ALPN protocol h2,spdy/3.1,http/1.1 * The "Server Hello" has no mention of anything related to ALPN. Also the code prints null. So I think it is not working. Here is a screen shot of wireshark: http://imgur.com/a/OX4kd Here is what I do in the code: Is this how it should be done? System.setProperty("jdk.tls.server.enableStatusRequestExtension", "true"); sslContext = SSLContext.getInstance("TLS"); sslContext.init(kmf.getKeyManagers(), null, null); SSLServerSocket sslserversocket = null; SSLServerSocketFactory sslserversocketfactory = sslContext.getServerSocketFactory(); sslserversocket = (SSLServerSocket)sslserversocketfactory.createServerSocket(443); sslserversocket.setUseClientMode(false); sslserversocket.setWantClientAuth(false); String [] protocols = {"TLSv1","TLSv1.1","TLSv1.2"}; sslserversocket.setEnabledProtocols(protocols); SSLParameters p = sslserversocket.getSSLParameters(); p.setApplicationProtocols(new String[] {"http/1.1"}); sslserversocket.setSSLParameters(p); String [] cipher = {"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"}; sslserversocket.setEnabledCipherSuites(cipher); SSLSocket sslsocket = (SSLSocket)sslserversocket.accept(); System.out.println(sslsocket.getHandshakeApplicationProtocol()); //prints null System.out.println(sslsocket.getApplicationProtocol()); //prints null Thanks, On Tue, Jun 7, 2016 at 1:52 AM, Bradford Wetmore < bradford.wetmore at oracle.com> wrote: > JEP 244/ALPN, aka JDK-8144083/JDK-8051498 went into JDK 9 late last year. > > The API/design is at: > > https://bugs.openjdk.java.net/browse/JDK-8062848 > > In a nutshell, the client application sets the strings to send. The > server application can parse the ClientHello if desired, and can do any > SSLSocket/SSLEngine preconfiguration before starting the handshake. During > handshaking, the server library code iterates its set values, and compares > with what was received (i.e. server-preference) and chooses the first > supported value. > > While the API could support either ALPN or NPN, OpenJDK only has ALPN > support as NPN was on its way out at the time of the writing. > > Brad > > > > > > > On 6/6/2016 3:10 PM, Jon Berg wrote: > >> Hi, >> >> Given that you are acting as a server, it would be nice to be able to >> offer >> "http/1.1" as application. >> >> The purpose of this is to get chrome to do tls false start which require >> that the server "advertise" http/1.1 in ALPN or NPN. In the tls handshake. >> To do this it is just and integer and that string that has to be included >> in the handshake message at the right place... >> >> From looking at the api it seems that this is not supported. >> And from reading http://openjdk.java.net/jeps/244 it sounds as it does >> not advertise anything, but for a server socket it is an intersection of >> what >> the client sends and what the server is capable of. >> >> Can you confirm that this is not supported in openjdk 9? >> >> Thanks, >> Jon Berg. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Tue Jun 7 06:45:02 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 6 Jun 2016 23:45:02 -0700 (PDT) Subject: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout In-Reply-To: <1ed32268-fc9c-c779-1346-d5b924d564e9@oracle.com> References: <1ed32268-fc9c-c779-1346-d5b924d564e9@oracle.com> Message-ID: <94337aed-6412-455d-baed-54581d29d252@default> Hi Xuelei, Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.01/ As suggested, I have increased the timeout for (3072 256) to 700. Thanks, Siba -----Original Message----- From: Xuelei Fan Sent: Saturday, June 04, 2016 6:02 AM To: Sibabrata Sahoo; Valerie Peng; security-dev at openjdk.java.net Subject: Re: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout SupportedDSAParamGen.java ========================= Please use more large timeout. The update from 450 to 550 may be not significant enough to prevent intermittent failure. I may use bigger value, 600 or even bigger? The same comment for TestDSAGenParameterSpec.java. Thanks, Xuelei On 5/31/2016 11:04 PM, Sibabrata Sahoo wrote: > Hi, > > > > Please review the fix for the following JBS bugs, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157896 > > https://bugs.openjdk.java.net/browse/JDK-8157898 > > > > webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.00/ > > > > Description: > > These Tests takes a lots of time to generate DSA parameter when the > prime and subprime values are greater in some machine with some > platform. The reason is being the operations are CPU intensive, which > causes the Tests to timeout in rare occasion. But the Test performance > can be improved by, instead of generating DSA parameter with all > supported input in a single run, it can be divided for each input as a > separate run, so that each run can complete much before compared to > all input at once. It also provides the flexibility to associate test > options like "timeout" for specific input type where the execution > time is expected to exceed the default. > > > > Note: The fix won't give a guarantee that the timeout will never > happen but it can surely help reduce the timeout in greater extent. > Please provide your suggestion, in case any. > > > > > > Thanks, > > Siba > > > From Xuelei.Fan at Oracle.Com Tue Jun 7 10:42:37 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 7 Jun 2016 18:42:37 +0800 Subject: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout In-Reply-To: <94337aed-6412-455d-baed-54581d29d252@default> References: <1ed32268-fc9c-c779-1346-d5b924d564e9@oracle.com> <94337aed-6412-455d-baed-54581d29d252@default> Message-ID: Looks fine to me. Thanks! Xuelei > On Jun 7, 2016, at 2:45 PM, Sibabrata Sahoo wrote: > > Hi Xuelei, > > Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.01/ > > As suggested, I have increased the timeout for (3072 256) to 700. > > Thanks, > Siba > > -----Original Message----- > From: Xuelei Fan > Sent: Saturday, June 04, 2016 6:02 AM > To: Sibabrata Sahoo; Valerie Peng; security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8157896: TestDSAGenParameterSpec.java test fails with timeout > > SupportedDSAParamGen.java > ========================= > Please use more large timeout. The update from 450 to 550 may be not significant enough to prevent intermittent failure. I may use bigger value, 600 or even bigger? > > The same comment for TestDSAGenParameterSpec.java. > > Thanks, > Xuelei > > >> On 5/31/2016 11:04 PM, Sibabrata Sahoo wrote: >> Hi, >> >> >> >> Please review the fix for the following JBS bugs, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8157896 >> >> https://bugs.openjdk.java.net/browse/JDK-8157898 >> >> >> >> webrev: http://cr.openjdk.java.net/~ssahoo/8157896/webrev.00/ >> >> >> >> Description: >> >> These Tests takes a lots of time to generate DSA parameter when the >> prime and subprime values are greater in some machine with some >> platform. The reason is being the operations are CPU intensive, which >> causes the Tests to timeout in rare occasion. But the Test performance >> can be improved by, instead of generating DSA parameter with all >> supported input in a single run, it can be divided for each input as a >> separate run, so that each run can complete much before compared to >> all input at once. It also provides the flexibility to associate test >> options like "timeout" for specific input type where the execution >> time is expected to exceed the default. >> >> >> >> Note: The fix won't give a guarantee that the timeout will never >> happen but it can surely help reduce the timeout in greater extent. >> Please provide your suggestion, in case any. >> >> >> >> >> >> Thanks, >> >> Siba > From claes.redestad at oracle.com Tue Jun 7 19:44:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 7 Jun 2016 21:44:12 +0200 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <57348732.6020705@oracle.com> References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> Message-ID: <5757240C.7080006@oracle.com> Hi, there is some lingering concern that this and related changes make it that much easier to accidentally leak the system Properties object outside of core modules. By wrapping access to the system Properties object in a class residing in a non-exported package we disallow this at little to no cost: http://cr.openjdk.java.net/~redestad/8155039/webrev.02/ /Claes On 2016-05-12 15:37, Claes Redestad wrote: > Hi, > > the API this improvement depends on was updated to reflect more clearly > that this > is taking a privileged action: > https://bugs.openjdk.java.net/browse/JDK-8155775 > > Here's the updated webrev: > http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ > > Thanks! > > /Claes > > On 2016-04-25 19:28, Claes Redestad wrote: >> Hi, >> >> SSLContextImpl and TrustManagerFactoryImpl has some setup code that >> could be >> simplified, getting rid of a couple of anonymous classes in the process. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 >> >> Alternatively we could remove OpenFileInputStreamAction instead since >> these two uses >> introduced here are actually the only active uses of this old >> convenience class. >> >> Thanks! >> >> /Claes > From bradford.wetmore at oracle.com Tue Jun 7 20:12:55 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Jun 2016 13:12:55 -0700 Subject: is it possible in openjdk 9 to advertise application protocol in the tls handshake? In-Reply-To: References: <881deaaa-fd1c-ba4c-dc25-203df96c7b86@oracle.com> Message-ID: <3dc39bfa-e50c-fdf6-8769-5a2caf6c6ffd@oracle.com> > So I think it is not working. Thanks for letting us know, and providing a reproducible test case. I have filed: JDK-8158978: ALPN not working when values are set directly on SSLServerSocket and a code review will follow shortly. BTW, your code didn't actually start the handshake, so getApplicationProtocol() won't return anything at that point. But once the handshake has started, it would (should!). Just FYI, another was to see the handshake message debug without using Wireshark is to use: java -Djavax.net.debug=all MyClass Thanks again, Brad On 6/6/2016 9:45 PM, Jon Berg wrote: > I have some basic TLS stuff running that seems OK, but I am not able to > get ALPN working. I am using the binary version for linux > (https://jdk9.java.net/download/). > > * Looking at wireshark, firefox sends in "Client Hello" with ALPN > protocol h2,spdy/3.1,http/1.1 > * The "Server Hello" has no mention of anything related to ALPN. Also > the code prints null. So I think it is not working. > Here is a screen shot of wireshark: http://imgur.com/a/OX4kd > > Here is what I do in the code: > Is this how it should be done? > > System.setProperty("jdk.tls.server.enableStatusRequestExtension", "true"); > sslContext = SSLContext.getInstance("TLS"); > sslContext.init(kmf.getKeyManagers(), null, null); > SSLServerSocket sslserversocket = null; > > SSLServerSocketFactory sslserversocketfactory = > sslContext.getServerSocketFactory(); > sslserversocket = > (SSLServerSocket)sslserversocketfactory.createServerSocket(443); > > > sslserversocket.setUseClientMode(false); > sslserversocket.setWantClientAuth(false); > String [] protocols = {"TLSv1","TLSv1.1","TLSv1.2"}; > sslserversocket.setEnabledProtocols(protocols); > > SSLParameters p = sslserversocket.getSSLParameters(); > p.setApplicationProtocols(new String[] {"http/1.1"}); > sslserversocket.setSSLParameters(p); > > String [] cipher = {"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", > "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", > "TLS_RSA_WITH_AES_128_GCM_SHA256", > "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256", > "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256", > "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", > "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256", > "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", > "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"}; > sslserversocket.setEnabledCipherSuites(cipher); > > SSLSocket sslsocket = (SSLSocket)sslserversocket.accept(); > System.out.println(sslsocket.getHandshakeApplicationProtocol()); > //prints null > System.out.println(sslsocket.getApplicationProtocol()); > //prints null > > Thanks, > > > On Tue, Jun 7, 2016 at 1:52 AM, Bradford Wetmore > > wrote: > > JEP 244/ALPN, aka JDK-8144083/JDK-8051498 went into JDK 9 late last > year. > > The API/design is at: > > https://bugs.openjdk.java.net/browse/JDK-8062848 > > In a nutshell, the client application sets the strings to send. The > server application can parse the ClientHello if desired, and can do > any SSLSocket/SSLEngine preconfiguration before starting the > handshake. During handshaking, the server library code iterates its > set values, and compares with what was received (i.e. > server-preference) and chooses the first supported value. > > While the API could support either ALPN or NPN, OpenJDK only has > ALPN support as NPN was on its way out at the time of the writing. > > Brad > > > > > > > On 6/6/2016 3:10 PM, Jon Berg wrote: > > Hi, > > Given that you are acting as a server, it would be nice to be > able to offer > "http/1.1" as application. > > The purpose of this is to get chrome to do tls false start which > require > that the server "advertise" http/1.1 in ALPN or NPN. In the tls > handshake. > To do this it is just and integer and that string that has to be > included > in the handshake message at the right place... > > From looking at the api it seems that this is not supported. > And from reading http://openjdk.java.net/jeps/244 it sounds as > it does > not advertise anything, but for a server socket it is an > intersection of > what > the client sends and what the server is capable of. > > Can you confirm that this is not supported in openjdk 9? > > Thanks, > Jon Berg. > > From bradford.wetmore at oracle.com Tue Jun 7 20:13:07 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Jun 2016 13:13:07 -0700 Subject: JDK-8158978: ALPN not working when values are set directly on SSLServerSocket Message-ID: <75aab1ba-bed8-c409-6e9b-ff51a20013ab@oracle.com> Simple fix/test. We missed copying the ALPN values from the SSLServerSocket to the SSLSocket. The test is essentially SSLSocketAlpnTest.java but setting the SSLParameters on SSLServerSocket instead of SSLSocket. https://bugs.openjdk.java.net/browse/JDK-8158978 http://cr.openjdk.java.net/~wetmore/8158978/webrev.00 Brad From xuelei.fan at oracle.com Wed Jun 8 01:24:08 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Jun 2016 09:24:08 +0800 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <5757240C.7080006@oracle.com> References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> Message-ID: <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> Hi Claes, What's the necessary to get all system properties for just one specific one? Can you explain more about the necessary to make the change? Thanks, Xuelei On 6/8/2016 3:44 AM, Claes Redestad wrote: > Hi, > > there is some lingering concern that this and related changes make it > that much easier to accidentally leak the system Properties object > outside of core modules. By wrapping access to the system Properties > object in a class residing in a non-exported package we disallow this at > little to no cost: > > http://cr.openjdk.java.net/~redestad/8155039/webrev.02/ > > /Claes > > On 2016-05-12 15:37, Claes Redestad wrote: >> Hi, >> >> the API this improvement depends on was updated to reflect more clearly >> that this >> is taking a privileged action: >> https://bugs.openjdk.java.net/browse/JDK-8155775 >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ >> >> Thanks! >> >> /Claes >> >> On 2016-04-25 19:28, Claes Redestad wrote: >>> Hi, >>> >>> SSLContextImpl and TrustManagerFactoryImpl has some setup code that >>> could be >>> simplified, getting rid of a couple of anonymous classes in the process. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 >>> >>> Alternatively we could remove OpenFileInputStreamAction instead since >>> these two uses >>> introduced here are actually the only active uses of this old >>> convenience class. >>> >>> Thanks! >>> >>> /Claes >> From xuelei.fan at oracle.com Wed Jun 8 01:27:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Jun 2016 09:27:28 +0800 Subject: JDK-8158978: ALPN not working when values are set directly on SSLServerSocket In-Reply-To: <75aab1ba-bed8-c409-6e9b-ff51a20013ab@oracle.com> References: <75aab1ba-bed8-c409-6e9b-ff51a20013ab@oracle.com> Message-ID: <34d01d12-e588-b28c-dbe0-77f42108df0e@oracle.com> Looks fine to me. Thanks, Xuelei On 6/8/2016 4:13 AM, Bradford Wetmore wrote: > > Simple fix/test. > > We missed copying the ALPN values from the SSLServerSocket to the > SSLSocket. > > The test is essentially SSLSocketAlpnTest.java but setting the > SSLParameters on SSLServerSocket instead of SSLSocket. > > https://bugs.openjdk.java.net/browse/JDK-8158978 > http://cr.openjdk.java.net/~wetmore/8158978/webrev.00 > > Brad > From sha.jiang at oracle.com Wed Jun 8 07:57:03 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 8 Jun 2016 15:57:03 +0800 Subject: [9] RFR: JDK-8158462: CipherTest should get rid of race condition In-Reply-To: <137a609d-7e72-1d70-aa89-6dc935d5b9ab@oracle.com> References: <596c2004-c504-235e-11ba-58c007dee7da@oracle.com> <137a609d-7e72-1d70-aa89-6dc935d5b9ab@oracle.com> Message-ID: <004fe35a-7f26-b383-0ccd-137c7d62b52c@oracle.com> Hi Xuelei, Thanks for your comment very much! I was resolving the race condition issue on a closed JDK test, which depends on javax/net/ssl/sanity/interop/CipherTest.java. Such tests have the similar code patterns. I supposed the open JDK tests, javax/net/ssl/sanity/interop/CipherTest.java, sun/security/pkcs11/fips/CipherTest.java and sun/security/pkcs11/sslecc/CipherTest.java, have the same race condition issue. But, in fact, the scenario in the closed JDK test is different from the open JDK ones. I'll close this issue. Best regards, John Jiang On 2016/6/7 9:44, Xuelei Fan wrote: > Hi John, > > If I understand correctly, you have the client side wait for a while so > that the server can get run. This update may mitigate the race > condition, but cannot get rid of the race condition. After the timeout, > the server may still not ready. > > Did you catch a testing failure of the race condition? I was wondering > after the server socket is created, it would be ready to accept client > connections even the server thread does not call socket.accept() yet. > It may be not necessary to have client wait for server thread ready in > this context. A testing failure of the race condition would be helpful > for further evaluation. > > Thanks, > Xuelei > > > On 6/7/2016 6:43 AM, John Jiang wrote: >> Hi, >> Please review this patch. Thanks! >> >> John Jiang >> >> >> On 2016/6/2 20:54, John Jiang wrote: >>> Hi, >>> Please review this updated webrev: >>> http://cr.openjdk.java.net/~jjiang/8158462/webrev.01 >>> I just updated the year in copyright notice. >>> >>> Best regards, >>> John Jiang >>> >>> On 2016/6/2 14:11, John Jiang wrote: >>>> Hi, >>>> Please review this patch on resolving possible race condition for the >>>> following tests: >>>> javax/net/ssl/sanity/interop/CipherTest.java >>>> sun/security/pkcs11/fips/CipherTest.java >>>> sun/security/pkcs11/sslecc/CipherTest.java >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158462 >>>> >>>> Best regards, >>>> John Jiang >>>> >>>> >>> > From valerie.peng at oracle.com Wed Jun 8 17:28:59 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 08 Jun 2016 10:28:59 -0700 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) Message-ID: <575855DB.8060808@oracle.com> Tony, Can u please help reviewing this? Most if not all of the changes here are performance enhancements suggestions from the performance team. I polished them and then updated the java.security file to add SHA-3. Webrev: http://cr.openjdk.java.net/~valeriep/8157495/webrev.00/ Thanks, Valerie From ecki at zusammenkunft.net Wed Jun 8 19:49:43 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Wed, 8 Jun 2016 21:49:43 +0200 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) In-Reply-To: <575855DB.8060808@oracle.com> References: <575855DB.8060808@oracle.com> Message-ID: <93ccf45c-e6ee-487e-8d36-d48f18f3ec86.maildroid@localhost> Hello, I would not mix performance and policy commits, but maybe those changes are related to the same task? What about Group.HmacSHA2:SunJCE is that needed as well? BTW the preferences are only set for Solaris, why are there no preferences on the other platforms shipped? (Or rather, why are there overwrites on Solaris) Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Valerie Peng To: OpenJDK Dev list Sent: Mi., 08 Juni 2016 19:39 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) Tony, Can u please help reviewing this? Most if not all of the changes here are performance enhancements suggestions from the performance team. I polished them and then updated the java.security file to add SHA-3. Webrev: http://cr.openjdk.java.net/~valeriep/8157495/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Wed Jun 8 20:05:17 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Jun 2016 13:05:17 -0700 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) In-Reply-To: <93ccf45c-e6ee-487e-8d36-d48f18f3ec86.maildroid@localhost> References: <575855DB.8060808@oracle.com> <93ccf45c-e6ee-487e-8d36-d48f18f3ec86.maildroid@localhost> Message-ID: <57587A7D.6010104@oracle.com> On 06/08/2016 12:49 PM, ecki at zusammenkunft.net wrote: > Hello, > > I would not mix performance and policy commits, but maybe those changes are related to the same task? > > What about Group.HmacSHA2:SunJCE is that needed as well? BTW the preferences are only set for Solaris, why are there no preferences on the other platforms shipped? (Or rather, why are there overwrites on Solaris) > > Gruss > Bernd > Solaris's security.providers list has a different default than other OS releases with OracleUcrypto and SunPKCS11-Solaris at the top. The other OSes have SunJCE higher in the priority list. If you want to look at it more, it's in the Preferred Provider changes in JEP 246. Tony From mandy.chung at oracle.com Wed Jun 8 21:05:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Jun 2016 14:05:15 -0700 Subject: RFR 8062758: Update java/security/Security/ClassLoaderDeadlock/Deadlock2.sh with the removal of -Djava.ext.dirs In-Reply-To: <9ea80086-52a3-4d26-8b51-7c5ddedf4f2e@default> References: <7ed9fc84-0ee0-4b4f-9ea0-e6adc1ff4d0f@default> <9ea80086-52a3-4d26-8b51-7c5ddedf4f2e@default> Message-ID: <67664A76-C0A1-4236-A891-B9D970B798C6@oracle.com> > On Jun 5, 2016, at 10:40 PM, Bhanu Gopularam wrote: > > Hi all, > > Please review fix for following bug : > > Bug - https://bugs.openjdk.java.net/browse/JDK-8062758 > > Issue - Test java/security/Security/ClassLoaderDeadlock/Deadlock2.sh started failing after removal of java.ext.dirs option > > Actually the test loads two classes SunJCE provider class (uses ExtClassLoader in 8) and java.xml.parsers.DocumentBuilderFactory (loaded by bootstrap classloader) class using two separate threads simultaneously. In jdk-9 the provider classes are part of java.base and loaded by bootstrap loader. The ext classloader is replaced by platform classloader which is confined to load classes from modules only. Removing this particular test as scenario mentioned in it is not possible with new JDK-9 changes. > > Webrev - http://cr.openjdk.java.net/~bgopularam/8062758/webrev.00 Removing this test seems okay since there are existing tests checking for deadlocks. Mandy From rajan.halade at oracle.com Wed Jun 8 22:19:09 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 8 Jun 2016 15:19:09 -0700 Subject: RFR: 9: 8158569: ImpactOnSNI.java test failed with timeout Message-ID: <54b7777a-e432-5d86-881b-51ba702e39ad@oracle.com> Please help with your review of this patch. I was not able to reproduce the timeout but thread dump indicates that test timed out on waiting for server thread to join. Server thread is kept waiting on accept if client doesn't connect. This patch allows test to throw exception, if any, on client or server side eliminating this timeout scenario. Webrev: http://cr.openjdk.java.net/~rhalade/8158569/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Thu Jun 9 04:08:39 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 9 Jun 2016 12:08:39 +0800 Subject: RFR: 9: 8158569: ImpactOnSNI.java test failed with timeout In-Reply-To: <54b7777a-e432-5d86-881b-51ba702e39ad@oracle.com> References: <54b7777a-e432-5d86-881b-51ba702e39ad@oracle.com> Message-ID: <1ddefa3a-1797-5af9-34ea-36de8db4653a@oracle.com> I'm not sure this patch would work. What if throwing an exception immediately after the server ready in client side with/without this patch? There might be something wrong in the url connections of the testing. It might be worthy to add more defbug info for further evaluation. Xuelei On 6/9/2016 6:19 AM, Rajan Halade wrote: > Please help with your review of this patch. I was not able to reproduce > the timeout but thread dump indicates that test timed out on waiting for > server thread to join. Server thread is kept waiting on accept if client > doesn't connect. > > This patch allows test to throw exception, if any, on client or server > side eliminating this timeout scenario. > > Webrev: http://cr.openjdk.java.net/~rhalade/8158569/webrev.00/ > > Thanks, > Rajan From rajan.halade at oracle.com Thu Jun 9 07:24:53 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 9 Jun 2016 00:24:53 -0700 Subject: RFR: 9: 8158569: ImpactOnSNI.java test failed with timeout In-Reply-To: <1ddefa3a-1797-5af9-34ea-36de8db4653a@oracle.com> References: <54b7777a-e432-5d86-881b-51ba702e39ad@oracle.com> <1ddefa3a-1797-5af9-34ea-36de8db4653a@oracle.com> Message-ID: You are right, I missed the fact that startClient has exception catch which will allow test to call to serverThread.join(). Updated webrev fixed this along with some more debug output. Webrev: http://cr.openjdk.java.net/~rhalade/8158569/webrev.01/ Thanks, Rajan On 6/8/16 9:08 PM, Xuelei Fan wrote: > I'm not sure this patch would work. What if throwing an exception > immediately after the server ready in client side with/without this patch? > > There might be something wrong in the url connections of the testing. > It might be worthy to add more defbug info for further evaluation. > > Xuelei > > On 6/9/2016 6:19 AM, Rajan Halade wrote: >> Please help with your review of this patch. I was not able to reproduce >> the timeout but thread dump indicates that test timed out on waiting for >> server thread to join. Server thread is kept waiting on accept if client >> doesn't connect. >> >> This patch allows test to throw exception, if any, on client or server >> side eliminating this timeout scenario. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8158569/webrev.00/ >> >> Thanks, >> Rajan From valerie.peng at oracle.com Thu Jun 9 20:38:32 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 13:38:32 -0700 Subject: [9] RFR 8157881: security.provider property description needs to be updated for modules Message-ID: <5759D3C8.1020704@oracle.com> Sean, Can you please help reviewing this? I suppose we don't need to file CCC for this, right? There is already an earlier one under 7191662 and this is just updating comments in java.security file. Bug: https://bugs.openjdk.java.net/browse/JDK-8157881 Webrev: http://cr.openjdk.java.net/~valeriep/8157881/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Thu Jun 9 22:22:08 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 15:22:08 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra Message-ID: <5759EC10.9010805@oracle.com> Anyone can help reviewing this one-line change which removes a redundant declaration? As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix. Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ Thanks, Valerie From mandy.chung at oracle.com Thu Jun 9 22:31:12 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 9 Jun 2016 15:31:12 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <5759EC10.9010805@oracle.com> References: <5759EC10.9010805@oracle.com> Message-ID: <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> > On Jun 9, 2016, at 3:22 PM, Valerie Peng wrote: > > > Anyone can help reviewing this one-line change which removes a redundant declaration? > > As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix. > > Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ So all builtin security providers in java.base will not be found from ServiceLoader.load(Provider.class). test/java/security/Provider/DefaultProviderList.java should then be updated to expect all providers are not from java.base and check Class::getModule(). Currently the test simply skips some builtin security providers. Mandy From sha.jiang at oracle.com Thu Jun 9 23:01:14 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 10 Jun 2016 07:01:14 +0800 Subject: RFR: JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed Message-ID: Hi, Please review this small patch for updating ProblemList. Issue: https://bugs.openjdk.java.net/browse/JDK-8157665 Webrev: http://cr.openjdk.java.net/~jjiang/8157665/webrev.00/ Best regards, John Jiang From valerie.peng at oracle.com Thu Jun 9 23:22:40 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 16:22:40 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> Message-ID: <5759FA40.6030908@oracle.com> Thanks for the comments. I will update the reg test, i.e. test/java/security/Provider/DefaultProviderList.java, to check that they are from java.base. I don't see a need for built-in security providers to be found through ServiceLoader.load(Provider.class) though. The expected API usage is to get the provider instance through Security.getProvider(String provName). Regards, Valerie On 6/9/2016 3:31 PM, Mandy Chung wrote: >> On Jun 9, 2016, at 3:22 PM, Valerie Peng wrote: >> >> >> Anyone can help reviewing this one-line change which removes a redundant declaration? >> >> As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ > So all builtin security providers in java.base will not be found from ServiceLoader.load(Provider.class). > > test/java/security/Provider/DefaultProviderList.java should then be updated to expect all providers are not from java.base and check Class::getModule(). Currently the test simply skips some builtin security providers. > > Mandy > From mandy.chung at oracle.com Thu Jun 9 23:31:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 9 Jun 2016 16:31:35 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <5759FA40.6030908@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> Message-ID: > On Jun 9, 2016, at 4:22 PM, Valerie Peng wrote: > > > Thanks for the comments. I will update the reg test, i.e. test/java/security/Provider/DefaultProviderList.java, to check that they are from java.base. > To clarify: what I mean is that you should remove the logic that skips the built-in security provider if found. Also for the security provider, it should check it comes from a module other than java.base. > I don't see a need for built-in security providers to be found through ServiceLoader.load(Provider.class) though. The expected API usage is to get the provider instance through Security.getProvider(String provName). Right that?s implementation details. I have no issue with that. Mandy > Regards, > Valerie > > On 6/9/2016 3:31 PM, Mandy Chung wrote: >>> On Jun 9, 2016, at 3:22 PM, Valerie Peng wrote: >>> >>> >>> Anyone can help reviewing this one-line change which removes a redundant declaration? >>> >>> As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ >> So all builtin security providers in java.base will not be found from ServiceLoader.load(Provider.class). >> >> test/java/security/Provider/DefaultProviderList.java should then be updated to expect all providers are not from java.base and check Class::getModule(). Currently the test simply skips some builtin security providers. >> >> Mandy >> From anthony.scarpino at oracle.com Thu Jun 9 23:36:45 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 9 Jun 2016 16:36:45 -0700 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) In-Reply-To: <575855DB.8060808@oracle.com> References: <575855DB.8060808@oracle.com> Message-ID: <5759FD8D.9000502@oracle.com> On 06/08/2016 10:28 AM, Valerie Peng wrote: > Tony, > > Can u please help reviewing this? Most if not all of the changes here > are performance enhancements suggestions from the performance team. > I polished them and then updated the java.security file to add SHA-3. > > Webrev: http://cr.openjdk.java.net/~valeriep/8157495/webrev.00/ > > Thanks, > Valerie > One very minor nit at SHA3.java:132 and 148. I'm not sure the WIDTH checks are necessary since lanes and state are private and and have predefined lengths. Otherwise I assume all the tests passed, producing the right output. I'm fine with the change. And as we talked offline, you can remove the java.security change from the changeset. Tony From valerie.peng at oracle.com Thu Jun 9 23:37:49 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 16:37:49 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> Message-ID: <5759FDCD.4060006@oracle.com> I see. Looks like I misunderstood your earlier comment. What you suggested sounds good. I will make modifications accordingly. Thanks, Valerie On 6/9/2016 4:31 PM, Mandy Chung wrote: >> On Jun 9, 2016, at 4:22 PM, Valerie Peng wrote: >> >> >> Thanks for the comments. I will update the reg test, i.e. test/java/security/Provider/DefaultProviderList.java, to check that they are from java.base. >> > To clarify: what I mean is that you should remove the logic that skips the built-in security provider if found. Also for the security provider, it should check it comes from a module other than java.base. > >> I don't see a need for built-in security providers to be found through ServiceLoader.load(Provider.class) though. The expected API usage is to get the provider instance through Security.getProvider(String provName). > Right that?s implementation details. I have no issue with that. > > Mandy > >> Regards, >> Valerie >> >> On 6/9/2016 3:31 PM, Mandy Chung wrote: >>>> On Jun 9, 2016, at 3:22 PM, Valerie Peng wrote: >>>> >>>> >>>> Anyone can help reviewing this one-line change which removes a redundant declaration? >>>> >>>> As Apple provider is instantiated directly (see sun.security.jca.ProviderConfig.java) and not loaded through ServiceLoader , we can safely remove the line for ServiceLoader lookup. No new regression test as this is just a minor performance fix. >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ >>> So all builtin security providers in java.base will not be found from ServiceLoader.load(Provider.class). >>> >>> test/java/security/Provider/DefaultProviderList.java should then be updated to expect all providers are not from java.base and check Class::getModule(). Currently the test simply skips some builtin security providers. >>> >>> Mandy >>> From valerie.peng at oracle.com Fri Jun 10 00:26:46 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 17:26:46 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <5759FDCD.4060006@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> <5759FDCD.4060006@oracle.com> Message-ID: <575A0946.2080803@oracle.com> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.01 Thanks, Valerie On 6/9/2016 4:37 PM, Valerie Peng wrote: > > I see. Looks like I misunderstood your earlier comment. > What you suggested sounds good. I will make modifications accordingly. > Thanks, > Valerie > > On 6/9/2016 4:31 PM, Mandy Chung wrote: >>> On Jun 9, 2016, at 4:22 PM, Valerie Peng >>> wrote: >>> >>> >>> Thanks for the comments. I will update the reg test, i.e. >>> test/java/security/Provider/DefaultProviderList.java, to check that >>> they are from java.base. >>> >> To clarify: what I mean is that you should remove the logic that >> skips the built-in security provider if found. Also for the security >> provider, it should check it comes from a module other than java.base. >> >>> I don't see a need for built-in security providers to be found >>> through ServiceLoader.load(Provider.class) though. The expected API >>> usage is to get the provider instance through >>> Security.getProvider(String provName). >> Right that?s implementation details. I have no issue with that. >> >> Mandy >> >>> Regards, >>> Valerie >>> >>> On 6/9/2016 3:31 PM, Mandy Chung wrote: >>>>> On Jun 9, 2016, at 3:22 PM, Valerie >>>>> Peng wrote: >>>>> >>>>> >>>>> Anyone can help reviewing this one-line change which removes a >>>>> redundant declaration? >>>>> >>>>> As Apple provider is instantiated directly (see >>>>> sun.security.jca.ProviderConfig.java) and not loaded through >>>>> ServiceLoader , we can safely remove the line for ServiceLoader >>>>> lookup. No new regression test as this is just a minor performance >>>>> fix. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157489/ >>>> So all builtin security providers in java.base will not be found >>>> from ServiceLoader.load(Provider.class). >>>> >>>> test/java/security/Provider/DefaultProviderList.java should then be >>>> updated to expect all providers are not from java.base and check >>>> Class::getModule(). Currently the test simply skips some builtin >>>> security providers. >>>> >>>> Mandy >>>> From claes.redestad at oracle.com Fri Jun 10 00:31:04 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 10 Jun 2016 02:31:04 +0200 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> Message-ID: <575A0A48.8070903@oracle.com> Hi, by using a non-exported type, PropertiesWrapper, to encapsulate Properties this change makes it impossible for a JDK developer to accidentally leak system properties outside of java.base without breaking encapsulation. I believe that was yours and Sean's main concern about the API changes to GetPropertyAction that this is hopefully a final amendment to. Generally the changes to streamline system property access bring about minor improvements to startup and footprint by reducing the number of classes generated and loaded as well as the number of doPriv calls done. /Claes On 2016-06-08 03:24, Xuelei Fan wrote: > Hi Claes, > > What's the necessary to get all system properties for just one specific > one? Can you explain more about the necessary to make the change? > > Thanks, > Xuelei > > On 6/8/2016 3:44 AM, Claes Redestad wrote: >> Hi, >> >> there is some lingering concern that this and related changes make it >> that much easier to accidentally leak the system Properties object >> outside of core modules. By wrapping access to the system Properties >> object in a class residing in a non-exported package we disallow this at >> little to no cost: >> >> http://cr.openjdk.java.net/~redestad/8155039/webrev.02/ >> >> /Claes >> >> On 2016-05-12 15:37, Claes Redestad wrote: >>> Hi, >>> >>> the API this improvement depends on was updated to reflect more clearly >>> that this >>> is taking a privileged action: >>> https://bugs.openjdk.java.net/browse/JDK-8155775 >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ >>> >>> Thanks! >>> >>> /Claes >>> >>> On 2016-04-25 19:28, Claes Redestad wrote: >>>> Hi, >>>> >>>> SSLContextImpl and TrustManagerFactoryImpl has some setup code that >>>> could be >>>> simplified, getting rid of a couple of anonymous classes in the process. >>>> >>>> Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 >>>> >>>> Alternatively we could remove OpenFileInputStreamAction instead since >>>> these two uses >>>> introduced here are actually the only active uses of this old >>>> convenience class. >>>> >>>> Thanks! >>>> >>>> /Claes >>> > From valerie.peng at oracle.com Fri Jun 10 00:35:46 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 17:35:46 -0700 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) In-Reply-To: <5759FD8D.9000502@oracle.com> References: <575855DB.8060808@oracle.com> <5759FD8D.9000502@oracle.com> Message-ID: <575A0B62.4000006@oracle.com> Sure, I think it should be ok to skip the checks. Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8157495/webrev.01 I have removed the update on java.security file and we can address this later if needed. Thanks for the review, Valerie On 6/9/2016 4:36 PM, Anthony Scarpino wrote: > On 06/08/2016 10:28 AM, Valerie Peng wrote: >> Tony, >> >> Can u please help reviewing this? Most if not all of the changes here >> are performance enhancements suggestions from the performance team. >> I polished them and then updated the java.security file to add SHA-3. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8157495/webrev.00/ >> >> Thanks, >> Valerie >> > > One very minor nit at SHA3.java:132 and 148. I'm not sure the WIDTH > checks are necessary since lanes and state are private and and have > predefined lengths. > > Otherwise I assume all the tests passed, producing the right output. > I'm fine with the change. And as we talked offline, you can remove > the java.security change from the changeset. > > Tony > From valerie.peng at oracle.com Fri Jun 10 01:01:08 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 09 Jun 2016 18:01:08 -0700 Subject: [9] RFR 8157627: Ucrypto prov need to workaround the renaming of CK_AES_GCM_PARAMS starting S11.3 Message-ID: <575A1154.5020804@oracle.com> Hi Tony, Could you please help reviewing this? Solaris crypto team made some changes in the Ucrypto area since S11.3 which breaks JDK build. This is the workaround (and some minor clean up) for S11.3. This incompatible change will be addressed starting S12 but not S11.3 due to their release model. Webrev: http://cr.openjdk.java.net/~valeriep/8157627/webrev.00/ I have verified the changes by building on S11.3 myself and through JPRT jobs. Thanks, Valerie From mandy.chung at oracle.com Fri Jun 10 01:15:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 9 Jun 2016 18:15:59 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <575A0946.2080803@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> <5759FDCD.4060006@oracle.com> <575A0946.2080803@oracle.com> Message-ID: <9849F709-DADE-4B3E-826D-61C8FB73FA21@oracle.com> > On Jun 9, 2016, at 5:26 PM, Valerie Peng wrote: > > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.01 > 51 if (!pClass.getModule().getName().equals("java.base")) { You can check if Module object is Object.class.getModule() instead of checking the module name. Since you expect no provider from java.base, the test should detect that e.g. if (pClass.getModule() == Object.class.getModule()) throw new RuntimeException(?); Otherwise, looks okay. Mandy From xuelei.fan at oracle.com Fri Jun 10 02:27:27 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Jun 2016 10:27:27 +0800 Subject: RFR: JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 6/10/2016 7:01 AM, John Jiang wrote: > Hi, > Please review this small patch for updating ProblemList. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157665 > Webrev: http://cr.openjdk.java.net/~jjiang/8157665/webrev.00/ > > Best regards, > John Jiang > From mandy.chung at oracle.com Fri Jun 10 02:32:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 9 Jun 2016 19:32:40 -0700 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <575A0A48.8070903@oracle.com> References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> <575A0A48.8070903@oracle.com> Message-ID: Hi Claes, I don?t like the PropertiesWrapper idea. The caller should be cautious in storing any sensitive information. For the system properties, these callsites use it in the local scope that I don?t see any reason and benefit to introduce a wrapper. I didn?t follow this discussion closely and I may miss some reason ? Mandy > On Jun 9, 2016, at 5:31 PM, Claes Redestad wrote: > > Hi, > > by using a non-exported type, PropertiesWrapper, to encapsulate Properties this change makes it impossible for a JDK developer to accidentally leak system properties outside of java.base without breaking encapsulation. I believe that was yours and Sean's main concern about the API changes to GetPropertyAction that this is hopefully a final amendment to. > > Generally the changes to streamline system property access bring about minor improvements to startup and footprint by reducing the number of classes generated and loaded as well as the number of doPriv calls done. > > /Claes > > On 2016-06-08 03:24, Xuelei Fan wrote: >> Hi Claes, >> >> What's the necessary to get all system properties for just one specific >> one? Can you explain more about the necessary to make the change? >> >> Thanks, >> Xuelei >> >> On 6/8/2016 3:44 AM, Claes Redestad wrote: >>> Hi, >>> >>> there is some lingering concern that this and related changes make it >>> that much easier to accidentally leak the system Properties object >>> outside of core modules. By wrapping access to the system Properties >>> object in a class residing in a non-exported package we disallow this at >>> little to no cost: >>> >>> http://cr.openjdk.java.net/~redestad/8155039/webrev.02/ >>> >>> /Claes >>> >>> On 2016-05-12 15:37, Claes Redestad wrote: >>>> Hi, >>>> >>>> the API this improvement depends on was updated to reflect more clearly >>>> that this >>>> is taking a privileged action: >>>> https://bugs.openjdk.java.net/browse/JDK-8155775 >>>> >>>> Here's the updated webrev: >>>> http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> On 2016-04-25 19:28, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> SSLContextImpl and TrustManagerFactoryImpl has some setup code that >>>>> could be >>>>> simplified, getting rid of a couple of anonymous classes in the process. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 >>>>> >>>>> Alternatively we could remove OpenFileInputStreamAction instead since >>>>> these two uses >>>>> introduced here are actually the only active uses of this old >>>>> convenience class. >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >> From jamil.j.nimeh at oracle.com Fri Jun 10 04:49:14 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 9 Jun 2016 21:49:14 -0700 Subject: Review: 8157925: Fix typo in X509KeyManager javadoc Message-ID: Hi folks, can I please get a quick review for a very simple javadoc fix in X509KeyManager? Bug: https://bugs.openjdk.java.net/browse/JDK-8157925 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/webrev.01 Thanks! --Jamil From anthony.scarpino at oracle.com Fri Jun 10 05:22:59 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 9 Jun 2016 22:22:59 -0700 Subject: [9] RFR 8157495: SHA-3 Hash algorithm performance improvements (~12x speedup) In-Reply-To: <575A0B62.4000006@oracle.com> References: <575855DB.8060808@oracle.com> <5759FD8D.9000502@oracle.com> <575A0B62.4000006@oracle.com> Message-ID: Looks good. Tony > On Jun 9, 2016, at 5:35 PM, Valerie Peng wrote: > > Sure, I think it should be ok to skip the checks. > Webrev is updated at: http://cr.openjdk.java.net/~valeriep/8157495/webrev.01 > > I have removed the update on java.security file and we can address this later if needed. > Thanks for the review, > Valerie > >> On 6/9/2016 4:36 PM, Anthony Scarpino wrote: >>> On 06/08/2016 10:28 AM, Valerie Peng wrote: >>> Tony, >>> >>> Can u please help reviewing this? Most if not all of the changes here >>> are performance enhancements suggestions from the performance team. >>> I polished them and then updated the java.security file to add SHA-3. >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8157495/webrev.00/ >>> >>> Thanks, >>> Valerie >> >> One very minor nit at SHA3.java:132 and 148. I'm not sure the WIDTH checks are necessary since lanes and state are private and and have predefined lengths. >> >> Otherwise I assume all the tests passed, producing the right output. I'm fine with the change. And as we talked offline, you can remove the java.security change from the changeset. >> >> Tony >> From anthony.scarpino at oracle.com Fri Jun 10 05:27:19 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 9 Jun 2016 22:27:19 -0700 Subject: Review: 8157925: Fix typo in X509KeyManager javadoc In-Reply-To: References: Message-ID: Looks fine to me. Tony > On Jun 9, 2016, at 9:49 PM, Jamil Nimeh wrote: > > Hi folks, can I please get a quick review for a very simple javadoc fix in X509KeyManager? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157925 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/webrev.01 > > Thanks! > --Jamil From xuelei.fan at oracle.com Fri Jun 10 09:35:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 10 Jun 2016 17:35:37 +0800 Subject: Review: 8157925: Fix typo in X509KeyManager javadoc In-Reply-To: References: Message-ID: Nice catch! Looks fine to me, too. Thanks, Xuelei On 6/10/2016 1:27 PM, Anthony Scarpino wrote: > Looks fine to me. > > Tony > >> On Jun 9, 2016, at 9:49 PM, Jamil Nimeh wrote: >> >> Hi folks, can I please get a quick review for a very simple javadoc fix in X509KeyManager? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157925 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/webrev.01 >> >> Thanks! >> --Jamil > From sean.mullan at oracle.com Fri Jun 10 11:33:57 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 Jun 2016 07:33:57 -0400 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> <575A0A48.8070903@oracle.com> Message-ID: <575AA5A5.3090500@oracle.com> On 06/09/2016 10:32 PM, Mandy Chung wrote: > Hi Claes, > > I don?t like the PropertiesWrapper idea. The caller should be > cautious in storing any sensitive information. For the system > properties, these callsites use it in the local scope that I don?t > see any reason and benefit to introduce a wrapper. I didn?t follow > this discussion closely and I may miss some reason ? The original code used multiple calls to System.getProperty wrapped in a doPrivileged. Claes' first iteration of the fix changed this to use a GetPropertyAction.privilegedGetProperties method that returned a Properties object. I expressed a concern that this was now exposing an object that, if accidentally leaked to untrusted code could cause much more damage than the original code (since the code would be able to set/get/remove *any* system property). Hence the current fix which uses a wrapper class which is not exported. --Sean > > Mandy > >> On Jun 9, 2016, at 5:31 PM, Claes Redestad >> wrote: >> >> Hi, >> >> by using a non-exported type, PropertiesWrapper, to encapsulate >> Properties this change makes it impossible for a JDK developer to >> accidentally leak system properties outside of java.base without >> breaking encapsulation. I believe that was yours and Sean's main >> concern about the API changes to GetPropertyAction that this is >> hopefully a final amendment to. >> >> Generally the changes to streamline system property access bring >> about minor improvements to startup and footprint by reducing the >> number of classes generated and loaded as well as the number of >> doPriv calls done. >> >> /Claes >> >> On 2016-06-08 03:24, Xuelei Fan wrote: >>> Hi Claes, >>> >>> What's the necessary to get all system properties for just one >>> specific one? Can you explain more about the necessary to make >>> the change? >>> >>> Thanks, Xuelei >>> >>> On 6/8/2016 3:44 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> there is some lingering concern that this and related changes >>>> make it that much easier to accidentally leak the system >>>> Properties object outside of core modules. By wrapping access >>>> to the system Properties object in a class residing in a >>>> non-exported package we disallow this at little to no cost: >>>> >>>> http://cr.openjdk.java.net/~redestad/8155039/webrev.02/ >>>> >>>> /Claes >>>> >>>> On 2016-05-12 15:37, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> the API this improvement depends on was updated to reflect >>>>> more clearly that this is taking a privileged action: >>>>> https://bugs.openjdk.java.net/browse/JDK-8155775 >>>>> >>>>> Here's the updated webrev: >>>>> http://cr.openjdk.java.net/~redestad/8155039/webrev.01/ >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>>> >>>>> On 2016-04-25 19:28, Claes Redestad wrote: >>>>>> Hi, >>>>>> >>>>>> SSLContextImpl and TrustManagerFactoryImpl has some setup >>>>>> code that could be simplified, getting rid of a couple of >>>>>> anonymous classes in the process. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~redestad/8155039/webrev.00 Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8155039 >>>>>> >>>>>> Alternatively we could remove OpenFileInputStreamAction >>>>>> instead since these two uses introduced here are actually >>>>>> the only active uses of this old convenience class. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Claes >>>>> >>> > From sean.mullan at oracle.com Fri Jun 10 17:21:01 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 Jun 2016 13:21:01 -0400 Subject: [9] RFR 8157881: security.provider property description needs to be updated for modules In-Reply-To: <5759D3C8.1020704@oracle.com> References: <5759D3C8.1020704@oracle.com> Message-ID: <575AF6FD.6050407@oracle.com> On 06/09/2016 04:38 PM, Valerie Peng wrote: > Sean, > > Can you please help reviewing this? I suppose we don't need to file CCC > for this, right? Right, since it was covered in a previous CCC. > There is already an earlier one under 7191662 and this > is just updating comments in java.security file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157881 > Webrev: http://cr.openjdk.java.net/~valeriep/8157881/webrev.00/ 36 # specify either the provider name or the name of provider class 37 # and priority in the format since you describe the difference between provName and className below, I suggest simplifying this sentence as: "specify the provider and priority in the format" 57 # There must be at least one provider specification in java.security. 58 # There is a default provider that comes standard with the JDK. It 59 # is called the "SUN" provider. Thus, the "SUN" provider is registered 60 # via the following: 61 # 62 # security.provider.1=SUN 63 # This whole paragraph is a bit out-of-date. There is more than one provider included in the JDK. And the SUN provider is not always the #1 provider (ex: on Solaris). That first sentence is a little odd too, do we really check if there is at least one provider? My thought is to remove this whole paragraph - it doesn't seem useful and is out-of-date. --Sean From anthony.scarpino at oracle.com Fri Jun 10 18:01:18 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 10 Jun 2016 11:01:18 -0700 Subject: [9] RFR 8157627: Ucrypto prov need to workaround the renaming of CK_AES_GCM_PARAMS starting S11.3 In-Reply-To: <575A1154.5020804@oracle.com> References: <575A1154.5020804@oracle.com> Message-ID: <575B006E.7080904@oracle.com> The changes look fine.. thanks Tony On 06/09/2016 06:01 PM, Valerie Peng wrote: > Hi Tony, > > Could you please help reviewing this? Solaris crypto team made some > changes in the Ucrypto area since S11.3 which breaks JDK build. > This is the workaround (and some minor clean up) for S11.3. This > incompatible change will be addressed starting S12 but not S11.3 due to > their release model. > > Webrev: http://cr.openjdk.java.net/~valeriep/8157627/webrev.00/ > > I have verified the changes by building on S11.3 myself and through JPRT > jobs. > Thanks, > Valerie From mandy.chung at oracle.com Fri Jun 10 18:13:40 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Jun 2016 11:13:40 -0700 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: <575AA5A5.3090500@oracle.com> References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> <575A0A48.8070903@oracle.com> <575AA5A5.3090500@oracle.com> Message-ID: > On Jun 10, 2016, at 4:33 AM, Sean Mullan wrote: > > On 06/09/2016 10:32 PM, Mandy Chung wrote: >> Hi Claes, >> >> I don?t like the PropertiesWrapper idea. The caller should be >> cautious in storing any sensitive information. For the system >> properties, these callsites use it in the local scope that I don?t >> see any reason and benefit to introduce a wrapper. I didn?t follow >> this discussion closely and I may miss some reason ? > > The original code used multiple calls to System.getProperty wrapped in a doPrivileged. Claes' first iteration of the fix changed this to use a GetPropertyAction.privilegedGetProperties method that returned a Properties object. I expressed a concern that this was now exposing an object that, if accidentally leaked to untrusted code could cause much more damage than the original code (since the code would be able to set/get/remove *any* system property). Hence the current fix which uses a wrapper class which is not exported. I actually see the original code is clearer to the reader and involves one single doPrivileged. I would avoid introducing PropertiesWrapper which I don?t think it?s the right way to protect security information. Sean may suggest to revert to the original code which I won?t object. Mandy From valerie.peng at oracle.com Fri Jun 10 19:43:34 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 10 Jun 2016 12:43:34 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <9849F709-DADE-4B3E-826D-61C8FB73FA21@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> <5759FDCD.4060006@oracle.com> <575A0946.2080803@oracle.com> <9849F709-DADE-4B3E-826D-61C8FB73FA21@oracle.com> Message-ID: <575B1866.2070503@oracle.com> Sure, sounds good to me. Will update the test with your feedback. Thanks for the review, Valerie On 6/9/2016 6:15 PM, Mandy Chung wrote: > >> On Jun 9, 2016, at 5:26 PM, Valerie Peng wrote: >> >> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.01 >> > > 51 if (!pClass.getModule().getName().equals("java.base")) { > > You can check if Module object is Object.class.getModule() instead of checking the module name. > > Since you expect no provider from java.base, the test should detect that e.g. > > if (pClass.getModule() == Object.class.getModule()) > throw new RuntimeException(?); > > Otherwise, looks okay. > > Mandy From valerie.peng at oracle.com Fri Jun 10 20:07:27 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 10 Jun 2016 13:07:27 -0700 Subject: [9] RFR 8157881: security.provider property description needs to be updated for modules In-Reply-To: <575AF6FD.6050407@oracle.com> References: <5759D3C8.1020704@oracle.com> <575AF6FD.6050407@oracle.com> Message-ID: <575B1DFF.6030208@oracle.com> Sounds good. Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157881/webrev.01/ Thanks, Valerie On 6/10/2016 10:21 AM, Sean Mullan wrote: > On 06/09/2016 04:38 PM, Valerie Peng wrote: >> Sean, >> >> Can you please help reviewing this? I suppose we don't need to file CCC >> for this, right? > > Right, since it was covered in a previous CCC. > >> There is already an earlier one under 7191662 and this >> is just updating comments in java.security file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157881 >> Webrev: http://cr.openjdk.java.net/~valeriep/8157881/webrev.00/ > > > 36 # specify either the provider name or the name of provider class > 37 # and priority in the format > > since you describe the difference between provName and className > below, I suggest simplifying this sentence as: > > "specify the provider and priority in the format" > > 57 # There must be at least one provider specification in java.security. > 58 # There is a default provider that comes standard with the JDK. It > 59 # is called the "SUN" provider. Thus, the "SUN" provider is registered > 60 # via the following: > 61 # > 62 # security.provider.1=SUN > 63 # > > This whole paragraph is a bit out-of-date. There is more than one > provider included in the JDK. And the SUN provider is not always the > #1 provider (ex: on Solaris). That first sentence is a little odd too, > do we really check if there is at least one provider? > > My thought is to remove this whole paragraph - it doesn't seem useful > and is out-of-date. > > --Sean From valerie.peng at oracle.com Fri Jun 10 22:51:52 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 10 Jun 2016 15:51:52 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <575B1866.2070503@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> <5759FDCD.4060006@oracle.com> <575A0946.2080803@oracle.com> <9849F709-DADE-4B3E-826D-61C8FB73FA21@oracle.com> <575B1866.2070503@oracle.com> Message-ID: <575B4488.1070408@oracle.com> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.02. Thanks, Valerie On 6/10/2016 12:43 PM, Valerie Peng wrote: > Sure, sounds good to me. > Will update the test with your feedback. > Thanks for the review, > Valerie > > On 6/9/2016 6:15 PM, Mandy Chung wrote: >> >>> On Jun 9, 2016, at 5:26 PM, Valerie Peng >>> wrote: >>> >>> Webrev updated at: >>> http://cr.openjdk.java.net/~valeriep/8157489/webrev.01 >>> >> >> 51 if >> (!pClass.getModule().getName().equals("java.base")) { >> >> You can check if Module object is Object.class.getModule() instead of >> checking the module name. >> >> Since you expect no provider from java.base, the test should detect >> that e.g. >> >> if (pClass.getModule() == Object.class.getModule()) >> throw new RuntimeException(?); >> >> Otherwise, looks okay. >> >> Mandy From weijun.wang at oracle.com Sun Jun 12 01:45:21 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 12 Jun 2016 09:45:21 +0800 Subject: RFR 8158534: DrbgParameters strength parameter is underspecified if < -1 Message-ID: <8F86EE9B-E8D0-49E0-ACC9-F70D6AD7B308@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8158534/webrev.00 Thanks Max From xuelei.fan at oracle.com Sun Jun 12 02:15:52 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 12 Jun 2016 10:15:52 +0800 Subject: RFR 8158534: DrbgParameters strength parameter is underspecified if < -1 In-Reply-To: <8F86EE9B-E8D0-49E0-ACC9-F70D6AD7B308@oracle.com> References: <8F86EE9B-E8D0-49E0-ACC9-F70D6AD7B308@oracle.com> Message-ID: <8335cd57-f010-2005-2dc3-41b6cb4cc203@oracle.com> Looks fine to me except a minor comment: throw new IllegalArgumentException( "Illegal strength: " + strength); I may add more info in the exception message, for example "Illegal security strength". Xuelei On 6/12/2016 9:45 AM, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8158534/webrev.00 > > Thanks > Max > From weijun.wang at oracle.com Sun Jun 12 02:45:16 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 12 Jun 2016 10:45:16 +0800 Subject: RFR 8158534: DrbgParameters strength parameter is underspecified if < -1 In-Reply-To: <8335cd57-f010-2005-2dc3-41b6cb4cc203@oracle.com> References: <8F86EE9B-E8D0-49E0-ACC9-F70D6AD7B308@oracle.com> <8335cd57-f010-2005-2dc3-41b6cb4cc203@oracle.com> Message-ID: <26DAC4E8-7321-45C0-ADBB-A139B6209A37@oracle.com> Sure. I can add the word in my push. Thanks Max > On Jun 12, 2016, at 10:15 AM, Xuelei Fan wrote: > > Looks fine to me except a minor comment: > > throw new IllegalArgumentException( > "Illegal strength: " + strength); > > I may add more info in the exception message, for example "Illegal > security strength". > > Xuelei > > On 6/12/2016 9:45 AM, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8158534/webrev.00 >> >> Thanks >> Max >> > From mandy.chung at oracle.com Sun Jun 12 04:07:10 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 11 Jun 2016 21:07:10 -0700 Subject: [9] RFR 8157489: AppleProvider in java.base/macosx/classes/module-info.java.extra In-Reply-To: <575B4488.1070408@oracle.com> References: <5759EC10.9010805@oracle.com> <458357C1-D1B4-47E8-8987-934AD6B82631@oracle.com> <5759FA40.6030908@oracle.com> <5759FDCD.4060006@oracle.com> <575A0946.2080803@oracle.com> <9849F709-DADE-4B3E-826D-61C8FB73FA21@oracle.com> <575B1866.2070503@oracle.com> <575B4488.1070408@oracle.com> Message-ID: > On Jun 10, 2016, at 3:51 PM, Valerie Peng wrote: > > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157489/webrev.02. Looks fine. Mandy From weijun.wang at oracle.com Sun Jun 12 12:44:57 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 12 Jun 2016 20:44:57 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> References: <56C3381E.4070903@oracle.com> <9b8fd97d-852e-ec62-c481-f68d2e6be8da@oracle.com> <4E118FCE-0D69-4F32-B8FA-21DA9830AD23@oracle.com> <1A423858-F07C-4ECA-BD9B-14B78165407E@oracle.com> <2CFD24DE-8CE5-49AF-B3A2-E5EC9AB3D375@oracle.com> <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> Message-ID: <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> I was about to send out a new webrev (CCC just approved) but noticed a behavior change. Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now it failed, because ServiceLoader.load(Provider.class) does not contain "SUN" anymore. Maybe it is inside java.base and loaded in a shortcut mode? Therefore I am looking to add some extra lines into the following method: public static void loadProviderByName(String provName, String arg) { + Provider loaded = Security.getProvider(provName); + if (loaded != null) { + if (arg != null) { + loaded = loaded.configure(arg); + Security.addProvider(loaded); + } + return; + } for (Provider p : ServiceLoader.load(Provider.class)) { if (p.getName().equals(provName)) { if (arg != null) { p = p.configure(arg); } Security.addProvider(p); return; } } throw new IllegalArgumentException(); } Although it might not be worth supporting "-addprovider SUN", but suppose one day we have a provider inside java.base that requires an argument, this would be useful. If you are OK with this, I will send out a webrev.04 soon. Thanks Max > On Feb 23, 2016, at 11:28 AM, Wang Weijun wrote: > > Webrev updated at http://cr.openjdk.java.net/~weijun/8130302/webrev.03/. > > -provider and loadProviderByName() are useless for jdk9/dev, and loadProviderByClass() only uses reflection. > > The SunPKCS11 compatibility line will be add in a sub-patch for jake. > > --Max From Alan.Bateman at oracle.com Sun Jun 12 18:33:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 12 Jun 2016 19:33:35 +0100 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> Message-ID: <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> On 12/06/2016 13:44, Wang Weijun wrote: > I was about to send out a new webrev (CCC just approved) but noticed a behavior change. > > Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now it failed, because ServiceLoader.load(Provider.class) does not contain "SUN" anymore. Maybe it is inside java.base and loaded in a shortcut mode? > "SUN" ,"SunJCE", "SunRsaSign", and "SunJSSE" are built-in, I think Valerie has code in sun.security.jca.ProviderConfig for this. I don't recall java.base ever declaring that it `provides` these providers, except maybe via a META-INF/services configuration file for a short period from the original JCE work and the dropping the service configuration files. -Alan. From mandy.chung at oracle.com Mon Jun 13 04:23:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 12 Jun 2016 21:23:28 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> Message-ID: <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> > On Jun 12, 2016, at 11:33 AM, Alan Bateman wrote: > > > > On 12/06/2016 13:44, Wang Weijun wrote: >> I was about to send out a new webrev (CCC just approved) but noticed a behavior change. >> >> Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now it failed, because ServiceLoader.load(Provider.class) does not contain "SUN" anymore. Maybe it is inside java.base and loaded in a shortcut mode? >> > "SUN" ,"SunJCE", "SunRsaSign", and "SunJSSE" are built-in, I think Valerie has code in sun.security.jca.ProviderConfig for this. I don't recall java.base ever declaring that it `provides` these providers, except maybe via a META-INF/services configuration file for a short period from the original JCE work and the dropping the service configuration files. I think Alan is right. They were not loaded via ServiceLoader.load because of the build complexity to get multiple service config files before the module system went in jdk9. As it stands now, no provides java.security.Provider in java.base after JDK-8157489 is resolved. Mandy From sean.mullan at oracle.com Mon Jun 13 12:22:48 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Jun 2016 08:22:48 -0400 Subject: [9] RFR 8157881: security.provider property description needs to be updated for modules In-Reply-To: <575B1DFF.6030208@oracle.com> References: <5759D3C8.1020704@oracle.com> <575AF6FD.6050407@oracle.com> <575B1DFF.6030208@oracle.com> Message-ID: <575EA598.3000908@oracle.com> On 06/10/2016 04:07 PM, Valerie Peng wrote: > > Sounds good. > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157881/webrev.01/ Looks good. --Sean From artem.smotrakov at oracle.com Mon Jun 13 22:25:20 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 13 Jun 2016 15:25:20 -0700 Subject: [9] RFR: 8159038: javax/net/ssl/SSLSession/SessionCacheSizeTests.java failed with java.net.SocketException: Address already in use Message-ID: <575F32D0.4050702@oracle.com> Hello, Please review this patch for 9. javax/net/ssl/SSLSession/SessionCacheSizeTests.java test fails intermittently with "java.net.SocketException: Address already in use" exception. This exception occurs while creating a server socket: ... void doServerSide(int serverPort, int serverConns) throws Exception { try (SSLServerSocket sslServerSocket = (SSLServerSocket) sslssf.createServerSocket(serverPort)) { ... , where "serverPort" comes from "serverPorts" array which is originally initialized with zeros. The code looks correct to me, and I don't see how "serverPort" may have non-zero value, so that it can point to a busy port. If "Address already in use" error occurs when zero is passed to SSLServerSocketFactory.createServerSocket() then it looks like a bug there. Passing "serverPort" to doServerSide() and startServer() methods looks redundant. doServerSide() method can just pass zero to SSLServerSocketFactory.createServerSocket() method. The patch updates the test to use a zero constant when it creates a server socket. As I mentioned earlier, and if I am not missing something, the code looks correct to me, this change is to make sure that zero is passed to there. Any other suggestions are very welcome. It also updates the test to print some additional output, and to use try-with-resources and try-finally blocks. Bug: https://bugs.openjdk.java.net/browse/JDK-8159038 Webrev: http://cr.openjdk.java.net/~asmotrak/8159038/webrev.00/ Artem From valerie.peng at oracle.com Tue Jun 14 00:10:42 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 13 Jun 2016 17:10:42 -0700 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module Message-ID: <575F4B82.6050903@oracle.com> Sean, Can you please review the changes for deprivileging the java.smartcardio module? I have to update one makefile in the top-level workspace besides the java.policy file in the jdk workspace. One java.smartcardio regression test uses custom policy file which needs to be updated as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 Webrevs: top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Tue Jun 14 03:28:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 14 Jun 2016 11:28:42 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> Message-ID: <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> OK, please take a review at the new version at http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ Changes from webrev.03: 1. The new option name -addprovider is used, along with the changes in Resources.java. 2. In KeyStoreUtil::loadProviderByClass, special treatment for "sun.security.pkcs11.SunPKCS11" and "com.oracle.security.crypto.UcryptoProvider". 3. In KeyStoreUtil::loadProviderByName, check if the name is already loaded, configure and add it if necessary. As I said in my previous mail, this can be useful if something like SunPKCS11 is defined inside java.base. 4. Valarie asked me to bring in a change to the OracleUcrypto provider, which allows arbitrary config file. Changes are inside java.policy and UcryptoProvider.java. Thanks Max > On Jun 13, 2016, at 12:23 PM, Mandy Chung wrote: > > >> On Jun 12, 2016, at 11:33 AM, Alan Bateman wrote: >> >> >> >> On 12/06/2016 13:44, Wang Weijun wrote: >>> I was about to send out a new webrev (CCC just approved) but noticed a behavior change. >>> >>> Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now it failed, because ServiceLoader.load(Provider.class) does not contain "SUN" anymore. Maybe it is inside java.base and loaded in a shortcut mode? >>> >> "SUN" ,"SunJCE", "SunRsaSign", and "SunJSSE" are built-in, I think Valerie has code in sun.security.jca.ProviderConfig for this. I don't recall java.base ever declaring that it `provides` these providers, except maybe via a META-INF/services configuration file for a short period from the original JCE work and the dropping the service configuration files. > > I think Alan is right. They were not loaded via ServiceLoader.load because of the build complexity to get multiple service config files before the module system went in jdk9. > > As it stands now, no provides java.security.Provider in java.base after JDK-8157489 is resolved. > > Mandy From Alan.Bateman at oracle.com Tue Jun 14 11:16:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jun 2016 12:16:38 +0100 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> References: <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> Message-ID: On 14/06/2016 04:28, Wang Weijun wrote: > OK, please take a review at the new version at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ > > Changes from webrev.03: > > 1. The new option name -addprovider is used, along with the changes in Resources.java. > > 2. In KeyStoreUtil::loadProviderByClass, special treatment for "sun.security.pkcs11.SunPKCS11" and "com.oracle.security.crypto.UcryptoProvider". > > 3. In KeyStoreUtil::loadProviderByName, check if the name is already loaded, configure and add it if necessary. As I said in my previous mail, this can be useful if something like SunPKCS11 is defined inside java.base. > > 4. Valarie asked me to bring in a change to the OracleUcrypto provider, which allows arbitrary config file. Changes are inside java.policy and UcryptoProvider.java. > > I assume someone folks on security libraries will review this. A general comment is that the options looks good to me. A minor comment is that the I assume it should be "class name" rather than "classname" in usage message. -Alan. From xuelei.fan at oracle.com Tue Jun 14 11:38:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 14 Jun 2016 19:38:15 +0800 Subject: [9] RFR: 8159038: javax/net/ssl/SSLSession/SessionCacheSizeTests.java failed with java.net.SocketException: Address already in use In-Reply-To: <575F32D0.4050702@oracle.com> References: <575F32D0.4050702@oracle.com> Message-ID: <05a7f8e4-39b9-e1e5-368f-4ff4be8eb826@oracle.com> Looks fine to me. Thanks, Xuelei On 6/14/2016 6:25 AM, Artem Smotrakov wrote: > Hello, > > Please review this patch for 9. > > javax/net/ssl/SSLSession/SessionCacheSizeTests.java test fails > intermittently with "java.net.SocketException: Address already in use" > exception. This exception occurs while creating a server socket: > > ... > void doServerSide(int serverPort, int serverConns) throws Exception { > > try (SSLServerSocket sslServerSocket = > (SSLServerSocket) sslssf.createServerSocket(serverPort)) { > ... > > , where "serverPort" comes from "serverPorts" array which is originally > initialized with zeros. > > The code looks correct to me, and I don't see how "serverPort" may have > non-zero value, so that it can point to a busy port. If "Address already > in use" error occurs when zero is passed to > SSLServerSocketFactory.createServerSocket() then it looks like a bug there. > > Passing "serverPort" to doServerSide() and startServer() methods looks > redundant. doServerSide() method can just pass zero to > SSLServerSocketFactory.createServerSocket() method. > > The patch updates the test to use a zero constant when it creates a > server socket. As I mentioned earlier, and if I am not missing > something, the code looks correct to me, this change is to make sure > that zero is passed to there. Any other suggestions are very welcome. > > It also updates the test to print some additional output, and to use > try-with-resources and try-finally blocks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159038 > Webrev: http://cr.openjdk.java.net/~asmotrak/8159038/webrev.00/ > > Artem From simone.bordet at gmail.com Tue Jun 14 13:57:37 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 14 Jun 2016 15:57:37 +0200 Subject: Issues with ALPN implementation in JDK 9 Message-ID: Hi, I gave a shot at implementing ALPN in JDK 9 in Jetty. TLDR: I could not find a way to make it work. This email is to discuss whether I am off road or discuss possible solutions. Below my feedback. * Lack of facilities to convert TLS protocol bytes to protocol strings. This class already exist in JDK, sun.security.ssl.ProtocolVersion, it would just need to be exposed in javax.net.ssl. * Lack of facilities to convert TLS cipher bytes to cipher name strings. As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly. Note that for the 2 bullets above, a recent message from Mark Reinhold to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I hope they can be considered for inclusion. * Server-side Implementation I followed the guidelines reported here: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013132.html, namely: 1) Read network bytes after initial connection. 2) Parse network bytes, expecting TLS ClientHello message. 3) Extract from ClientHello the TLS protocol version, the TLS ciphers, the ALPN protocols. At this point, I should negotiate the application protocol, and it must be only one. Assuming the ClientHello TLS protocol is spoken by both peers, the server logic can create pairs (cipher, app_proto) for each of the ciphers in common between client and server, and discard the ciphers that are not good for any protocol. At this point, among all the valid pairs, I need to choose a protocol. Let's make an example; the pairs are: (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, h3) (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, h2) (TLS_WHATEVER, http/1.1) Here "h3" is the future HTTP/3 protocol which I picked as an example to show the problem I will encounter. Because at this point the server logic must choose one protocol only (so that it can be returned in the ServerHello), it picks h3, which goes along with a ECDSA cipher, so: sslParams.setApplicationProtocols(new String[]{"h3"}); sslParams.setCipherSuites(new String[]{"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", ...); sslEngine.setSSLParameters(sslParams); At this point, the server logic is good to let SSLEngine do the unwrap(), and pass the original network bytes to unwrap(). During the unwrap(), the JDK implementation picks a cipher based on the JDK logic. In particular, in my case, I had a keystore with a certificate that was *not* ECDSA. If, in the snippet above, I set more than one cipher on the SSLParameters, then perhaps a weaker cipher could be negotiated that is not good for h3. Otherwise, if I set only one cipher, there are no ciphers in common and the TLS handshake is terminated with an error. Bottom line, no negotiation is possible with this approach. Next attempt I made was that before calling unwrap(), the server code opens the keystore, and verifies if the certificate is ECDSA, handles SNI, etc. However, this means duplicating all the JDK logic to make sure that the server logic *before* calling unwrap() is the same of the JDK so that when unwrap() is called there will be no failures. I don't think this is maintainable; the JDK is entitled to change the logic following CVEs, optimizations and what not, and each such change risks to break existing server code. I then tried another approach. In the server code, before calling unwrap(), I would remember the pairs (cipher, app_proto), but *not* calling SSLParameters.setApplicationProtocol(). I would then call unwrap(), where the JDK would choose the cipher. The cipher is chosen in the NEED_TASK step of the unwrap(), so after the task is run, the cipher chosen by the JDK is now available to the server logic. At this point I called again the server logic and, given the exact cipher, choose the right protocol among the pairs that I have previously stored. In the example above, the JDK would have chose the RSA cipher because the certificate was not ECDSA, and the server logic would have chosen h2 as the application protocol: sslParams.setApplicationProtocol(new String[]{"h2"}); Then let the unwrap()/wrap() code to finish the TLS handshake (in particular, generate the ServerHello). This approach has the benefit of cipher pre-selection done by the server logic (it will retain not the intersection of ciphers between client and server, but a possibly more restricted set that is valid for the application protocols that are supported - imagine when http/1.1 is not supported), coupled with JDK logic to interact with SNI and certificates, coupled with a "late" selection of the application protocol based on the cipher selected by the JDK logic. Unfortunately, it does not work. It does not work because the JDK implementation of SSLEngine.setSSLParameters() is (more or less): if (!handshake.started()) { handshaker.setApplicationProtocols(applicationProtocols); ... } By the time the task is run in the NEED_TASK step, handshaker.started==true, so the application protocols are not copied into the handshaker and are not used to generate the ServerHello. Conclusions. I could not make a reliable ALPN implementation with the current JDK 9. If I am off road, then that's good news, and I will be all ears for alternative approaches. If I am correct, I would like to discuss whether it would be possible to delay handshaker.started=true to a later time, so that SSLParameters can be changed just after the NEED_TASK step, so that server applications will be able to interact with the JDK for what pertains TLS protocols, ciphers, SNI, etc. without duplicating the logic. Comments welcome. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From david.lloyd at redhat.com Tue Jun 14 14:31:57 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 14 Jun 2016 09:31:57 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: <5760155D.4070907@redhat.com> I have a few questions, inline. On 06/14/2016 08:57 AM, Simone Bordet wrote: > Hi, > > I gave a shot at implementing ALPN in JDK 9 in Jetty. > > TLDR: I could not find a way to make it work. This email is to discuss > whether I am off road or discuss possible solutions. > > Below my feedback. > > * Lack of facilities to convert TLS protocol bytes to protocol strings. > This class already exist in JDK, sun.security.ssl.ProtocolVersion, it > would just need to be exposed in javax.net.ssl. > * Lack of facilities to convert TLS cipher bytes to cipher name strings. > As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly. This would *definitely* be a real nice-to-have. Just having spent way too long creating our own lookup table... > Note that for the 2 bullets above, a recent message from Mark Reinhold > to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I > hope they can be considered for inclusion. > > * Server-side Implementation > I followed the guidelines reported here: > http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013132.html, > namely: > > 1) Read network bytes after initial connection. > 2) Parse network bytes, expecting TLS ClientHello message. > 3) Extract from ClientHello the TLS protocol version, the TLS ciphers, > the ALPN protocols. > > At this point, I should negotiate the application protocol, and it > must be only one. > > Assuming the ClientHello TLS protocol is spoken by both peers, the > server logic can create pairs (cipher, app_proto) for each of the > ciphers in common between client and server, and discard the ciphers > that are not good for any protocol. > > At this point, among all the valid pairs, I need to choose a protocol. > Let's make an example; the pairs are: > > (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, h3) > (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, h2) > (TLS_WHATEVER, http/1.1) > > Here "h3" is the future HTTP/3 protocol which I picked as an example > to show the problem I will encounter. > > Because at this point the server logic must choose one protocol only > (so that it can be returned in the ServerHello), it picks h3, which > goes along with a ECDSA cipher, so: > > sslParams.setApplicationProtocols(new String[]{"h3"}); > sslParams.setCipherSuites(new > String[]{"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", ...); > sslEngine.setSSLParameters(sslParams); > > At this point, the server logic is good to let SSLEngine do the > unwrap(), and pass the original network bytes to unwrap(). > > During the unwrap(), the JDK implementation picks a cipher based on > the JDK logic. > In particular, in my case, I had a keystore with a certificate that > was *not* ECDSA. Could you not use the available keys as an input into your own protocol selection? Granted you have to know what kind of key works with what algorithm, but if you already have a table of cipher suites, you might as well just add it on there... > If, in the snippet above, I set more than one cipher on the > SSLParameters, then perhaps a weaker cipher could be negotiated that > is not good for h3. > Otherwise, if I set only one cipher, there are no ciphers in common > and the TLS handshake is terminated with an error. > > Bottom line, no negotiation is possible with this approach. > > Next attempt I made was that before calling unwrap(), the server code > opens the keystore, and verifies if the certificate is ECDSA, handles > SNI, etc. > > However, this means duplicating all the JDK logic to make sure that > the server logic *before* calling unwrap() is the same of the JDK so > that when unwrap() is called there will be no failures. I don't think you have to duplicate the exact logic though. It's not really a "black box": if you know the cipher suites supported by your available key(s) then you should have enough information to know, based on the client cipher suites and the per-protocol suites, and the cipher suites available in the SSL context(s), which protocols can complete. > I don't think this is maintainable; the JDK is entitled to change the > logic following CVEs, optimizations and what not, and each such change > risks to break existing server code. What kind of change do you anticipate being a breaking change? Are you thinking of e.g. blacklisting some known-bad cipher suite or something? (eom) > I then tried another approach. > > In the server code, before calling unwrap(), I would remember the > pairs (cipher, app_proto), but *not* calling > SSLParameters.setApplicationProtocol(). > > I would then call unwrap(), where the JDK would choose the cipher. > The cipher is chosen in the NEED_TASK step of the unwrap(), so after > the task is run, the cipher chosen by the JDK is now available to the > server logic. > > At this point I called again the server logic and, given the exact > cipher, choose the right protocol among the pairs that I have > previously stored. > In the example above, the JDK would have chose the RSA cipher because > the certificate was not ECDSA, and the server logic would have chosen > h2 as the application protocol: > > sslParams.setApplicationProtocol(new String[]{"h2"}); > > Then let the unwrap()/wrap() code to finish the TLS handshake (in > particular, generate the ServerHello). > > This approach has the benefit of cipher pre-selection done by the > server logic (it will retain not the intersection of ciphers between > client and server, but a possibly more restricted set that is valid > for the application protocols that are supported - imagine when > http/1.1 is not supported), coupled with JDK logic to interact with > SNI and certificates, coupled with a "late" selection of the > application protocol based on the cipher selected by the JDK logic. > > Unfortunately, it does not work. > > It does not work because the JDK implementation of > SSLEngine.setSSLParameters() is (more or less): > > if (!handshake.started()) { > handshaker.setApplicationProtocols(applicationProtocols); > ... > } > > By the time the task is run in the NEED_TASK step, > handshaker.started==true, so the application protocols are not copied > into the handshaker and are not used to generate the ServerHello. > > Conclusions. > > I could not make a reliable ALPN implementation with the current JDK 9. > If I am off road, then that's good news, and I will be all ears for > alternative approaches. > > If I am correct, I would like to discuss whether it would be possible > to delay handshaker.started=true to a later time, so that > SSLParameters can be changed just after the NEED_TASK step, so that > server applications will be able to interact with the JDK for what > pertains TLS protocols, ciphers, SNI, etc. without duplicating the > logic. > > Comments welcome. > > Thanks ! > -- - DML From sbordet at webtide.com Tue Jun 14 14:47:21 2016 From: sbordet at webtide.com (Simone Bordet) Date: Tue, 14 Jun 2016 16:47:21 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <5760155D.4070907@redhat.com> References: <5760155D.4070907@redhat.com> Message-ID: Hi, On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote: >> During the unwrap(), the JDK implementation picks a cipher based on >> the JDK logic. >> In particular, in my case, I had a keystore with a certificate that >> was *not* ECDSA. > > Could you not use the available keys as an input into your own protocol > selection? Granted you have to know what kind of key works with what > algorithm, but if you already have a table of cipher suites, you might as > well just add it on there... By "keys" here you mean, exactly ? >> However, this means duplicating all the JDK logic to make sure that >> the server logic *before* calling unwrap() is the same of the JDK so >> that when unwrap() is called there will be no failures. > > I don't think you have to duplicate the exact logic though. It's not really > a "black box": if you know the cipher suites supported by your available > key(s) then you should have enough information to know, based on the client > cipher suites and the per-protocol suites, and the cipher suites available > in the SSL context(s), which protocols can complete. Well, perhaps. My point is that I implement some logic in the server, say version 10. Server 10 works with JDK 9.1.0. Time passes, JDK gets updated to 9.1.173, which has now a different logic, for whatever reason. Try to run server 10 with JDK 9.1.173 does not negotiate the right protocol. >> I don't think this is maintainable; the JDK is entitled to change the >> logic following CVEs, optimizations and what not, and each such change >> risks to break existing server code. > > > What kind of change do you anticipate being a breaking change? Are you > thinking of e.g. blacklisting some known-bad cipher suite or something? Well, take ECDSA for instance. Before that, my logic on server version 10 was not caring about ECDSA. My server version 10 was working with JDK 5, but not with JDK 9 (assuming that JDK 5 did not have support for ECDSA). That is a breaking change to me. I imagine in the future ECDSA be replaced by something else, or a different DSA being used, I have to change the server code. I would like to avoid that, and keep the server logic independent of how the JDK chooses the cipher. Makes sense ? Thanks ! -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From david.lloyd at redhat.com Tue Jun 14 14:53:58 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 14 Jun 2016 09:53:58 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <5760155D.4070907@redhat.com> Message-ID: <57601A86.8000400@redhat.com> On 06/14/2016 09:47 AM, Simone Bordet wrote: > Hi, > > On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote: >>> During the unwrap(), the JDK implementation picks a cipher based on >>> the JDK logic. >>> In particular, in my case, I had a keystore with a certificate that >>> was *not* ECDSA. >> >> Could you not use the available keys as an input into your own protocol >> selection? Granted you have to know what kind of key works with what >> algorithm, but if you already have a table of cipher suites, you might as >> well just add it on there... > > By "keys" here you mean, exactly ? I'm referring to where you point out that when you read your server key from the key store, it didn't work with the cipher(s) that was/were associated with the protocol that was selected. >>> However, this means duplicating all the JDK logic to make sure that >>> the server logic *before* calling unwrap() is the same of the JDK so >>> that when unwrap() is called there will be no failures. >> >> I don't think you have to duplicate the exact logic though. It's not really >> a "black box": if you know the cipher suites supported by your available >> key(s) then you should have enough information to know, based on the client >> cipher suites and the per-protocol suites, and the cipher suites available >> in the SSL context(s), which protocols can complete. > > Well, perhaps. > > My point is that I implement some logic in the server, say version 10. > Server 10 works with JDK 9.1.0. > Time passes, JDK gets updated to 9.1.173, which has now a different > logic, for whatever reason. > Try to run server 10 with JDK 9.1.173 does not negotiate the right protocol. > >>> I don't think this is maintainable; the JDK is entitled to change the >>> logic following CVEs, optimizations and what not, and each such change >>> risks to break existing server code. >> >> >> What kind of change do you anticipate being a breaking change? Are you >> thinking of e.g. blacklisting some known-bad cipher suite or something? > > Well, take ECDSA for instance. Before that, my logic on server version > 10 was not caring about ECDSA. > My server version 10 was working with JDK 5, but not with JDK 9 > (assuming that JDK 5 did not have support for ECDSA). > That is a breaking change to me. > > I imagine in the future ECDSA be replaced by something else, or a > different DSA being used, I have to change the server code. > I would like to avoid that, and keep the server logic independent of > how the JDK chooses the cipher. > > Makes sense ? Yes. Basically the server logic always has to be up to date with the latest cipher suites and that sort of thing. Our solution to this is to have a security framework that is responsible for this (among other things). It's not ideal but it seems to work OK so far. -- - DML From simone.bordet at gmail.com Tue Jun 14 15:02:16 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 14 Jun 2016 17:02:16 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57601A86.8000400@redhat.com> References: <5760155D.4070907@redhat.com> <57601A86.8000400@redhat.com> Message-ID: Hi, On Tue, Jun 14, 2016 at 4:53 PM, David M. Lloyd wrote: > Yes. Basically the server logic always has to be up to date with the latest > cipher suites and that sort of thing. Our solution to this is to have a > security framework that is responsible for this (among other things). It's > not ideal but it seems to work OK so far. Right, but this is not always possible. To cite our experience, we have people running Jetty 5 in JDK 1.4. That some few hundreds releases back for both Jetty and the JDK. Point being, we never know what version of Jetty people run with what JDK. We already painfully maintain Jetty's alpn-boot implementation for JDK 8 changing it for every JDK change. We hoped to get rid of that with JDK 9, but currently that does not seem possible. I really hope that handshaker.started=true could be delayed (or a similar solution) to give room to a forward compatible ALPN implementation that can be run with any JDK 9+. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jason.greene at redhat.com Tue Jun 14 15:26:46 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 14 Jun 2016 11:26:46 -0400 (EDT) Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: > On Jun 14, 2016, at 8:58 AM, Simone Bordet wrote: > > During the unwrap(), the JDK implementation picks a cipher based on > the JDK logic. > In particular, in my case, I had a keystore with a certificate that > was *not* ECDSA. > If, in the snippet above, I set more than one cipher on the > SSLParameters, then perhaps a weaker cipher could be negotiated that > is not good for h3. > Otherwise, if I set only one cipher, there are no ciphers in common > and the TLS handshake is terminated with an error. With H2 all impls are required to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 , so that should be selectable either by your protocol stack or the TLS layer. If you wanted to be especially lazy you could just exclude any blacklisted cipher list presented in the client hello, and verify that additional ones are present, and if so set the rest as the available cipher set in SSL params. The TLS stack will pick appropriately at that point. This is future proof, because an H protocol version increase is required to introduce further restrictions. Once you have code that understands the new H version you can add additional blacklisted values for that version, and you are once again future proof. From simone.bordet at gmail.com Tue Jun 14 15:58:58 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 14 Jun 2016 17:58:58 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: Hi, On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene wrote: > With H2 all impls are required to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Unless it is discovered vulnerable. > so that should be selectable either by your protocol stack or the TLS layer. If you wanted to be especially lazy you could just exclude any blacklisted cipher list presented in the client hello, and verify that additional ones are present, and if so set the rest as the available cipher set in SSL params. The TLS stack will pick appropriately at that point. Not in general, see my example. The server could choose an ECDSA cipher for h3, the mandatory cipher for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the server chooses the protocol *before* the JDK chooses the cipher, it may think that h3 is a good choice, but the TLS stack chooses the RSA cipher. At this point, you have the h3 protocol with the RSA cipher, which may be an invalid combination. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From lussnig at suche.org Tue Jun 14 15:04:54 2016 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 14 Jun 2016 17:04:54 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: <57601D16.5090706@suche.org> Hi, i think not only the cipher suite and protocol version. But many other parts should be also be public. Like Supported digest, curve types, etc... And also these information should be available for the keymanger. So that he is able to select certificate also based on the curve types. Gru? Thomas Am 14.06.2016 um 15:57 schrieb Simone Bordet: > Hi, > > I gave a shot at implementing ALPN in JDK 9 in Jetty. > > TLDR: I could not find a way to make it work. This email is to discuss > whether I am off road or discuss possible solutions. > > Below my feedback. > > * Lack of facilities to convert TLS protocol bytes to protocol strings. > This class already exist in JDK, sun.security.ssl.ProtocolVersion, it > would just need to be exposed in javax.net.ssl. > > * Lack of facilities to convert TLS cipher bytes to cipher name strings. > As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly. > > Note that for the 2 bullets above, a recent message from Mark Reinhold > to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I > hope they can be considered for inclusion. > > * Server-side Implementation > I followed the guidelines reported here: > http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013132.html, > namely: > > 1) Read network bytes after initial connection. > 2) Parse network bytes, expecting TLS ClientHello message. > 3) Extract from ClientHello the TLS protocol version, the TLS ciphers, > the ALPN protocols. > > At this point, I should negotiate the application protocol, and it > must be only one. > > Assuming the ClientHello TLS protocol is spoken by both peers, the > server logic can create pairs (cipher, app_proto) for each of the > ciphers in common between client and server, and discard the ciphers > that are not good for any protocol. > > At this point, among all the valid pairs, I need to choose a protocol. > Let's make an example; the pairs are: > > (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, h3) > (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, h2) > (TLS_WHATEVER, http/1.1) > > Here "h3" is the future HTTP/3 protocol which I picked as an example > to show the problem I will encounter. > > Because at this point the server logic must choose one protocol only > (so that it can be returned in the ServerHello), it picks h3, which > goes along with a ECDSA cipher, so: > > sslParams.setApplicationProtocols(new String[]{"h3"}); > sslParams.setCipherSuites(new > String[]{"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", ...); > sslEngine.setSSLParameters(sslParams); > > At this point, the server logic is good to let SSLEngine do the > unwrap(), and pass the original network bytes to unwrap(). > > During the unwrap(), the JDK implementation picks a cipher based on > the JDK logic. > In particular, in my case, I had a keystore with a certificate that > was *not* ECDSA. > If, in the snippet above, I set more than one cipher on the > SSLParameters, then perhaps a weaker cipher could be negotiated that > is not good for h3. > Otherwise, if I set only one cipher, there are no ciphers in common > and the TLS handshake is terminated with an error. > > Bottom line, no negotiation is possible with this approach. > > Next attempt I made was that before calling unwrap(), the server code > opens the keystore, and verifies if the certificate is ECDSA, handles > SNI, etc. > > However, this means duplicating all the JDK logic to make sure that > the server logic *before* calling unwrap() is the same of the JDK so > that when unwrap() is called there will be no failures. > > I don't think this is maintainable; the JDK is entitled to change the > logic following CVEs, optimizations and what not, and each such change > risks to break existing server code. > > I then tried another approach. > > In the server code, before calling unwrap(), I would remember the > pairs (cipher, app_proto), but *not* calling > SSLParameters.setApplicationProtocol(). > > I would then call unwrap(), where the JDK would choose the cipher. > The cipher is chosen in the NEED_TASK step of the unwrap(), so after > the task is run, the cipher chosen by the JDK is now available to the > server logic. > > At this point I called again the server logic and, given the exact > cipher, choose the right protocol among the pairs that I have > previously stored. > In the example above, the JDK would have chose the RSA cipher because > the certificate was not ECDSA, and the server logic would have chosen > h2 as the application protocol: > > sslParams.setApplicationProtocol(new String[]{"h2"}); > > Then let the unwrap()/wrap() code to finish the TLS handshake (in > particular, generate the ServerHello). > > This approach has the benefit of cipher pre-selection done by the > server logic (it will retain not the intersection of ciphers between > client and server, but a possibly more restricted set that is valid > for the application protocols that are supported - imagine when > http/1.1 is not supported), coupled with JDK logic to interact with > SNI and certificates, coupled with a "late" selection of the > application protocol based on the cipher selected by the JDK logic. > > Unfortunately, it does not work. > > It does not work because the JDK implementation of > SSLEngine.setSSLParameters() is (more or less): > > if (!handshake.started()) { > handshaker.setApplicationProtocols(applicationProtocols); > ... > } > > By the time the task is run in the NEED_TASK step, > handshaker.started==true, so the application protocols are not copied > into the handshaker and are not used to generate the ServerHello. > > Conclusions. > > I could not make a reliable ALPN implementation with the current JDK 9. > If I am off road, then that's good news, and I will be all ears for > alternative approaches. > > If I am correct, I would like to discuss whether it would be possible > to delay handshaker.started=true to a later time, so that > SSLParameters can be changed just after the NEED_TASK step, so that > server applications will be able to interact with the JDK for what > pertains TLS protocols, ciphers, SNI, etc. without duplicating the > logic. > > Comments welcome. > > Thanks ! > From simone.bordet at gmail.com Tue Jun 14 17:52:42 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 14 Jun 2016 19:52:42 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: Hi, On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet wrote: > The server could choose an ECDSA cipher for h3, the mandatory cipher > for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the > server chooses the protocol *before* the JDK chooses the cipher, it > may think that h3 is a good choice, but the TLS stack chooses the RSA > cipher. > At this point, you have the h3 protocol with the RSA cipher, which may > be an invalid combination. Just to add more information here. If the server logic chooses h3 and also restricts the ciphers to only (ECDSA) to make sure that h3 is chosen, the JDK may find that the cipher is not good for the certificate, and therefore there are no ciphers in common and the connection is terminated. There is no negotiation, although h2 with RSA would have been a valid combination. If handshaker.started=true is delayed, the server could wait for the JDK to choose a cipher, and then a suitable protocol for that cipher, which in the example would be h2, and the negotiation would be successful. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jason.greene at redhat.com Tue Jun 14 18:11:47 2016 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 14 Jun 2016 13:11:47 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: <268D9783-FE9C-46BA-B6E2-0F673A264EC0@redhat.com> > On Jun 14, 2016, at 10:58 AM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene > wrote: >> With H2 all impls are required to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > Unless it is discovered vulnerable. Sure, but in that case we have to rev the H2 protocol to fix it (h2.1 or something), and users will probably have to deploy intermediate solutions (like JSSE configs) to address it. > >> so that should be selectable either by your protocol stack or the TLS layer. If you wanted to be especially lazy you could just exclude any blacklisted cipher list presented in the client hello, and verify that additional ones are present, and if so set the rest as the available cipher set in SSL params. The TLS stack will pick appropriately at that point. > > Not in general, see my example. > The server could choose an ECDSA cipher for h3, the mandatory cipher > for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the > server chooses the protocol *before* the JDK chooses the cipher, it > may think that h3 is a good choice, but the TLS stack chooses the RSA > cipher. > At this point, you have the h3 protocol with the RSA cipher, which may > be an invalid combination. In the case that the client doesn?t present a valid H3 cipher, that can be determined by removing all blacklisted ciphers (and unsupported ciphers), and ultimately wind up with an empty set. If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key. -Jason From simone.bordet at gmail.com Tue Jun 14 19:52:52 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 14 Jun 2016 21:52:52 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <268D9783-FE9C-46BA-B6E2-0F673A264EC0@redhat.com> References: <268D9783-FE9C-46BA-B6E2-0F673A264EC0@redhat.com> Message-ID: Hi, On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: > If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key. I don't think it is that easy. The server logic has to mimic exactly what the JDK logic is, that is to verify the cipher and certificate compatibility. Not only, the server has to run the logic for SNI, the same logic that the JDK runs to get the right certificate. This logic would now run twice. As I said, it is doable as long as the server logic duplicates and keeps in sync with the JDK logic so that it is guaranteed that the application protocol chosen by the server ends up with a cipher, chosen by the JDK, valid for that protocol. The moment the logic is different, there is a problem. Every time the JDK updates, you and me have to go and look inside the JDK to check whether the logic is changed, and if so, update our servers. And then we have to say that version X of our server only works with JDKs up to version Y, and that version X+1 of our server only works with JDK version Y+1. Been there, done that. I'd like to move to a better model that is future proof. I don't control which JDK people use to run Jetty. I would rather not duplicate all the JDK logic into an application. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From sean.mullan at oracle.com Tue Jun 14 21:28:41 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Jun 2016 17:28:41 -0400 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module In-Reply-To: <575F4B82.6050903@oracle.com> References: <575F4B82.6050903@oracle.com> Message-ID: <57607709.4070506@oracle.com> I don't think you need to make changes to test/javax/smartcardio/policy. Instead you can change the tests that use this policy file to use the new jtreg @run /java.security.policy=policy which extends the default system policy. --Sean On 06/13/2016 08:10 PM, Valerie Peng wrote: > Sean, > > Can you please review the changes for deprivileging the java.smartcardio > module? > I have to update one makefile in the top-level workspace besides the > java.policy file in the jdk workspace. > One java.smartcardio regression test uses custom policy file which needs > to be updated as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 > Webrevs: > top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ > jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ > > Thanks, > Valerie From joe.darcy at oracle.com Tue Jun 14 21:37:02 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 14 Jun 2016 14:37:02 -0700 Subject: JDK 9 RFR of JDK-8159502: Mark ShortRSAKey512.java as intermittently failing Message-ID: The test javax/net/ssl/TLSv12/ShortRSAKey512.java has been seen to intermittently fail (JDK-8159501). The test should be marked accordingly. Please review the patch below which does this. Thanks, -Joe diff -r d6a1ad87842f test/javax/net/ssl/TLSv12/ShortRSAKey512.java --- a/test/javax/net/ssl/TLSv12/ShortRSAKey512.java Tue Jun 14 09:03:12 2016 -0700 +++ b/test/javax/net/ssl/TLSv12/ShortRSAKey512.java Tue Jun 14 14:36:39 2016 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -33,6 +33,7 @@ * * SunJSSE does not support dynamic system properties, no way to re-use * system properties in samevm/agentvm mode. + * @key intermittent * @run main/othervm ShortRSAKey512 PKIX * @run main/othervm ShortRSAKey512 SunX509 */ From jason.greene at redhat.com Tue Jun 14 22:28:58 2016 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 14 Jun 2016 17:28:58 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <268D9783-FE9C-46BA-B6E2-0F673A264EC0@redhat.com> Message-ID: > On Jun 14, 2016, at 2:52 PM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: >> If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key. > > I don't think it is that easy. Well certificate mechanisms aren?t introduced that often, so its probably good enough under such a scenario. As a related tangent, it?s hard to imagine that RSA would get blacklisted unless quantum immune algorithms were rolling out, but that seems a long long long way away. > > The server logic has to mimic exactly what the JDK logic is, that is > to verify the cipher and certificate compatibility. > Not only, the server has to run the logic for SNI, the same logic that > the JDK runs to get the right certificate. This logic would now run > twice. > > As I said, it is doable as long as the server logic duplicates and > keeps in sync with the JDK logic so that it is guaranteed that the > application protocol chosen by the server ends up with a cipher, > chosen by the JDK, valid for that protocol. > The moment the logic is different, there is a problem. I think the issue is that to make the decision 100% perfect, you have to evaluate a number of factors together (ciphers, tls protocol, alpn protocol, key material, etc). The JDK TLS impl could certainly do it, but unfortunately, as you know, it was decided there wasn?t enough time to redesign the implementaiton in 9 to accommodate a multi factor negotiation incorporating alpn (the tuple approach). There?s also a secondary problem that new application protocols could be introduced before the JDK is aware of them, and with varying cipher requirements. So to make a tuple based JDK impl work, you would have to introduce a callback API with rich information for the application to use, and it would have to understand a lot about ciphers to use this. Ultimately we ended with a defer to application plan, which does allow for a perfect decision, but it does put a burden on the app for sure, but its not much more than what a callback approach like I mentioned above would require. If we let the JDK negotiate the cipher, and then the app negotiates the protocol separately, you can end up with wrong answers as well. For example, stick an h2 blacklisted cipher higher on the order list in ClientHello, and you can end up forcing h1 instead of h2, even if there is a perfectly valid h2 cipher present. > > Every time the JDK updates, you and me have to go and look inside the > JDK to check whether the logic is changed, and if so, update our > servers. > And then we have to say that version X of our server only works with > JDKs up to version Y, and that version X+1 of our server only works > with JDK version Y+1. > Been there, done that. I'd like to move to a better model that is future proof. > I don't control which JDK people use to run Jetty. I don?t see the challenge in supporting old JDK versions with the same up-to-date server code (at least after Java 9 where the app can control all of this)? > > I would rather not duplicate all the JDK logic into an application. Well I think the ?lazy? approach I described before would work quite well with very few application updates necessary, basically zero today, and another whenever a new HTTP/X version rolls out, but you have to do that anyway. With a more thorough application stack though its possible to make perfect decisions on these sorts of things. I can appreciate the desire not to duplicate the JDK; it would be nice to see a richer tuple based impl in the future. > > Thanks ! > From mandy.chung at oracle.com Tue Jun 14 22:43:06 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Jun 2016 15:43:06 -0700 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module In-Reply-To: <575F4B82.6050903@oracle.com> References: <575F4B82.6050903@oracle.com> Message-ID: <947C82F0-F6DB-4050-A8B4-2989E98C2C41@oracle.com> > On Jun 13, 2016, at 5:10 PM, Valerie Peng wrote: > > Sean, > > Can you please review the changes for deprivileging the java.smartcardio module? > I have to update one makefile in the top-level workspace besides the java.policy file in the jdk workspace. > One java.smartcardio regression test uses custom policy file which needs to be updated as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 > Webrevs: > top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ > jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ make/common/Modules.gmk change looks okay to me. Mandy From valerie.peng at oracle.com Tue Jun 14 23:05:38 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 14 Jun 2016 16:05:38 -0700 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module In-Reply-To: <57607709.4070506@oracle.com> References: <575F4B82.6050903@oracle.com> <57607709.4070506@oracle.com> Message-ID: <57608DC2.9030807@oracle.com> That sounds better. I will update the test and re-run it. Thanks, Valerie On 6/14/2016 2:28 PM, Sean Mullan wrote: > I don't think you need to make changes to > test/javax/smartcardio/policy. Instead you can change the tests that > use this policy file to use the new jtreg @run > /java.security.policy=policy which extends the default system policy. > > --Sean > > > On 06/13/2016 08:10 PM, Valerie Peng wrote: >> Sean, >> >> Can you please review the changes for deprivileging the java.smartcardio >> module? >> I have to update one makefile in the top-level workspace besides the >> java.policy file in the jdk workspace. >> One java.smartcardio regression test uses custom policy file which needs >> to be updated as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 >> Webrevs: >> top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ >> jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ >> >> Thanks, >> Valerie From gregw at webtide.com Wed Jun 15 00:04:14 2016 From: gregw at webtide.com (Greg Wilkins) Date: Wed, 15 Jun 2016 10:04:14 +1000 Subject: Issues with ALPN implementation in JDK 9 Message-ID: I think this discussion can be simplified to the following points: - ALPN allows for a negotiated application protocol to be a function of the cipher negotiated ( h2 vs h1 selection being the prime use-case). - The cipher is negotiated by SslEngine during the unwrap of the Hello message - The negotiated application protocol is sent by SslEngine during the following wrap of the Hello response. - SslEngined does not allow the negotiated protocol to be set after the unwrap of the Hello message. So this last point means that SslEngine does not allow the negotiated protocol to be a function of the negotiated cipher. Sure there are ways to work around this limitation (guessing, running duplicate sslEngine instances etc.), but we should have to work around limitations in a newly released feature! If SslEngine is changed to allow the negotiated application protocol to be set up until the time the hello response was wrapped, that would fix the problem. Would it create any others? cheers -- Greg Wilkins CTO http://webtide.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Jun 15 00:12:44 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 14 Jun 2016 17:12:44 -0700 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module In-Reply-To: <57608DC2.9030807@oracle.com> References: <575F4B82.6050903@oracle.com> <57607709.4070506@oracle.com> <57608DC2.9030807@oracle.com> Message-ID: <57609D7C.2080205@oracle.com> Re-ran passed. Webrev updated at: http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.01/ Regards, Valerie On 6/14/2016 4:05 PM, Valerie Peng wrote: > That sounds better. I will update the test and re-run it. > Thanks, > Valerie > > On 6/14/2016 2:28 PM, Sean Mullan wrote: >> I don't think you need to make changes to >> test/javax/smartcardio/policy. Instead you can change the tests that >> use this policy file to use the new jtreg @run >> /java.security.policy=policy which extends the default system policy. >> >> --Sean >> >> >> On 06/13/2016 08:10 PM, Valerie Peng wrote: >>> Sean, >>> >>> Can you please review the changes for deprivileging the >>> java.smartcardio >>> module? >>> I have to update one makefile in the top-level workspace besides the >>> java.policy file in the jdk workspace. >>> One java.smartcardio regression test uses custom policy file which >>> needs >>> to be updated as well. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 >>> Webrevs: >>> top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ >>> jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ >>> >>> Thanks, >>> Valerie From xuelei.fan at oracle.com Wed Jun 15 00:20:55 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 08:20:55 +0800 Subject: JDK 9 RFR of JDK-8159502: Mark ShortRSAKey512.java as intermittently failing In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 6/15/2016 5:37 AM, joe darcy wrote: > The test > > javax/net/ssl/TLSv12/ShortRSAKey512.java > > has been seen to intermittently fail (JDK-8159501). The test should be > marked accordingly. > > Please review the patch below which does this. > > Thanks, > > -Joe > > diff -r d6a1ad87842f test/javax/net/ssl/TLSv12/ShortRSAKey512.java > --- a/test/javax/net/ssl/TLSv12/ShortRSAKey512.java Tue Jun 14 > 09:03:12 2016 -0700 > +++ b/test/javax/net/ssl/TLSv12/ShortRSAKey512.java Tue Jun 14 > 14:36:39 2016 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -33,6 +33,7 @@ > * > * SunJSSE does not support dynamic system properties, no way to > re-use > * system properties in samevm/agentvm mode. > + * @key intermittent > * @run main/othervm ShortRSAKey512 PKIX > * @run main/othervm ShortRSAKey512 SunX509 > */ > From weijun.wang at oracle.com Wed Jun 15 00:42:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 08:42:44 +0800 Subject: RFR 8157848: Mark deprecated javax.security.auth.Policy API with forRemoval=true Message-ID: <11BE60E0-2FA1-4AC8-A7D1-EB7CDE3179B8@oracle.com> We intend to remove this API in jdk10. Please take a review on the jdk9/dev patch below: diff --git a/src/java.base/share/classes/javax/security/auth/Policy.java b/src/java.base/share/classes/javax/security/auth/Policy.java --- a/src/java.base/share/classes/javax/security/auth/Policy.java +++ b/src/java.base/share/classes/javax/security/auth/Policy.java @@ -152,10 +152,11 @@ * * These two APIs provide callers the means to query the * Policy for Principal-based Permission entries. + * This class is subject to removal in a future version of Java SE. * * @see java.security.Security security properties */ - at Deprecated + at Deprecated(since="1.4", forRemoval=true) public abstract class Policy { private static Policy policy; Thanks Max From xuelei.fan at oracle.com Wed Jun 15 01:01:25 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 09:01:25 +0800 Subject: RFR 8157848: Mark deprecated javax.security.auth.Policy API with forRemoval=true In-Reply-To: <11BE60E0-2FA1-4AC8-A7D1-EB7CDE3179B8@oracle.com> References: <11BE60E0-2FA1-4AC8-A7D1-EB7CDE3179B8@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/15/2016 8:42 AM, Wang Weijun wrote: > We intend to remove this API in jdk10. Please take a review on the jdk9/dev patch below: > > diff --git a/src/java.base/share/classes/javax/security/auth/Policy.java b/src/java.base/share/classes/javax/security/auth/Policy.java > --- a/src/java.base/share/classes/javax/security/auth/Policy.java > +++ b/src/java.base/share/classes/javax/security/auth/Policy.java > @@ -152,10 +152,11 @@ > * > * These two APIs provide callers the means to query the > * Policy for Principal-based Permission entries. > + * This class is subject to removal in a future version of Java SE. > * > * @see java.security.Security security properties > */ > - at Deprecated > + at Deprecated(since="1.4", forRemoval=true) > public abstract class Policy { > > private static Policy policy; > > Thanks > Max > From jason.greene at redhat.com Wed Jun 15 01:40:42 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 14 Jun 2016 21:40:42 -0400 (EDT) Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: > On Jun 14, 2016, at 7:04 PM, Greg Wilkins wrote: > > If SslEngine is changed to allow the negotiated application protocol to be set up until the time the hello response was wrapped, that would fix the problem. Would it create any others? Well the fundamental issue is that the application protocol isn't a direct function of a cipher, rather the application protocol has a policy of allowed ciphers and optimal selection is finding the most recent protocol with a matching allowed cipher. From gregw at webtide.com Wed Jun 15 02:28:43 2016 From: gregw at webtide.com (Greg Wilkins) Date: Wed, 15 Jun 2016 12:28:43 +1000 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: On 15 June 2016 at 11:40, Jason T. Greene wrote: > > > > On Jun 14, 2016, at 7:04 PM, Greg Wilkins wrote: > > > > If SslEngine is changed to allow the negotiated application protocol to > be set up until the time the hello response was wrapped, that would fix the > problem. Would it create any others? > > Well the fundamental issue is that the application protocol isn't a direct > function of a cipher, rather the application protocol has a policy of > allowed ciphers and optimal selection is finding the most recent protocol > with a matching allowed cipher. So doesn't that make application protocol a function of the negotiated cipher? Isn't working out which of the acceptable protocols allows the negotiated cipher a function? Put another way, it is not possible to implement: Protocol selectProtocol(List mutualAcceptableCiphers, List mutualAcceptableProtocols) such that it always returns a correct result, as a acceptable cipher may not allowable for a given acceptable protocol. Furthermore it ls not possible to implement: String selectProtocol(List> mutualAcceptable) because within that function there is no indication of what ciphers might be negotiated. So further information is needed, which could either be: String selectProtocol(List> mutualAcceptable, List availableCertificates, IPAddress host) Which requires the implementation to rework the certificate selection and SNI logic that is already performed by SslEngine. Either this logic needs to be duplicated (fragile) or an extra instance of SslEngine would need to be used to duplicate the logic. Alternately the function could be implemented as: String selectProtocol(List> mutualAcceptable, Cipher negotiatedCipher) ie a function of the negotiated cipher, but as the negotiatedCipher is known only after the Hello message is unwrapped, this would require that SslEngine allows setApplicationProtocol to be called after the hello unwrap but before the hello response wrap. I guess the other alternative would be to replace the SSLParameters. setApplicationProtocols(List) method with something like: SSLParameters.setApplicationProtocols(Function selectProtocol) or SSLParameters.setApplicationProtocols(List> cipherProtocolPairs) or SSLParameters.setApplicationProtocols(Map> protocolsForCiphers) In short, either the cipher/SNI logic of SslEngine has to be duplicated or the selection of the protocol needs to be deferred until after the cipher is negotiated - either by allowing the setter to be called after negotiation or by giving the SslEngine the information to know what protocols are acceptable for which ciphers. I believe that duplication is unacceptable for a new feature like ALPN. Does anybody really believe that it is acceptable? Are there any other alternatives other than the ones I've outlined above? cheers PS. The Cipher and Protocol types would most likely just be String in all of the above examples. Using strong typing in the examples for clarity. -- Greg Wilkins CTO http://webtide.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jun 15 02:47:02 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 10:47:02 +0800 Subject: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out Message-ID: This test runs slow. I've noticed it timeouts several times with exploded build back in the jigsaw forest. Running with an image build should be faster but it's still safe to add some extra time. Please take a review: diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh --- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh +++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh @@ -25,7 +25,7 @@ # @bug 6802846 # @summary jarsigner needs enhanced cert validation(options) # -# @run shell concise_jarsigner.sh +# @run shell/timeout=240 concise_jarsigner.sh # if [ "${TESTJAVA}" = "" ] ; then Thanks Max From weijun.wang at oracle.com Wed Jun 15 02:58:23 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 10:58:23 +0800 Subject: RFR 8157387: StrongSecureRandom.java timeout after push for JDK-8141039 Message-ID: <71CDEDD3-838F-4DF9-8A25-A599EBD0665A@oracle.com> The tests on non-native SecureRandom implementations are already covered by other tests and can be removed from this one. Please take a review at http://cr.openjdk.java.net/~weijun/8157387/webrev.00 Please note that I also remove another line from ProblemTest.txt because that bug is a dup of an already fixed bug. Thanks Max From xuelei.fan at oracle.com Wed Jun 15 02:58:31 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 10:58:31 +0800 Subject: Code Review Request 8150966 Typo in javax.net.ssl.SSLEngineResult.HandshakeStatus.NEED_UNWRAP_AGAIN Message-ID: <4f08dcf1-c383-5572-321c-c9973bb7ba28@oracle.com> Hi, Please review this spec typo fix. There is an additional word 'can' in the spec "The {@code SSLEngine} needs to unwrap before handshaking can can continue." Here is the update of jdk/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java: /** * The {@code SSLEngine} needs to unwrap before handshaking can - * can continue. + * continue. *

* This value is used to indicate that not-yet-interpreted data * has been previously received from the remote side, and does * not need to be received again. *

* This handshake status only applies to DTLS. * * @since 9 */ NEED_UNWRAP_AGAIN; Thanks, Xuelei From weijun.wang at oracle.com Wed Jun 15 03:03:13 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 11:03:13 +0800 Subject: Code Review Request 8150966 Typo in javax.net.ssl.SSLEngineResult.HandshakeStatus.NEED_UNWRAP_AGAIN In-Reply-To: <4f08dcf1-c383-5572-321c-c9973bb7ba28@oracle.com> References: <4f08dcf1-c383-5572-321c-c9973bb7ba28@oracle.com> Message-ID: <19FAAE79-C065-4B59-8525-1596C170AA17@oracle.com> Looks fine. Thanks Max > On Jun 15, 2016, at 10:58 AM, Xuelei Fan wrote: > > Hi, > > Please review this spec typo fix. There is an additional word 'can' in > the spec "The {@code SSLEngine} needs to unwrap before handshaking can > can continue." > > Here is the update of > jdk/src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java: > > /** > * The {@code SSLEngine} needs to unwrap before handshaking can > - * can continue. > + * continue. > *

> * This value is used to indicate that not-yet-interpreted data > * has been previously received from the remote side, and does > * not need to be received again. > *

> * This handshake status only applies to DTLS. > * > * @since 9 > */ > NEED_UNWRAP_AGAIN; > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Jun 15 03:10:37 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 11:10:37 +0800 Subject: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out In-Reply-To: References: Message-ID: <064892d4-01a6-acf8-ed9e-6a0e1d7e8116@oracle.com> Looks fine to me. Timeout may occurs intermittent because of the load of the platform. Is it safer to use a bigger timeout value? For example 320 or 480. Thanks, Xuelei On 6/15/2016 10:47 AM, Wang Weijun wrote: > This test runs slow. I've noticed it timeouts several times with exploded build back in the jigsaw forest. Running with an image build should be faster but it's still safe to add some extra time. Please take a review: > > diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh > --- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh > +++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh > @@ -25,7 +25,7 @@ > # @bug 6802846 > # @summary jarsigner needs enhanced cert validation(options) > # > -# @run shell concise_jarsigner.sh > +# @run shell/timeout=240 concise_jarsigner.sh > # > > if [ "${TESTJAVA}" = "" ] ; then > > Thanks > Max > From weijun.wang at oracle.com Wed Jun 15 03:12:23 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 11:12:23 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back Message-ID: Please take a review on the patch diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java +++ b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java @@ -354,8 +354,8 @@ // We wait 250milli quanta, so the minimum wait time // cannot be under 250milli. int latch = 0; - long l = System.currentTimeMillis() + 250; - while (System.currentTimeMillis() < l) { + long l = System.nanoTime() + 250000000; + while (System.nanoTime() < l) { synchronized(this){}; latch++; } nanoTime() is for elapsed time and should be used here. Thanks Max From weijun.wang at oracle.com Wed Jun 15 03:13:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 11:13:46 +0800 Subject: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out In-Reply-To: <064892d4-01a6-acf8-ed9e-6a0e1d7e8116@oracle.com> References: <064892d4-01a6-acf8-ed9e-6a0e1d7e8116@oracle.com> Message-ID: <8AC3A79A-FBA7-4689-B668-9AF889FEFC00@oracle.com> Let's use 240 for the moment. If it fails again, maybe it's because of a real bug? Thanks Max > On Jun 15, 2016, at 11:10 AM, Xuelei Fan wrote: > > Looks fine to me. > > Timeout may occurs intermittent because of the load of the platform. Is > it safer to use a bigger timeout value? For example 320 or 480. > > Thanks, > Xuelei > > On 6/15/2016 10:47 AM, Wang Weijun wrote: >> This test runs slow. I've noticed it timeouts several times with exploded build back in the jigsaw forest. Running with an image build should be faster but it's still safe to add some extra time. Please take a review: >> >> diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh >> --- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh >> +++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh >> @@ -25,7 +25,7 @@ >> # @bug 6802846 >> # @summary jarsigner needs enhanced cert validation(options) >> # >> -# @run shell concise_jarsigner.sh >> +# @run shell/timeout=240 concise_jarsigner.sh >> # >> >> if [ "${TESTJAVA}" = "" ] ; then >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Wed Jun 15 03:22:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 11:22:16 +0800 Subject: RFR 8158887: sun/security/tools/jarsigner/concise_jarsigner.sh timed out In-Reply-To: <8AC3A79A-FBA7-4689-B668-9AF889FEFC00@oracle.com> References: <064892d4-01a6-acf8-ed9e-6a0e1d7e8116@oracle.com> <8AC3A79A-FBA7-4689-B668-9AF889FEFC00@oracle.com> Message-ID: <5171333d-e7da-7ec8-3121-3a1e3bc4368d@oracle.com> OK. Xuelei On 6/15/2016 11:13 AM, Wang Weijun wrote: > Let's use 240 for the moment. If it fails again, maybe it's because of a real bug? > > Thanks > Max > >> On Jun 15, 2016, at 11:10 AM, Xuelei Fan wrote: >> >> Looks fine to me. >> >> Timeout may occurs intermittent because of the load of the platform. Is >> it safer to use a bigger timeout value? For example 320 or 480. >> >> Thanks, >> Xuelei >> >> On 6/15/2016 10:47 AM, Wang Weijun wrote: >>> This test runs slow. I've noticed it timeouts several times with exploded build back in the jigsaw forest. Running with an image build should be faster but it's still safe to add some extra time. Please take a review: >>> >>> diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh >>> --- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh >>> +++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh >>> @@ -25,7 +25,7 @@ >>> # @bug 6802846 >>> # @summary jarsigner needs enhanced cert validation(options) >>> # >>> -# @run shell concise_jarsigner.sh >>> +# @run shell/timeout=240 concise_jarsigner.sh >>> # >>> >>> if [ "${TESTJAVA}" = "" ] ; then >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Wed Jun 15 03:36:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 11:36:48 +0800 Subject: RFR 8146619: Re-examine supportness of public classes in com.sun.security.auth.** Message-ID: <137FF95F-4767-481E-AD97-4E22EBC55F71@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8146619/webrev.00/ Basically, the following changes are made to all 7 classes: + * This class is subject to removal in a future version of Java SE. */ - at Deprecated + at Deprecated(since="1.4", forRemoval=true) public class Xyz { I still find it a little uneasy to directly remove them before making an announcement, so we will remove them in jdk10. Thanks Max From mandy.chung at oracle.com Wed Jun 15 03:53:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Jun 2016 20:53:48 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> Message-ID: > On Jun 13, 2016, at 8:28 PM, Wang Weijun wrote: > > OK, please take a review at the new version at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.04/ > The new -addProvider option is good. I mostly reviewed KeyStoreUtil.java and skimmed through other files that I assume the security team will review them in details. 267 * Loads a security provider in a module with its name. This does not limit to modules. It can load security providers from classpath via ServiceLoader. 282 for (Provider p : ServiceLoader.load(Provider.class)) { This should use ServiceLoader.load(Provider.class, ClassLoader.getSystemClassLoader()) instead of loading with TCCL. 291 throw new IllegalArgumentException(); Nit: good to have a message even if it?s not used. 295 * Loads a non-modularized security provider with its full-qualified name. I suggest to reword it to ?Loads a security provider by a fully-qualified class name? move line 306 to 317 241 throw (InvalidParameterException) This cast should not be needed? 319 Class clazz; 320 if (cl != null) { 321 clazz = cl.loadClass(provClass); 322 } else { 323 clazz = Class.forName(provClass); 324 } You should call Class.forName(provClass, false, cl) instead. Mandy From xuelei.fan at oracle.com Wed Jun 15 04:13:33 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 12:13:33 +0800 Subject: RFR 8146619: Re-examine supportness of public classes in com.sun.security.auth.** In-Reply-To: <137FF95F-4767-481E-AD97-4E22EBC55F71@oracle.com> References: <137FF95F-4767-481E-AD97-4E22EBC55F71@oracle.com> Message-ID: <7d6205cf-1238-04f3-3c47-b91c20452dda@oracle.com> Looks fine to me. Xuelei On 6/15/2016 11:36 AM, Wang Weijun wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8146619/webrev.00/ > > Basically, the following changes are made to all 7 classes: > > + * This class is subject to removal in a future version of Java SE. > */ > - at Deprecated > + at Deprecated(since="1.4", forRemoval=true) > public class Xyz { > > I still find it a little uneasy to directly remove them before making an announcement, so we will remove them in jdk10. > > Thanks > Max > > > From aph at redhat.com Wed Jun 15 08:03:39 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Jun 2016 09:03:39 +0100 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: <57610BDB.90609@redhat.com> On 14/06/16 14:57, Simone Bordet wrote: > * Lack of facilities to convert TLS protocol bytes to protocol strings. > This class already exist in JDK, sun.security.ssl.ProtocolVersion, it > would just need to be exposed in javax.net.ssl. > > * Lack of facilities to convert TLS cipher bytes to cipher name strings. > As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly. > > Note that for the 2 bullets above, a recent message from Mark Reinhold > to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I > hope they can be considered for inclusion. It's very late, and they certainly won't be considered unless someone proposes it. But can't we simply clone this class anyway? Incidentally, I can't tell which (if any) of the issues you describe are specific to JDK 9 (i.e. they would not be problems in JDK 8.) Andrew. From simone.bordet at gmail.com Wed Jun 15 08:11:20 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 15 Jun 2016 10:11:20 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57610BDB.90609@redhat.com> References: <57610BDB.90609@redhat.com> Message-ID: Hi, On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley wrote: > On 14/06/16 14:57, Simone Bordet wrote: >> * Lack of facilities to convert TLS protocol bytes to protocol strings. >> This class already exist in JDK, sun.security.ssl.ProtocolVersion, it >> would just need to be exposed in javax.net.ssl. >> >> * Lack of facilities to convert TLS cipher bytes to cipher name strings. >> As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly. >> >> Note that for the 2 bullets above, a recent message from Mark Reinhold >> to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I >> hope they can be considered for inclusion. > > It's very late, It's not too late, like Mark Reinhold said. > and they certainly won't be considered unless > someone proposes it. I just did. > But can't we simply clone this class anyway? Sure, but then every ALPN implementer out there will have their own, they will need to be kept up to date when a new TLS protocol or a new cipher is introduced in the JDK, etc. etc. The TLS ciphers in the JDK have non-standard names for historical reasons, etc. The classes are trivial, and can be tiny wrappers around the existing ones like TLSProtocolNames and CipherSuiteNames. > Incidentally, I can't tell which (if any) of the issues you describe > are specific to JDK 9 (i.e. they would not be problems in JDK 8.) Not sure what you mean here. Unless you parse the TLS protocol in JDK 8, there is no particular need for those classes. With JDK9 we now need to parse the TLS protocol to handle ALPN, so those classes would be handy. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From aph at redhat.com Wed Jun 15 08:15:47 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Jun 2016 09:15:47 +0100 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57610BDB.90609@redhat.com> Message-ID: <57610EB3.905@redhat.com> On 15/06/16 09:11, Simone Bordet wrote: > Sure, but then every ALPN implementer out there will have their own, > they will need to be kept up to date when a new TLS protocol or a new > cipher is introduced in the JDK, etc. etc. OK, I get that. The problem I have with reading posts about JDK9 problems is that I can't tell the *severity* of the problems. I don't know if something is a total blocker or an inconvenience. When someone uses an internal sun.* class they may be doing something which must be done in order to get access which would be impossible otherwise. Andrew. From weijun.wang at oracle.com Wed Jun 15 08:27:25 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 16:27:25 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> Message-ID: <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> All suggestions accepted. Webrev updated at http://cr.openjdk.java.net/~weijun/8130302/webrev.05 > 241 throw (InvalidParameterException) > > This cast should not be needed? > } catch (UcryptoException ue) { throw (InvalidParameterException) new InvalidParameterException("Error using " + configArg). initCause(ue.getCause()); } initCause() returns Throwable but the method's signature throws InvalidParameterException. Thanks Max From simone.bordet at gmail.com Wed Jun 15 08:35:19 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 15 Jun 2016 10:35:19 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57610EB3.905@redhat.com> References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> Message-ID: Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: > The problem I have with reading posts about JDK9 problems is that I > can't tell the *severity* of the problems. I don't know if something > is a total blocker or an inconvenience. When someone uses an internal > sun.* class they may be doing something which must be done in order to > get access which would be impossible otherwise. I don't understand this comment. The main issue of this thread is the current impossibility to have a clean and precise ALPN implementation with minimal code. Sure we can fallback to less optimal solutions that won't work in all cases. Sure we can duplicate the JDK logic and keep it up-to-date, invoke SNI twice, etc. But I don't see the point of settling for a less than optimal solution when there is room to make it better, and the effort is minimal. Is this issue a blocker ? Surely not, it is possible to rewrite from scratch a JSSE provider. Would I do that ? No, thanks. I am proposing 3 simple changes to be done: 1) Introduce a TLSProtocolNames class that can convert from TLS protocol bytes to TLS protocol names. 2) Introduce a TLSCipherSuiteNames class that can convert from TLS cipher suite bytes to TLS cipher suite names. 3) Delay handshaker.started=true so that it would simpler and more precise for an application to handle ALPN. I think these changes will benefit all the people involved in network servers having to play with ALPN. We *are* still in time, according to Mark Reinhold. The changes are simple. We have not heard from Oracle yet, but I can prepare a webrev if that helps. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jaroslav at kamenik.cz Wed Jun 15 08:50:32 2016 From: jaroslav at kamenik.cz (=?UTF-8?Q?Jaroslav_Kamen=C3=ADk?=) Date: Wed, 15 Jun 2016 10:50:32 +0200 Subject: JDK-8144566 Message-ID: Hi, could you please backport fix for this bug into JDK8? We run into it recently, our use case works well with JDK9, but it is long time to official release.. Thanx:). Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Wed Jun 15 11:31:46 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Jun 2016 06:31:46 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> Message-ID: <57613CA2.2030803@redhat.com> On 06/15/2016 03:35 AM, Simone Bordet wrote: > Hi, > > On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: >> The problem I have with reading posts about JDK9 problems is that I >> can't tell the *severity* of the problems. I don't know if something >> is a total blocker or an inconvenience. When someone uses an internal >> sun.* class they may be doing something which must be done in order to >> get access which would be impossible otherwise. > > I don't understand this comment. > > The main issue of this thread is the current impossibility to have a > clean and precise ALPN implementation with minimal code. The problem is that this is quite subjective. In my opinion the current solution is both clean and precise: 1) Read the hello packet 2) Examine the protocols, host names, and cipher suites 3) Apply arbitrary user policy to select the enabled cipher suites and even possibly the SSL context to use based on: * The above information * The supported cipher suites (for each SSL context, if multiple) * The available host key types for each host and/or protocol * Any user-driven factor that goes beyond *just* HTTP 2 No matter what the JDK does, it will not be able to encapsulate a completely arbitrary user policy - certainly not precisely - during handshake, nor will it be able to allow for the selection of different SSLContexts based on that policy (let alone proxying the connection). The best that can be done in the JDK, in my opinion, is to provide various utilities to simplify implementing the above: a helpful SSL explorer style class, which includes mapping the protocol and cipher suite list (which I believe we agree on) and perhaps providing information about the key type(s) supported by each cipher suite, so the user can compare this against the available key types. Once you know what cipher suites are offered, and you have selected the protocol, host, and enabled cipher suites, there isn't a great deal of mystery left in the JDK: it simply carries out the negotiation that you specified. > Sure we can fallback to less optimal solutions that won't work in all cases. > Sure we can duplicate the JDK logic and keep it up-to-date, invoke SNI > twice, etc. > But I don't see the point of settling for a less than optimal solution > when there is room to make it better, and the effort is minimal. > > Is this issue a blocker ? Surely not, it is possible to rewrite from > scratch a JSSE provider. > Would I do that ? No, thanks. > > I am proposing 3 simple changes to be done: > > 1) Introduce a TLSProtocolNames class that can convert from TLS > protocol bytes to TLS protocol names. > 2) Introduce a TLSCipherSuiteNames class that can convert from TLS > cipher suite bytes to TLS cipher suite names. > 3) Delay handshaker.started=true so that it would simpler and more > precise for an application to handle ALPN. I agree with 1 and 2, at least in concept if not in specifics, but I think 3 is a mistake: if you've committed to an SSL context then it's already too late to make some possibly important decisions, and SNI can play a factor here too. We can make this easier but I think that trying to do this all inside of the handshake process is going to cut off some important use cases. > I think these changes will benefit all the people involved in network > servers having to play with ALPN. > > We *are* still in time, according to Mark Reinhold. > The changes are simple. > > We have not heard from Oracle yet, but I can prepare a webrev if that helps. > -- - DML From sean.mullan at oracle.com Wed Jun 15 11:33:14 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Jun 2016 07:33:14 -0400 Subject: [9] RFR 8154191: Deprivilege java.smartcardio module In-Reply-To: <57609D7C.2080205@oracle.com> References: <575F4B82.6050903@oracle.com> <57607709.4070506@oracle.com> <57608DC2.9030807@oracle.com> <57609D7C.2080205@oracle.com> Message-ID: <57613CFA.2000102@oracle.com> Looks fine. --Sean On 06/14/2016 08:12 PM, Valerie Peng wrote: > Re-ran passed. > Webrev updated at: > http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.01/ > Regards, > Valerie > > On 6/14/2016 4:05 PM, Valerie Peng wrote: >> That sounds better. I will update the test and re-run it. >> Thanks, >> Valerie >> >> On 6/14/2016 2:28 PM, Sean Mullan wrote: >>> I don't think you need to make changes to >>> test/javax/smartcardio/policy. Instead you can change the tests that >>> use this policy file to use the new jtreg @run >>> /java.security.policy=policy which extends the default system policy. >>> >>> --Sean >>> >>> >>> On 06/13/2016 08:10 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Can you please review the changes for deprivileging the >>>> java.smartcardio >>>> module? >>>> I have to update one makefile in the top-level workspace besides the >>>> java.policy file in the jdk workspace. >>>> One java.smartcardio regression test uses custom policy file which >>>> needs >>>> to be updated as well. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154191 >>>> Webrevs: >>>> top-level=> http://cr.openjdk.java.net/~valeriep/8154191/webrev.00/ >>>> jdk=> http://cr.openjdk.java.net/~valeriep/8154191/jdk/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From xuelei.fan at oracle.com Wed Jun 15 12:00:20 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 20:00:20 +0800 Subject: RFR 8157387: StrongSecureRandom.java timeout after push for JDK-8141039 In-Reply-To: <71CDEDD3-838F-4DF9-8A25-A599EBD0665A@oracle.com> References: <71CDEDD3-838F-4DF9-8A25-A599EBD0665A@oracle.com> Message-ID: <8ac8098a-936c-e0f6-6922-6825d63151ad@oracle.com> Looks fine to me. Xuelei On 6/15/2016 10:58 AM, Wang Weijun wrote: > The tests on non-native SecureRandom implementations are already covered by other tests and can be removed from this one. Please take a review at > > http://cr.openjdk.java.net/~weijun/8157387/webrev.00 > > Please note that I also remove another line from ProblemTest.txt because that bug is a dup of an already fixed bug. > > Thanks > Max > From david.lloyd at redhat.com Wed Jun 15 12:07:30 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Jun 2016 07:07:30 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: Message-ID: <57614502.2080202@redhat.com> On 06/14/2016 09:28 PM, Greg Wilkins wrote: > > > On 15 June 2016 at 11:40, Jason T. Greene > wrote: > > > > On Jun 14, 2016, at 7:04 PM, Greg Wilkins > wrote: > > > > If SslEngine is changed to allow the negotiated application protocol to be set up until the time the hello response was wrapped, that would fix the problem. Would it create any others? > > Well the fundamental issue is that the application protocol isn't a > direct function of a cipher, rather the application protocol has a > policy of allowed ciphers and optimal selection is finding the most > recent protocol with a matching allowed cipher. > > > So doesn't that make application protocol a function of the negotiated > cipher? Isn't working out which of the acceptable protocols allows > the negotiated cipher a function? No, you can't take the ciphers and spit out a protocol during handshake. You also have to consider the host name(s) and available key(s) for each, and in addition you might have separate (possibly pre-existing) SSL contexts for different protocols (after all, protocols aren't just limited to two flavors of HTTP), or you might even want to proxy the connection instead of handling it locally in certain cases. But leaving the multiple-SSLContext case aside, the pieces of information that are relevant are: * The requested cipher suites and TLS protocol version * The requested ALPN protocol names (the name, BTW, is all that appears in the ClientHello) * The requested SNI server names * The SSL context's supported TLS protocol and cipher suite lists * The available server key(s) (and possibly client key(s) as well), which may vary by host as well as by ALPN protocol * A way to determine which cipher suites can use which key types * A way to determine which cipher suites can/should be used with which TLS protocol versions * Information about which cipher suites are supported by various ALPN protocols Some of these bits of information are already an existing part of the handshake but are done too late in the process to be useful to protocol or host selection (for example, choosing a key by key type or trimming the cipher suite list by TLS protocol version). Some of this information varies by ALPN protocol, and thus (IMO) has no place in the JDK, rather belonging in the protocol server code (for example, the policy as to which cipher suites are blacklisted by the ALPN protocol). You can definitely encapsulate some of this in a general "SSL connection information" structure, which is in fact what we (JBoss) are doing now. But the fact remains that you have to do all of this analysis before handshake starts for it to work. And you can't avoid duplicating some of the decisions that the target SSL engine has to make. > [...] > In short, either the cipher/SNI logic of SslEngine has to be duplicated > or the selection of the protocol needs to be deferred until after the > cipher is negotiated - either by allowing the setter to be called after > negotiation or by giving the SslEngine the information to know what > protocols are acceptable for which ciphers. But, you can't negotiate the cipher without considering the ALPN protocol. It's not a one-way decision where the protocol decides the cipher suite. You have to choose a protocol which has a chance to succeed because the corresponding cipher suites and key, but also you choose the cipher suites based on the policy of the protocol and available keys. The decision has to be made all at once, otherwise you risk choosing a protocol and cipher suite for which you have no key, or a protocol and key for which there is no matching cipher suite, etc. > I believe that duplication is unacceptable for a new feature like ALPN. > Does anybody really believe that it is acceptable? > Are there any other alternatives other than the ones I've outlined above? Well, I agree it's not ideal. But I do not think a better (and also achievable) option has yet been proposed which does not exclude important use cases. The current approach has the distinct advantage of being workable, imperfect though it may seem. -- - DML From xuelei.fan at oracle.com Wed Jun 15 12:07:31 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Jun 2016 20:07:31 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: References: Message-ID: I'm not sure I understand the while loop. But this update looks fine to me as it does not change the logic of the code except to use elapsed time. Xuelei On 6/15/2016 11:12 AM, Wang Weijun wrote: > Please take a review on the patch > > diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > +++ b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > @@ -354,8 +354,8 @@ > // We wait 250milli quanta, so the minimum wait time > // cannot be under 250milli. > int latch = 0; > - long l = System.currentTimeMillis() + 250; > - while (System.currentTimeMillis() < l) { > + long l = System.nanoTime() + 250000000; > + while (System.nanoTime() < l) { > synchronized(this){}; > latch++; > } > > nanoTime() is for elapsed time and should be used here. > > Thanks > Max > From simone.bordet at gmail.com Wed Jun 15 12:36:57 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 15 Jun 2016 14:36:57 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57613CA2.2030803@redhat.com> References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> <57613CA2.2030803@redhat.com> Message-ID: Hi, On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: > The problem is that this is quite subjective. In my opinion the current > solution is both clean and precise: > > 1) Read the hello packet > 2) Examine the protocols, host names, and cipher suites > 3) Apply arbitrary user policy to select the enabled cipher suites and even > possibly the SSL context to use based on: > * The above information > * The supported cipher suites (for each SSL context, if multiple) > * The available host key types for each host and/or protocol > * Any user-driven factor that goes beyond *just* HTTP 2 Sure, that's the duplication of what the JDK does. Change logic in the JDK, change logic above. How do you avoid to run the application SNI logic twice, once by you, and once by the JDK ? What if that SNI logic, provided by an external application, has side effects ? Your bullets above are "precise" only under the assumption that those bullets are exactly what the JDK does. If it's not the case, then they're broken. I understand for you is not a big deal to replicate the JDK logic and keeping it up to date, and banning certain versions of your code to run with certain versions of the JDK. I hope you understand it's not the case for others; for example, we don't control with what JDK versions people run Jetty. If JDK 10 changes the logic, we will have to say: "Oh, sorry, you cannot run Jetty 9 (the current version) with JDK 10". And we won't be able to change the logic in Jetty 9, because we would break previous JDKs. We will be back to sniffing what JDK it is. Yuck. > No matter what the JDK does, it will not be able to encapsulate a completely > arbitrary user policy - certainly not precisely - during handshake, nor will > it be able to allow for the selection of different SSLContexts based on that > policy (let alone proxying the connection). Can you detail a case ? > The best that can be done in the > JDK, in my opinion, is to provide various utilities to simplify implementing > the above: a helpful SSL explorer style class, which includes mapping the > protocol and cipher suite list (which I believe we agree on) and perhaps > providing information about the key type(s) supported by each cipher suite, > so the user can compare this against the available key types. Unfortunately this SSL Explorer class has not yet been provided. If it was, it would be helpful. But I think it will just hit the same problems I hit: logic duplication and running SNI twice. > Once you know what cipher suites are offered, and you have selected the > protocol, host, and enabled cipher suites, there isn't a great deal of > mystery left in the JDK: it simply carries out the negotiation that you > specified. IFF your logic is the same as the JDK. I don't want to check this every time a JDK release is made. Why you enjoy doing this this check, it's a mystery to me :) > I agree with 1 and 2, at least in concept if not in specifics, but I think 3 is a mistake: > if you've committed to an SSL context then it's already too late to make some > possibly important decisions, and SNI can play a factor here too. > We can make this easier but I think that trying to do this all inside of the > handshake process is going to cut off some important use cases. Which use cases ? BTW, the delay of handshaker.started=true would be irrelevant to the TLS mechanism, it's just an implementation detail. The information that needs to be reported in the ServerHello is only needed when the ServerHello is being constructed. Had the JDK implementation been written with a delayed handshaker.started=true we would have the best of both worlds. You could write your own solution, we could write our own. Yours will have some restrictions, and so will ours (just different ones). Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From david.lloyd at redhat.com Wed Jun 15 13:00:43 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Jun 2016 08:00:43 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> <57613CA2.2030803@redhat.com> Message-ID: <5761517B.5010107@redhat.com> On 06/15/2016 07:36 AM, Simone Bordet wrote: > Hi, > > On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: >> The problem is that this is quite subjective. In my opinion the current >> solution is both clean and precise: >> >> 1) Read the hello packet >> 2) Examine the protocols, host names, and cipher suites >> 3) Apply arbitrary user policy to select the enabled cipher suites and even >> possibly the SSL context to use based on: >> * The above information >> * The supported cipher suites (for each SSL context, if multiple) >> * The available host key types for each host and/or protocol >> * Any user-driven factor that goes beyond *just* HTTP 2 > > Sure, that's the duplication of what the JDK does. > Change logic in the JDK, change logic above. Sure, the JDK has the same logic but does it go beyond matching the key type with the cipher suite? You can't avoid doing this in the user handler AFAICT, so yes that duplication stands. What kind of change in the JDK logic are you thinking of? > How do you avoid to run the application SNI logic twice, once by you, > and once by the JDK ? You can't avoid it. But this is different logic: the user chooses which host to use (and what SSL context, key, etc.) and the JDK simply verifies that choice. > What if that SNI logic, provided by an external application, has side effects ? > > Your bullets above are "precise" only under the assumption that those > bullets are exactly what the JDK does. > If it's not the case, then they're broken. > > I understand for you is not a big deal to replicate the JDK logic and > keeping it up to date, and banning certain versions of your code to > run with certain versions of the JDK. > I hope you understand it's not the case for others; for example, we > don't control with what JDK versions people run Jetty. > > If JDK 10 changes the logic, we will have to say: "Oh, sorry, you > cannot run Jetty 9 (the current version) with JDK 10". > And we won't be able to change the logic in Jetty 9, because we would > break previous JDKs. > We will be back to sniffing what JDK it is. Yuck. > >> No matter what the JDK does, it will not be able to encapsulate a completely >> arbitrary user policy - certainly not precisely - during handshake, nor will >> it be able to allow for the selection of different SSLContexts based on that >> policy (let alone proxying the connection). > > Can you detail a case ? A very simple case: you have two completely different protocols multiplexed on port 443. Each of these protocols has its own SSLContext. You read the client hello and dispatch to the appropriate downstream service based on protocol (and possibly other factors). Another case is that you have a service running on a separate system. If the protocol and/or host matches, the network connection is proxied to the downstream system, otherwise it is handled locally. >> The best that can be done in the >> JDK, in my opinion, is to provide various utilities to simplify implementing >> the above: a helpful SSL explorer style class, which includes mapping the >> protocol and cipher suite list (which I believe we agree on) and perhaps >> providing information about the key type(s) supported by each cipher suite, >> so the user can compare this against the available key types. > > Unfortunately this SSL Explorer class has not yet been provided. > If it was, it would be helpful. But I think it will just hit the same > problems I hit: logic duplication and running SNI twice. > >> Once you know what cipher suites are offered, and you have selected the >> protocol, host, and enabled cipher suites, there isn't a great deal of >> mystery left in the JDK: it simply carries out the negotiation that you >> specified. > > IFF your logic is the same as the JDK. > > I don't want to check this every time a JDK release is made. > Why you enjoy doing this this check, it's a mystery to me :) > >> I agree with 1 and 2, at least in concept if not in specifics, but I think 3 is a mistake: >> if you've committed to an SSL context then it's already too late to make some >> possibly important decisions, and SNI can play a factor here too. >> We can make this easier but I think that trying to do this all inside of the >> handshake process is going to cut off some important use cases. > > Which use cases ? Multiple SSLContext, network proxying. > BTW, the delay of handshaker.started=true would be irrelevant to the > TLS mechanism, it's just an implementation detail. > The information that needs to be reported in the ServerHello is only > needed when the ServerHello is being constructed. > > Had the JDK implementation been written with a delayed > handshaker.started=true we would have the best of both worlds. > You could write your own solution, we could write our own. > Yours will have some restrictions, and so will ours (just different ones). Fair enough. -- - DML From mandy.chung at oracle.com Wed Jun 15 14:57:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Jun 2016 07:57:32 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> Message-ID: <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> > On Jun 15, 2016, at 1:27 AM, Wang Weijun wrote: > > All suggestions accepted. Webrev updated at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.05 > >> 241 throw (InvalidParameterException) >> >> This cast should not be needed? >> > > } catch (UcryptoException ue) { > throw (InvalidParameterException) > new InvalidParameterException("Error using " + configArg). > initCause(ue.getCause()); > } > > initCause() returns Throwable but the method's signature throws InvalidParameterException. > Perhaps have a local variable for InvalidParameterException exception. Mandy From weijun.wang at oracle.com Wed Jun 15 15:40:27 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 15 Jun 2016 23:40:27 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> References: <794bd57c-66d6-73e6-7387-be8697c356ba@oracle.com> <56C57FF8.2010205@oracle.com> <56C5946C.1020806@oracle.com> <99442C80-5980-4F01-929D-472BAF6A003D@oracle.com> <56C6D55B.2070600@oracle.com> <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> Message-ID: <7A8A9004-C1DB-4CCD-9119-62DF352C5888@oracle.com> > On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: > >>> 241 throw (InvalidParameterException) >>> >>> This cast should not be needed? >>> >> >> } catch (UcryptoException ue) { >> throw (InvalidParameterException) >> new InvalidParameterException("Error using " + configArg). >> initCause(ue.getCause()); >> } >> >> initCause() returns Throwable but the method's signature throws InvalidParameterException. >> > > Perhaps have a local variable for InvalidParameterException exception. Valerie, are you OK with this? --Max > > Mandy From sean.coffey at oracle.com Wed Jun 15 16:23:06 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Jun 2016 17:23:06 +0100 Subject: JDK-8144566 In-Reply-To: References: Message-ID: <576180EA.4030207@oracle.com> Looks like a good candidate for backporting to jdk8u-dev. A backport record has been opened. Regards, Sean. On 15/06/16 09:50, Jaroslav Kamen?k wrote: > Hi, > > could you please backport fix for this bug into JDK8? > We run into it recently, our use case works well with > JDK9, but it is long time to official release.. Thanx:). > > Jaroslav From jason.greene at redhat.com Wed Jun 15 18:12:08 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 15 Jun 2016 13:12:08 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57614502.2080202@redhat.com> References: <57614502.2080202@redhat.com> Message-ID: > On Jun 15, 2016, at 7:07 AM, David M. Lloyd wrote: > > On 06/14/2016 09:28 PM, Greg Wilkins wrote: >> >> >> On 15 June 2016 at 11:40, Jason T. Greene > > wrote: >> >> >> > On Jun 14, 2016, at 7:04 PM, Greg Wilkins > wrote: >> > >> > If SslEngine is changed to allow the negotiated application protocol to be set up until the time the hello response was wrapped, that would fix the problem. Would it create any others? >> >> Well the fundamental issue is that the application protocol isn't a >> direct function of a cipher, rather the application protocol has a >> policy of allowed ciphers and optimal selection is finding the most >> recent protocol with a matching allowed cipher. >> >> >> So doesn't that make application protocol a function of the negotiated >> cipher? Isn't working out which of the acceptable protocols allows >> the negotiated cipher a function? > > No, you can't take the ciphers and spit out a protocol during handshake. You also have to consider the host name(s) and available key(s) for each, and in addition you might have separate (possibly pre-existing) SSL contexts for different protocols (after all, protocols aren't just limited to two flavors of HTTP), or you might even want to proxy the connection instead of handling it locally in certain cases. > > But leaving the multiple-SSLContext case aside, the pieces of information that are relevant are: -snip- Here is an H2 example: The ClientHello expressing interest in both h2, and h1, and lists the ciphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 So in this case the client is expressing a preference for a CBC cipher using stronger keys, but is blacklisted by h2 due to not being GCM, but this is allowed by h1. The JDK will follow the client hello as the TLS spec describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and the protocol stack will incorrectly select h1. Now technically H2 clients can avoid this by ordering h2 compliant ciphers on top, but they might not do so. The flaw really starts to show when you have multiple alternative protocols with completely different requirements. As an example, if you have a hypothetical protocol which does not perform certificate based authentication, and instead utilizes pre-shared keys or anonymous ciphers, that protocol can never be selected unless those algs are on the top of the list, if they are on the top of the list then h2 can?t be selected. -Jason From simone.bordet at gmail.com Wed Jun 15 19:25:17 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 15 Jun 2016 21:25:17 +0200 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57614502.2080202@redhat.com> Message-ID: Hi, On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene wrote: > Here is an H2 example: > > The ClientHello expressing interest in both h2, and h1, and lists the ciphers: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > So in this case the client is expressing a preference for a CBC cipher using stronger keys, but is blacklisted by h2 due to not being GCM, but this is allowed by h1. The JDK will follow the client hello as the TLS spec describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and the protocol stack will incorrectly select h1. > > Now technically H2 clients can avoid this by ordering h2 compliant ciphers on top, but they might not do so. > > The flaw really starts to show when you have multiple alternative protocols with completely different requirements. As an example, if you have a hypothetical protocol which does not perform certificate based authentication, and instead utilizes pre-shared keys or anonymous ciphers, that protocol can never be selected unless those algs are on the top of the list, if they are on the top of the list then h2 can?t be selected. > I'm not sure what you want to show here. If you want to prefer ciphers, you have to give up on protocol and viceversa, that's normal business. If there is no decision, then there is a conflict; if there is a decision, then the solution I propose works equally well to what you guys propose. There is no "flaw", it is just undecidable. What am I missing ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From jason.greene at redhat.com Wed Jun 15 19:35:59 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 15 Jun 2016 14:35:59 -0500 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57614502.2080202@redhat.com> Message-ID: > On Jun 15, 2016, at 2:25 PM, Simone Bordet wrote: > > Hi, > > On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene wrote: >> Here is an H2 example: >> >> The ClientHello expressing interest in both h2, and h1, and lists the ciphers: >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> So in this case the client is expressing a preference for a CBC cipher using stronger keys, but is blacklisted by h2 due to not being GCM, but this is allowed by h1. The JDK will follow the client hello as the TLS spec describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and the protocol stack will incorrectly select h1. >> >> Now technically H2 clients can avoid this by ordering h2 compliant ciphers on top, but they might not do so. >> >> The flaw really starts to show when you have multiple alternative protocols with completely different requirements. As an example, if you have a hypothetical protocol which does not perform certificate based authentication, and instead utilizes pre-shared keys or anonymous ciphers, that protocol can never be selected unless those algs are on the top of the list, if they are on the top of the list then h2 can?t be selected. >> > > I'm not sure what you want to show here. > If you want to prefer ciphers, you have to give up on protocol and > viceversa, that's normal business. > > If there is no decision, then there is a conflict; if there is a > decision, then the solution I propose works equally well to what you > guys propose. > > There is no "flaw", it is just undecidable. > What am I missing ? The point is that protocol isn?t a function of cipher, rather protocol and cipher are two inputs that must be cooperatively analyzed when making a decision. If H2 is the preferred protocol, then you analyze the cipher set to find the most preferred compliant match. So the best outcome is cipher = TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256? & protocol = h2. If there isn?t a compliant h2 match, then you fall back to h1. -Jason From gregw at webtide.com Wed Jun 15 21:36:00 2016 From: gregw at webtide.com (Greg Wilkins) Date: Thu, 16 Jun 2016 07:36:00 +1000 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: <57613CA2.2030803@redhat.com> References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> <57613CA2.2030803@redhat.com> Message-ID: On 15 June 2016 at 21:31, David M. Lloyd wrote: > > >> I am proposing 3 simple changes to be done: >> >> 1) Introduce a TLSProtocolNames class that can convert from TLS >> protocol bytes to TLS protocol names. >> 2) Introduce a TLSCipherSuiteNames class that can convert from TLS >> cipher suite bytes to TLS cipher suite names. >> 3) Delay handshaker.started=true so that it would simpler and more >> precise for an application to handle ALPN. >> > > I agree with 1 and 2, at least in concept if not in specifics, but I think > 3 is a mistake: if you've committed to an SSL context then it's already too > late to make some possibly important decisions, and SNI can play a factor > here too. We can make this easier but I think that trying to do this all > inside of the handshake process is going to cut off some important use > cases. > >> >> Note that with 3 : - Not all decisions have to be made late. Some logic will need to be executed before unwrapping hello, such as trimming the set of available ciphers to mutually acceptable ones. - You are still free to pick a protocol early - ie before hello unwrap if you can/want The process we are working towards in jetty is three phase: firstly we trim ciphers and protocol list; then we allow SslEngine to pick the specific cipher (using certificates and/or SNI); finally we want to pick the protocol based on the cipher AND the earlier work trimming ciphers/protocols. So definitely don't want to "do this all inside of the handshake process". Just want to ability to make the final protocol choice after the final cipher decision has been made in the hello unwrap. Again, this would be optional and you could do it all before if you don't want to support the edge cases where this is needed. cheers -- Greg Wilkins CTO http://webtide.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Wed Jun 15 22:30:19 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 15 Jun 2016 15:30:19 -0700 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: References: Message-ID: Looks good, Max, thanks for taking this over. Xuelei, it's a threaded accumulator, which feeds into the seed generator. We wait a certain amount of time before generating the values. Brad On 6/15/2016 5:07 AM, Xuelei Fan wrote: > I'm not sure I understand the while loop. But this update looks fine to > me as it does not change the logic of the code except to use elapsed time. > > Xuelei > > On 6/15/2016 11:12 AM, Wang Weijun wrote: >> Please take a review on the patch >> >> diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> +++ b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> @@ -354,8 +354,8 @@ >> // We wait 250milli quanta, so the minimum wait time >> // cannot be under 250milli. >> int latch = 0; >> - long l = System.currentTimeMillis() + 250; >> - while (System.currentTimeMillis() < l) { >> + long l = System.nanoTime() + 250000000; >> + while (System.nanoTime() < l) { >> synchronized(this){}; >> latch++; >> } >> >> nanoTime() is for elapsed time and should be used here. >> >> Thanks >> Max >> > From bradford.wetmore at oracle.com Wed Jun 15 22:32:12 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 15 Jun 2016 15:32:12 -0700 Subject: RFR 8157387: StrongSecureRandom.java timeout after push for JDK-8141039 In-Reply-To: <8ac8098a-936c-e0f6-6922-6825d63151ad@oracle.com> References: <71CDEDD3-838F-4DF9-8A25-A599EBD0665A@oracle.com> <8ac8098a-936c-e0f6-6922-6825d63151ad@oracle.com> Message-ID: Ditto. Brad On 6/15/2016 5:00 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 6/15/2016 10:58 AM, Wang Weijun wrote: >> The tests on non-native SecureRandom implementations are already covered by other tests and can be removed from this one. Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8157387/webrev.00 >> >> Please note that I also remove another line from ProblemTest.txt because that bug is a dup of an already fixed bug. >> >> Thanks >> Max >> > From david.lloyd at redhat.com Wed Jun 15 22:37:34 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Jun 2016 17:37:34 -0500 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: References: Message-ID: <5761D8AE.8030003@redhat.com> This will not work because System.nanoTime() can be negative and wrap around. You can't compare one nanoTime to another, only differences are useful. On 06/15/2016 05:30 PM, Bradford Wetmore wrote: > Looks good, Max, thanks for taking this over. > > Xuelei, it's a threaded accumulator, which feeds into the seed > generator. We wait a certain amount of time before generating the values. > > Brad > > > On 6/15/2016 5:07 AM, Xuelei Fan wrote: >> I'm not sure I understand the while loop. But this update looks fine to >> me as it does not change the logic of the code except to use elapsed >> time. >> >> Xuelei >> >> On 6/15/2016 11:12 AM, Wang Weijun wrote: >>> Please take a review on the patch >>> >>> diff --git >>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>> >>> --- >>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>> +++ >>> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>> @@ -354,8 +354,8 @@ >>> // We wait 250milli quanta, so the minimum >>> wait time >>> // cannot be under 250milli. >>> int latch = 0; >>> - long l = System.currentTimeMillis() + 250; >>> - while (System.currentTimeMillis() < l) { >>> + long l = System.nanoTime() + 250000000; >>> + while (System.nanoTime() < l) { >>> synchronized(this){}; >>> latch++; >>> } >>> >>> nanoTime() is for elapsed time and should be used here. >>> >>> Thanks >>> Max >>> >> -- - DML From valerie.peng at oracle.com Wed Jun 15 23:50:50 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 Jun 2016 16:50:50 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <7A8A9004-C1DB-4CCD-9119-62DF352C5888@oracle.com> References: <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! cle.com> Message-ID: <5761E9DA.6040205@oracle.com> No big difference to me. Valerie On 6/15/2016 8:40 AM, Wang Weijun wrote: >> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >> >>>> 241 throw (InvalidParameterException) >>>> >>>> This cast should not be needed? >>>> >>> } catch (UcryptoException ue) { >>> throw (InvalidParameterException) >>> new InvalidParameterException("Error using " + configArg). >>> initCause(ue.getCause()); >>> } >>> >>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>> >> Perhaps have a local variable for InvalidParameterException exception. > Valerie, are you OK with this? > > --Max > >> Mandy From bradford.wetmore at oracle.com Thu Jun 16 00:05:33 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 15 Jun 2016 17:05:33 -0700 Subject: Issues with ALPN implementation in JDK 9 In-Reply-To: References: <57610BDB.90609@redhat.com> <57610EB3.905@redhat.com> Message-ID: On 6/15/2016 1:35 AM, Simone Bordet wrote: > We have not heard from Oracle yet, but I can prepare a webrev if that helps. Hi all, Nice to see different folks are trying things out. I do appreciate the discussion/feedback. I am on a high-priority project right now, so I haven't had a chance to parse/respond to the discussion, but should be able to cycle back to this in 1-2 weeks. Best, Brad From valerie.peng at oracle.com Thu Jun 16 00:48:55 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 Jun 2016 17:48:55 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) Message-ID: <5761F777.5030506@oracle.com> Any one has cycles to review this? Although the number of updated files are not trivial, but the key changes are in only 2 files, i.e. src/java.base/share/classes/java/security/Provider.java and src/java.base/share/classes/java/security/AuthProvider.java. The rest of files are all very trivial, just changing the double version number to string. Instead of hardcoded values, I make most of them refer to the new PROVIDER_VER field of the sun.security.util.SecurityConstants class, so the providers would be automatically updated and use the "java.specification.version" system property value as its version string. Bug: https://bugs.openjdk.java.net/browse/JDK-8130181 Webrev: http://cr.openjdk.java.net/~valeriep/8130181/webrev.00/ Valerie From weijun.wang at oracle.com Thu Jun 16 01:33:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 09:33:08 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <5761E9DA.6040205@oracle.com> References: <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! cle.com> <5761E9DA.6040205@oracle.com> Message-ID: > On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: > > No big difference to me. Good, I'll remove the cast. @security-dev, can someone approve the whole webrev.05? http://cr.openjdk.java.net/~weijun/8130302/webrev.05 Thanks Max > Valerie > > On 6/15/2016 8:40 AM, Wang Weijun wrote: >>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>> >>>>> 241 throw (InvalidParameterException) >>>>> >>>>> This cast should not be needed? >>>>> >>>> } catch (UcryptoException ue) { >>>> throw (InvalidParameterException) >>>> new InvalidParameterException("Error using " + configArg). >>>> initCause(ue.getCause()); >>>> } >>>> >>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>> >>> Perhaps have a local variable for InvalidParameterException exception. >> Valerie, are you OK with this? >> >> --Max >> >>> Mandy From weijun.wang at oracle.com Thu Jun 16 02:32:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 10:32:40 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: <5761D8AE.8030003@redhat.com> References: <5761D8AE.8030003@redhat.com> Message-ID: <42EDA943-0126-448B-AB61-4AADE285A651@oracle.com> > On Jun 16, 2016, at 6:37 AM, David M. Lloyd wrote: > > This will not work because System.nanoTime() can be negative and wrap around. You can't compare one nanoTime to another, only differences are useful. Yes, you are right. How about this then? diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java +++ b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java @@ -354,8 +354,8 @@ // We wait 250milli quanta, so the minimum wait time // cannot be under 250milli. int latch = 0; - long l = System.currentTimeMillis() + 250; - while (System.currentTimeMillis() < l) { + long l = System.nanoTime(); + while (System.nanoTime() - l < 250000000) { synchronized(this){}; latch++; } Thanks Max > > On 06/15/2016 05:30 PM, Bradford Wetmore wrote: >> Looks good, Max, thanks for taking this over. >> >> Xuelei, it's a threaded accumulator, which feeds into the seed >> generator. We wait a certain amount of time before generating the values. >> >> Brad >> >> >> On 6/15/2016 5:07 AM, Xuelei Fan wrote: >>> I'm not sure I understand the while loop. But this update looks fine to >>> me as it does not change the logic of the code except to use elapsed >>> time. >>> >>> Xuelei >>> >>> On 6/15/2016 11:12 AM, Wang Weijun wrote: >>>> Please take a review on the patch >>>> >>>> diff --git >>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>> >>>> --- >>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>> +++ >>>> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>> @@ -354,8 +354,8 @@ >>>> // We wait 250milli quanta, so the minimum >>>> wait time >>>> // cannot be under 250milli. >>>> int latch = 0; >>>> - long l = System.currentTimeMillis() + 250; >>>> - while (System.currentTimeMillis() < l) { >>>> + long l = System.nanoTime() + 250000000; >>>> + while (System.nanoTime() < l) { >>>> synchronized(this){}; >>>> latch++; >>>> } >>>> >>>> nanoTime() is for elapsed time and should be used here. >>>> >>>> Thanks >>>> Max >>>> >>> > > -- > - DML From weijun.wang at oracle.com Thu Jun 16 03:33:37 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 11:33:37 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <5761F777.5030506@oracle.com> References: <5761F777.5030506@oracle.com> Message-ID: <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> You used String.valueOf(provider.getVersionStr()) on lines 70 and 861. Why not just provider.getVersionStr()? For parseVersionStr(), where is the spec for "java.specification.version"? Can we just use regex /(^\d+(\.\d+)?)/ to match the substring and turn it into a double? --Max > On Jun 16, 2016, at 8:48 AM, Valerie Peng wrote: > > > Any one has cycles to review this? Although the number of updated files are not trivial, but the key changes are in only 2 files, i.e. > src/java.base/share/classes/java/security/Provider.java and src/java.base/share/classes/java/security/AuthProvider.java. > > The rest of files are all very trivial, just changing the double version number to string. > Instead of hardcoded values, I make most of them refer to the new PROVIDER_VER field of the sun.security.util.SecurityConstants class, so the providers would be automatically updated and use the "java.specification.version" system property value as its version string. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130181 > Webrev: http://cr.openjdk.java.net/~valeriep/8130181/webrev.00/ > > Valerie From weijun.wang at oracle.com Thu Jun 16 04:17:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 12:17:44 +0800 Subject: RFR 8027781: New jarsigner timestamp warning is grammatically incorrect Message-ID: <6BC42732-8964-4ECF-AED8-C41CFD5CBB8E@oracle.com> Hi Sean Please review a resource string change diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java @@ -255,7 +255,7 @@ {"no.timestamp.signing", "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, {"no.timestamp.verifying", - "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, + "This jar contains signatures that do not include a timestamp. Without a timestamp, users may not be able to validate this jar after any of the signer certificates expires (as early as %1$tY-%1$tm-%1$td)."}, {"Unknown.password.type.", "Unknown password type: "}, {"Cannot.find.environment.variable.", "Cannot find environment variable: "}, I haven't used "one or more signatures" because many other jarsigner warnings use "This jar contains entries..." which do not have the words. About the expiration date, the warning is already showing the earliest one, so I added "as early as". Please note that when signing, the warning always shows the expiration date of the signer, even if there are other existing signatures without a timestamp. I assume this is a bug fix and no CCC is needed. Right? Thanks Max From weijun.wang at oracle.com Thu Jun 16 08:53:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 16:53:03 +0800 Subject: RFR 6968542: keytool -importcert cannot deal with duplicate certs Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/6968542/webrev.01/ Thanks Max From xuelei.fan at oracle.com Thu Jun 16 09:17:12 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 16 Jun 2016 17:17:12 +0800 Subject: RFR 6968542: keytool -importcert cannot deal with duplicate certs In-Reply-To: References: Message-ID: <1b66d666-ac46-1f23-8cc9-5577d2a23c1c@oracle.com> Maybe better to throw an exception so that the caller know that the reply is not valid. Tolerate problems may become a problem in the future. If you want to tolerate the duplicate cert in the chain, please add a comment about the use of hash set. The purpose of the use of hash set is not instinctive to the code reader. Xuelei On 6/16/2016 4:53 PM, Wang Weijun wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/6968542/webrev.01/ > > Thanks > Max > From weijun.wang at oracle.com Thu Jun 16 13:47:15 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 21:47:15 +0800 Subject: RFR 6968542: keytool -importcert cannot deal with duplicate certs In-Reply-To: <1b66d666-ac46-1f23-8cc9-5577d2a23c1c@oracle.com> References: <1b66d666-ac46-1f23-8cc9-5577d2a23c1c@oracle.com> Message-ID: <96F75005-7196-4477-849E-ABCBE28429D3@oracle.com> > On Jun 16, 2016, at 5:17 PM, Xuelei Fan wrote: > > Maybe better to throw an exception so that the caller know that the > reply is not valid. Tolerate problems may become a problem in the future. In this case, I only remove duplicated certs. Nothing else is tolerated. > > If you want to tolerate the duplicate cert in the chain, please add a > comment about the use of hash set. The purpose of the use of hash set > is not instinctive to the code reader. Sure. So does this mean you've approved my code changes? Thanks Max > > Xuelei > > On 6/16/2016 4:53 PM, Wang Weijun wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/6968542/webrev.01/ >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Jun 16 13:54:51 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 16 Jun 2016 21:54:51 +0800 Subject: Is there a test provider that does not allow private key export? Message-ID: <186C3E96-E51F-4C81-ACC8-0EC4369BD1D6@oracle.com> Hi Guys I am working on a keytool -providername bug [1] and would like to write a test with a provider that does not allow a private key to be exported (therefore not usable by Signature in another provider). Do we already have one inside jdk/test? Or is it possible to configure the SunPKCS11-NSS provider to do so? Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8143991 From Xuelei.Fan at Oracle.Com Thu Jun 16 15:15:38 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 16 Jun 2016 23:15:38 +0800 Subject: RFR 6968542: keytool -importcert cannot deal with duplicate certs In-Reply-To: <96F75005-7196-4477-849E-ABCBE28429D3@oracle.com> References: <1b66d666-ac46-1f23-8cc9-5577d2a23c1c@oracle.com> <96F75005-7196-4477-849E-ABCBE28429D3@oracle.com> Message-ID: <041DB3D7-AA3F-435A-A234-D963D2BE8C32@Oracle.Com> > On Jun 16, 2016, at 9:47 PM, Wang Weijun wrote: > > >> On Jun 16, 2016, at 5:17 PM, Xuelei Fan wrote: >> >> Maybe better to throw an exception so that the caller know that the >> reply is not valid. Tolerate problems may become a problem in the future. > > In this case, I only remove duplicated certs. Nothing else is tolerated. > >> >> If you want to tolerate the duplicate cert in the chain, please add a >> comment about the use of hash set. The purpose of the use of hash set >> is not instinctive to the code reader. > > Sure. > > So does this mean you've approved my code changes? > yes Xuelei > Thanks > Max > >> >> Xuelei >> >>> On 6/16/2016 4:53 PM, Wang Weijun wrote: >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/6968542/webrev.01/ >>> >>> Thanks >>> Max > From sean.mullan at oracle.com Thu Jun 16 19:50:04 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 16 Jun 2016 15:50:04 -0400 Subject: RFR 8027781: New jarsigner timestamp warning is grammatically incorrect In-Reply-To: <6BC42732-8964-4ECF-AED8-C41CFD5CBB8E@oracle.com> References: <6BC42732-8964-4ECF-AED8-C41CFD5CBB8E@oracle.com> Message-ID: <576302EC.3020109@oracle.com> On 06/16/2016 12:17 AM, Wang Weijun wrote: > Hi Sean > > Please review a resource string change > > diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java > @@ -255,7 +255,7 @@ > {"no.timestamp.signing", > "No -tsa or -tsacert is provided and this jar is not timestamped. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, > {"no.timestamp.verifying", > - "This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (%1$tY-%1$tm-%1$td)."}, > + "This jar contains signatures that do not include a timestamp. Without a timestamp, users may not be able to validate this jar after any of the signer certificates expires (as early as %1$tY-%1$tm-%1$td)."}, > {"Unknown.password.type.", "Unknown password type: "}, > {"Cannot.find.environment.variable.", > "Cannot find environment variable: "}, > > I haven't used "one or more signatures" because many other jarsigner warnings use "This jar contains entries..." which do not have the words. > > About the expiration date, the warning is already showing the earliest one, so I added "as early as". > > Please note that when signing, the warning always shows the expiration date of the signer, even if there are other existing signatures without a timestamp. Looks good, one nit on the wording: "... after any of the signer certificates expires ..." s/expires/expire/ > > I assume this is a bug fix and no CCC is needed. Right? Right. --Sean From xuelei.fan at oracle.com Fri Jun 17 00:28:44 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 Jun 2016 08:28:44 +0800 Subject: Is there a test provider that does not allow private key export? In-Reply-To: <186C3E96-E51F-4C81-ACC8-0EC4369BD1D6@oracle.com> References: <186C3E96-E51F-4C81-ACC8-0EC4369BD1D6@oracle.com> Message-ID: <3890e451-b86d-e39a-a118-cdfeef3ebf92@oracle.com> Maybe, you can have a look at: test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java Xuelei On 6/16/2016 9:54 PM, Wang Weijun wrote: > Hi Guys > > I am working on a keytool -providername bug [1] and would like to write a test with a provider that does not allow a private key to be exported (therefore not usable by Signature in another provider). Do we already have one inside jdk/test? Or is it possible to configure the SunPKCS11-NSS provider to do so? > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8143991 > From weijun.wang at oracle.com Fri Jun 17 02:00:42 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 10:00:42 +0800 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> Message-ID: <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> Ping again. > On Jun 7, 2016, at 11:52 AM, Wang Weijun wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ > > For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. > > I added a label noreg-cleanup, or maybe noreg-hard is better? > > Thanks > Max > From weijun.wang at oracle.com Fri Jun 17 02:00:55 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 10:00:55 +0800 Subject: RFR 8156471: test/sun/security/krb5/auto/TestHosts should not be modified in-place In-Reply-To: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> References: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> Message-ID: <32DFDBCB-315A-4989-B096-8E1CEC4552F7@oracle.com> Ping again. > On Jun 6, 2016, at 6:34 PM, Wang Weijun wrote: > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8156471/webrev.00/ > > Mark, I noticed a strange "irlga09" host name at the end of TestHosts [1]. Is it happened to be one of your test machines and you've added it with this test? I can remove it in this fix. > > Thanks > Max > > [1] http://cr.openjdk.java.net/~msheppar/8134577/webrev.10/test/sun/security/krb5/auto/TestHosts.html From xuelei.fan at oracle.com Fri Jun 17 02:28:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 Jun 2016 10:28:40 +0800 Subject: RFR 8156471: test/sun/security/krb5/auto/TestHosts should not be modified in-place In-Reply-To: <32DFDBCB-315A-4989-B096-8E1CEC4552F7@oracle.com> References: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> <32DFDBCB-315A-4989-B096-8E1CEC4552F7@oracle.com> Message-ID: <631c5631-50de-01fd-1851-00fcff607ae4@oracle.com> Looks fine to me. Xuelei On 6/17/2016 10:00 AM, Wang Weijun wrote: > Ping again. > >> On Jun 6, 2016, at 6:34 PM, Wang Weijun wrote: >> >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8156471/webrev.00/ >> >> Mark, I noticed a strange "irlga09" host name at the end of TestHosts [1]. Is it happened to be one of your test machines and you've added it with this test? I can remove it in this fix. >> >> Thanks >> Max >> >> [1] http://cr.openjdk.java.net/~msheppar/8134577/webrev.10/test/sun/security/krb5/auto/TestHosts.html > From xuelei.fan at oracle.com Fri Jun 17 02:31:49 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 17 Jun 2016 10:31:49 +0800 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> Message-ID: What did you mean "can a long field be a safe volatile?" Xuelei On 6/17/2016 10:00 AM, Wang Weijun wrote: > Ping again. > >> On Jun 7, 2016, at 11:52 AM, Wang Weijun wrote: >> >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ >> >> For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. >> >> I added a label noreg-cleanup, or maybe noreg-hard is better? >> >> Thanks >> Max >> > From weijun.wang at oracle.com Fri Jun 17 02:50:24 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 10:50:24 +0800 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> Message-ID: <03BC63B3-7102-4A48-B74E-82ADDDE65484@oracle.com> > On Jun 17, 2016, at 10:31 AM, Xuelei Fan wrote: > > What did you mean "can a long field be a safe volatile?" A long value cannot be updated atomically, and I am afraid that another thread might only see half bits updated and the other half not. --Max > > Xuelei > > On 6/17/2016 10:00 AM, Wang Weijun wrote: >> Ping again. >> >>> On Jun 7, 2016, at 11:52 AM, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ >>> >>> For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. >>> >>> I added a label noreg-cleanup, or maybe noreg-hard is better? >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Fri Jun 17 04:11:24 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 12:11:24 +0800 Subject: Is there a test provider that does not allow private key export? In-Reply-To: <3890e451-b86d-e39a-a118-cdfeef3ebf92@oracle.com> References: <186C3E96-E51F-4C81-ACC8-0EC4369BD1D6@oracle.com> <3890e451-b86d-e39a-a118-cdfeef3ebf92@oracle.com> Message-ID: <73A8F636-7566-4BB3-A155-C4D05C0C9270@oracle.com> Great, this is what I want. Thanks. > On Jun 17, 2016, at 8:28 AM, Xuelei Fan wrote: > > Maybe, you can have a look at: > test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java > > Xuelei > > On 6/16/2016 9:54 PM, Wang Weijun wrote: >> Hi Guys >> >> I am working on a keytool -providername bug [1] and would like to write a test with a provider that does not allow a private key to be exported (therefore not usable by Signature in another provider). Do we already have one inside jdk/test? Or is it possible to configure the SunPKCS11-NSS provider to do so? >> >> Thanks >> Max >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8143991 >> > From mark.sheppard at oracle.com Fri Jun 17 09:21:49 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 17 Jun 2016 10:21:49 +0100 Subject: RFR 8156471: test/sun/security/krb5/auto/TestHosts should not be modified in-place In-Reply-To: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> References: <6FC04A57-B479-4DFC-AB48-661BD7575232@oracle.com> Message-ID: Hi Max, yes that entry is an error .... an empty TestHosts should have been pushed the idea is that each test will setup its mappings, with the first addition truncating the TestHosts file, thus creating and empty file. regards Mark On 06/06/2016 11:34, Wang Weijun wrote: > Please review the change at > > http://cr.openjdk.java.net/~weijun/8156471/webrev.00/ > > Mark, I noticed a strange "irlga09" host name at the end of TestHosts [1]. Is it happened to be one of your test machines and you've added it with this test? I can remove it in this fix. > > Thanks > Max > > [1] http://cr.openjdk.java.net/~msheppar/8134577/webrev.10/test/sun/security/krb5/auto/TestHosts.html From weijun.wang at oracle.com Fri Jun 17 10:57:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 18:57:52 +0800 Subject: RFR 8158633: BASE64 encoded cert not correctly parsed Message-ID: Please review the fix at http://cr.openjdk.java.net/~weijun/8158633/webrev.00/ *Jon*: If I write this line inside a .java test: @test @run main/othervm -Dfile.encoding=UTF-16 PemEncoding this error occurs: STDERR: ??Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:59) I guess this mean jtreg does not like the system property set? Thanks Max From sean.mullan at oracle.com Fri Jun 17 11:14:58 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Jun 2016 07:14:58 -0400 Subject: RFR 8158633: BASE64 encoded cert not correctly parsed In-Reply-To: References: Message-ID: <5763DBB2.7080007@oracle.com> Looks fine to me, but can you add a comment to the bug report explaining what the issue was? Thanks, Sean On 06/17/2016 06:57 AM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8158633/webrev.00/ > > *Jon*: If I write this line inside a .java test: > > @test > @run main/othervm -Dfile.encoding=UTF-16 PemEncoding > > this error occurs: > > STDERR: > ??Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at com.sun.javatest.regtest.agent.MainWrapper.main(MainWrapper.java:59) > > I guess this mean jtreg does not like the system property set? > > Thanks > Max > From sean.mullan at oracle.com Fri Jun 17 11:45:35 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Jun 2016 07:45:35 -0400 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: <03BC63B3-7102-4A48-B74E-82ADDDE65484@oracle.com> References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> <03BC63B3-7102-4A48-B74E-82ADDDE65484@oracle.com> Message-ID: <5763E2DF.3060109@oracle.com> On 06/16/2016 10:50 PM, Wang Weijun wrote: > >> On Jun 17, 2016, at 10:31 AM, Xuelei Fan wrote: >> >> What did you mean "can a long field be a safe volatile?" > > A long value cannot be updated atomically, and I am afraid that another thread might only see half bits updated and the other half not. Have you considered using java.util.concurrent.atomic.AtomicLong? --Sean > > --Max > >> >> Xuelei >> >> On 6/17/2016 10:00 AM, Wang Weijun wrote: >>> Ping again. >>> >>>> On Jun 7, 2016, at 11:52 AM, Wang Weijun wrote: >>>> >>>> Hi All >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8158589/webrev.00/ >>>> >>>> For the reseedCounter case, the default reseedInterval is Integer.MAX_VALUE and there is no integer bigger than it, therefore a new check reseedCounter < 0 is added. I had thought about making it long but can a long field be a safe volatile? I am not sure. >>>> >>>> I added a label noreg-cleanup, or maybe noreg-hard is better? >>>> >>>> Thanks >>>> Max >>>> >>> >> > From weijun.wang at oracle.com Fri Jun 17 12:40:12 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 20:40:12 +0800 Subject: RFR 8159805: sun/security/tools/jarsigner/warnings/NoTimestampTest.java fails after JDK-8027781 Message-ID: <1BD10F65-4850-449D-88D3-9EA5A601376A@oracle.com> I forgot to update the test as well. Please review this patch: diff --git a/test/sun/security/tools/jarsigner/warnings/Test.java b/test/sun/security/tools/jarsigner/warnings/Test.java --- a/test/sun/security/tools/jarsigner/warnings/Test.java +++ b/test/sun/security/tools/jarsigner/warnings/Test.java @@ -121,10 +121,10 @@ + "(%1$tY-%1$tm-%1$td)."; static final String NO_TIMESTAMP_VERIFYING_WARN_TEMPLATE - = "This jar contains signatures that does not include a timestamp. " + = "This jar contains signatures that do not include a timestamp. " + "Without a timestamp, users may not be able to validate this jar " - + "after the signer certificate's expiration date " - + "(%1$tY-%1$tm-%1$td)."; + + "after any of the signer certificates expire " + + "(as early as %1$tY-%1$tm-%1$td)."; static final String NOT_YET_VALID_CERT_SIGNING_WARNING = "The signer certificate is not yet valid."; Thanks Max From weijun.wang at oracle.com Fri Jun 17 12:51:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 20:51:03 +0800 Subject: RFR 8158589: Possible integer overflow issues for DRBG In-Reply-To: <5763E2DF.3060109@oracle.com> References: <963892C7-73FE-48C7-86E7-2A0074487E5D@oracle.com> <6EE99D63-F3EC-468F-BE53-073B097A3E8B@oracle.com> <03BC63B3-7102-4A48-B74E-82ADDDE65484@oracle.com> <5763E2DF.3060109@oracle.com> Message-ID: > On Jun 17, 2016, at 7:45 PM, Sean Mullan wrote: > > On 06/16/2016 10:50 PM, Wang Weijun wrote: >> >>> On Jun 17, 2016, at 10:31 AM, Xuelei Fan wrote: >>> >>> What did you mean "can a long field be a safe volatile?" >> >> A long value cannot be updated atomically, and I am afraid that another thread might only see half bits updated and the other half not. > > Have you considered using java.util.concurrent.atomic.AtomicLong? I don't think it's worth using an AtomicLong. Wherever reseedCounter is accessed, it is already inside a synchronized block. The only reason I choose a volatile integer is that I can use it with the double checked locking technique. --Max > > --Sean From vincent.x.ryan at oracle.com Fri Jun 17 12:52:32 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 17 Jun 2016 13:52:32 +0100 Subject: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true Message-ID: Three Identity-related classes were deprecated in JDK 1.2. Please review the patch below that marks them as candidates for removal in a future JDK release. See http://openjdk.java.net/jeps/277 for details of the enhanced deprecation annotation. Thanks. diff --git a/src/java.base/share/classes/java/security/Identity.java b/src/java.base/share/classes/java/security/Identity.java --- a/src/java.base/share/classes/java/security/Identity.java +++ b/src/java.base/share/classes/java/security/Identity.java @@ -55,8 +55,9 @@ * replaced by {@code java.security.KeyStore}, the * {@code java.security.cert} package, and * {@code java.security.Principal}. + * This class is subject to removal in a future version of Java SE. */ - at Deprecated + at Deprecated(since="1.2", forRemoval=true) public abstract class Identity implements Principal, Serializable { /** use serialVersionUID from JDK 1.1.x for interoperability */ diff --git a/src/java.base/share/classes/java/security/IdentityScope.java b/src/java.base/share/classes/java/security/IdentityScope.java --- a/src/java.base/share/classes/java/security/IdentityScope.java +++ b/src/java.base/share/classes/java/security/IdentityScope.java @@ -60,8 +60,12 @@ * replaced by {@code java.security.KeyStore}, the * {@code java.security.cert} package, and * {@code java.security.Principal}. + * This class is subject to removal in a future version of Java SE. + * + * Note that the security property {@code policy.ignoreIdentityScope} + * is only applicable to these APIs and is also a candidate for removal. */ - at Deprecated + at Deprecated(since="1.2", forRemoval=true) public abstract class IdentityScope extends Identity { diff --git a/src/java.base/share/classes/java/security/Signer.java b/src/java.base/share/classes/java/security/Signer.java --- a/src/java.base/share/classes/java/security/Signer.java +++ b/src/java.base/share/classes/java/security/Signer.java @@ -43,8 +43,9 @@ * replaced by {@code java.security.KeyStore}, the * {@code java.security.cert} package, and * {@code java.security.Principal}. + * This class is subject to removal in a future version of Java SE. */ - at Deprecated + at Deprecated(since="1.2", forRemoval=true) public abstract class Signer extends Identity { private static final long serialVersionUID = -1763464102261361480L; -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jun 17 13:00:13 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Jun 2016 09:00:13 -0400 Subject: RFR 8159805: sun/security/tools/jarsigner/warnings/NoTimestampTest.java fails after JDK-8027781 In-Reply-To: <1BD10F65-4850-449D-88D3-9EA5A601376A@oracle.com> References: <1BD10F65-4850-449D-88D3-9EA5A601376A@oracle.com> Message-ID: <5763F45D.9010404@oracle.com> Looks fine. --Sean On 06/17/2016 08:40 AM, Wang Weijun wrote: > I forgot to update the test as well. Please review this patch: > > diff --git a/test/sun/security/tools/jarsigner/warnings/Test.java b/test/sun/security/tools/jarsigner/warnings/Test.java > --- a/test/sun/security/tools/jarsigner/warnings/Test.java > +++ b/test/sun/security/tools/jarsigner/warnings/Test.java > @@ -121,10 +121,10 @@ > + "(%1$tY-%1$tm-%1$td)."; > > static final String NO_TIMESTAMP_VERIFYING_WARN_TEMPLATE > - = "This jar contains signatures that does not include a timestamp. " > + = "This jar contains signatures that do not include a timestamp. " > + "Without a timestamp, users may not be able to validate this jar " > - + "after the signer certificate's expiration date " > - + "(%1$tY-%1$tm-%1$td)."; > + + "after any of the signer certificates expire " > + + "(as early as %1$tY-%1$tm-%1$td)."; > > static final String NOT_YET_VALID_CERT_SIGNING_WARNING > = "The signer certificate is not yet valid."; > > Thanks > Max > From sean.mullan at oracle.com Fri Jun 17 13:10:55 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Jun 2016 09:10:55 -0400 Subject: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true In-Reply-To: References: Message-ID: <5763F6DF.6050805@oracle.com> Looks fine to me. --Sean On 06/17/2016 08:52 AM, Vincent Ryan wrote: > Three Identity-related classes were deprecated in JDK 1.2. > Please review the patch below that marks them as candidates for removal > in a future JDK release. > > See http://openjdk.java.net/jeps/277 for details of the enhanced > deprecation annotation. > > Thanks. > > > diff --git a/src/java.base/share/classes/java/security/Identity.java > b/src/java.base/share/classes/java/security/Identity.java > --- a/src/java.base/share/classes/java/security/Identity.java > +++ b/src/java.base/share/classes/java/security/Identity.java > @@ -55,8 +55,9 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract class Identity implements Principal, Serializable { > > /** use serialVersionUID from JDK 1.1.x for interoperability */ > > > diff --git > a/src/java.base/share/classes/java/security/IdentityScope.java > b/src/java.base/share/classes/java/security/IdentityScope.java > --- a/src/java.base/share/classes/java/security/IdentityScope.java > +++ b/src/java.base/share/classes/java/security/IdentityScope.java > @@ -60,8 +60,12 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > + * > + * Note that the security property {@code policy.ignoreIdentityScope} > + * is only applicable to these APIs and is also a candidate for removal. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract > class IdentityScope extends Identity { > > > diff --git a/src/java.base/share/classes/java/security/Signer.java > b/src/java.base/share/classes/java/security/Signer.java > --- a/src/java.base/share/classes/java/security/Signer.java > +++ b/src/java.base/share/classes/java/security/Signer.java > @@ -43,8 +43,9 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract class Signer extends Identity { > > private static final long serialVersionUID = -1763464102261361480L; > From ecki at zusammenkunft.net Fri Jun 17 17:54:09 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Fri, 17 Jun 2016 19:54:09 +0200 Subject: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true In-Reply-To: <5763F6DF.6050805@oracle.com> References: <5763F6DF.6050805@oracle.com> Message-ID: Hello, While you are at that code, can the JavaDoc @code classnames be changed into @link as well? (Not sure if it works for packages). Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Sean Mullan To: Vincent Ryan , OpenJDK Sent: Fr., 17 Juni 2016 16:41 Subject: Re: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true Looks fine to me. --Sean On 06/17/2016 08:52 AM, Vincent Ryan wrote: > Three Identity-related classes were deprecated in JDK 1.2. > Please review the patch below that marks them as candidates for removal > in a future JDK release. > > See http://openjdk.java.net/jeps/277 for details of the enhanced > deprecation annotation. > > Thanks. > > > diff --git a/src/java.base/share/classes/java/security/Identity.java > b/src/java.base/share/classes/java/security/Identity.java > --- a/src/java.base/share/classes/java/security/Identity.java > +++ b/src/java.base/share/classes/java/security/Identity.java > @@ -55,8 +55,9 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract class Identity implements Principal, Serializable { > > /** use serialVersionUID from JDK 1.1.x for interoperability */ > > > diff --git > a/src/java.base/share/classes/java/security/IdentityScope.java > b/src/java.base/share/classes/java/security/IdentityScope.java > --- a/src/java.base/share/classes/java/security/IdentityScope.java > +++ b/src/java.base/share/classes/java/security/IdentityScope.java > @@ -60,8 +60,12 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > + * > + * Note that the security property {@code policy.ignoreIdentityScope} > + * is only applicable to these APIs and is also a candidate for removal. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract > class IdentityScope extends Identity { > > > diff --git a/src/java.base/share/classes/java/security/Signer.java > b/src/java.base/share/classes/java/security/Signer.java > --- a/src/java.base/share/classes/java/security/Signer.java > +++ b/src/java.base/share/classes/java/security/Signer.java > @@ -43,8 +43,9 @@ > * replaced by {@code java.security.KeyStore}, the > * {@code java.security.cert} package, and > * {@code java.security.Principal}. > + * This class is subject to removal in a future version of Java SE. > */ > - at Deprecated > + at Deprecated(since="1.2", forRemoval=true) > public abstract class Signer extends Identity { > > private static final long serialVersionUID = -1763464102261361480L; > From vincent.x.ryan at oracle.com Fri Jun 17 18:02:37 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 17 Jun 2016 19:02:37 +0100 Subject: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true In-Reply-To: References: <5763F6DF.6050805@oracle.com> Message-ID: Sure. (It works for packages too.) > On 17 Jun 2016, at 18:54, ecki at zusammenkunft.net wrote: > > Hello, > > While you are at that code, can the JavaDoc @code classnames be changed into @link as well? (Not sure if it works for packages). > > Gruss > Bernd > > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: Sean Mullan > To: Vincent Ryan , OpenJDK > Sent: Fr., 17 Juni 2016 16:41 > Subject: Re: RFR 8157730: Mark deprecated java.security.{Identity, IdentityScope, Signer} APIs with forRemoval=true > > Looks fine to me. > > --Sean > > On 06/17/2016 08:52 AM, Vincent Ryan wrote: >> Three Identity-related classes were deprecated in JDK 1.2. >> Please review the patch below that marks them as candidates for removal >> in a future JDK release. >> >> See http://openjdk.java.net/jeps/277 for details of the enhanced >> deprecation annotation. >> >> Thanks. >> >> >> diff --git a/src/java.base/share/classes/java/security/Identity.java >> b/src/java.base/share/classes/java/security/Identity.java >> --- a/src/java.base/share/classes/java/security/Identity.java >> +++ b/src/java.base/share/classes/java/security/Identity.java >> @@ -55,8 +55,9 @@ >> * replaced by {@code java.security.KeyStore}, the >> * {@code java.security.cert} package, and >> * {@code java.security.Principal}. >> + * This class is subject to removal in a future version of Java SE. >> */ >> - at Deprecated >> + at Deprecated(since="1.2", forRemoval=true) >> public abstract class Identity implements Principal, Serializable { >> >> /** use serialVersionUID from JDK 1.1.x for interoperability */ >> >> >> diff --git >> a/src/java.base/share/classes/java/security/IdentityScope.java >> b/src/java.base/share/classes/java/security/IdentityScope.java >> --- a/src/java.base/share/classes/java/security/IdentityScope.java >> +++ b/src/java.base/share/classes/java/security/IdentityScope.java >> @@ -60,8 +60,12 @@ >> * replaced by {@code java.security.KeyStore}, the >> * {@code java.security.cert} package, and >> * {@code java.security.Principal}. >> + * This class is subject to removal in a future version of Java SE. >> + * >> + * Note that the security property {@code policy.ignoreIdentityScope} >> + * is only applicable to these APIs and is also a candidate for removal. >> */ >> - at Deprecated >> + at Deprecated(since="1.2", forRemoval=true) >> public abstract >> class IdentityScope extends Identity { >> >> >> diff --git a/src/java.base/share/classes/java/security/Signer.java >> b/src/java.base/share/classes/java/security/Signer.java >> --- a/src/java.base/share/classes/java/security/Signer.java >> +++ b/src/java.base/share/classes/java/security/Signer.java >> @@ -43,8 +43,9 @@ >> * replaced by {@code java.security.KeyStore}, the >> * {@code java.security.cert} package, and >> * {@code java.security.Principal}. >> + * This class is subject to removal in a future version of Java SE. >> */ >> - at Deprecated >> + at Deprecated(since="1.2", forRemoval=true) >> public abstract class Signer extends Identity { >> >> private static final long serialVersionUID = -1763464102261361480L; >> From artem.smotrakov at oracle.com Fri Jun 17 23:21:39 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 17 Jun 2016 16:21:39 -0700 Subject: [9] RFR: 8159501: ShortRSAKey512.java intermittently times out Message-ID: <57648603.3060007@oracle.com> Hello, Please review the patch below for javax/net/ssl/TLSv12/ShortRSAKey512.java test. The test has been seen to fail intermittently with a time out. I was not able to reproduce this failure. The test fails with "Client died ..." message which occurs in case of exception on client side. But no exception is printed, so it is not clear why it fails. The test runs a client in a separate thread, and save an exception on client side if it occurs. Then, it waits for server to finish before print an exception on client side. The server waits for a client connection forever. As a result, the test fails by timeout, and no exception is printed to output. The patch updates the test with the following: - print out exceptions when they occur, and enabled SSL/TLS debug output, so that we'll have more info if it fails next time - start new threads as daemons, so that it doesn't need to wait for test timeout is reached - use try-with-resources - removed unnecessary "throw" and "try-catch" blocks Webrev: http://cr.openjdk.java.net/~asmotrak/8159501/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8159501 Artem From xuelei.fan at oracle.com Sat Jun 18 01:53:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 18 Jun 2016 09:53:23 +0800 Subject: [9] RFR: 8159501: ShortRSAKey512.java intermittently times out In-Reply-To: <57648603.3060007@oracle.com> References: <57648603.3060007@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/18/2016 7:21 AM, Artem Smotrakov wrote: > Hello, > > Please review the patch below for > javax/net/ssl/TLSv12/ShortRSAKey512.java test. > > The test has been seen to fail intermittently with a time out. I was not > able to reproduce this failure. The test fails with "Client died ..." > message which occurs in case of exception on client side. But no > exception is printed, so it is not clear why it fails. > > The test runs a client in a separate thread, and save an exception on > client side if it occurs. Then, it waits for server to finish before > print an exception on client side. The server waits for a client > connection forever. As a result, the test fails by timeout, and no > exception is printed to output. > > The patch updates the test with the following: > - print out exceptions when they occur, and enabled SSL/TLS debug > output, so that we'll have more info if it fails next time > - start new threads as daemons, so that it doesn't need to wait for test > timeout is reached > - use try-with-resources > - removed unnecessary "throw" and "try-catch" blocks > > Webrev: http://cr.openjdk.java.net/~asmotrak/8159501/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8159501 > > Artem From felix.yang at oracle.com Mon Jun 20 05:52:20 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 20 Jun 2016 13:52:20 +0800 Subject: RFR 8157530/9, Remove intermittent key from javax/net/ssl/DTLS/WeakCipherSuite.java Message-ID: javax/net/ssl/DTLS/WeakCipherSuite.java failed intermittently with (JDK-8129389 ). It had been resolved and no new failure was observed in pass round of same binaries runs. It looks necessary to remove @key intermittent from the test. bug: https://bugs.openjdk.java.net/browse/JDK-8157530 Patch: diff -r 7ff61c55b5c6 test/javax/net/ssl/DTLS/WeakCipherSuite.java --- a/test/javax/net/ssl/DTLS/WeakCipherSuite.java Sat Jun 18 16:50:19 2016 -0700 +++ b/test/javax/net/ssl/DTLS/WeakCipherSuite.java Sun Jun 19 22:39:34 2016 -0700 @@ -27,7 +27,6 @@ /* * @test * @bug 8043758 - * @key intermittent * @summary Datagram Transport Layer Security (DTLS) * @modules java.base/sun.security.util * @build DTLSOverDatagram Thanks, Felix -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jun 20 08:56:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Jun 2016 16:56:15 +0800 Subject: RFR 8157530/9, Remove intermittent key from javax/net/ssl/DTLS/WeakCipherSuite.java In-Reply-To: References: Message-ID: <55e3a609-9ec3-3257-8900-82a0ef3fa129@oracle.com> Looks fine to me. Thanks, Xuelei On 6/20/2016 1:52 PM, Felix Yang wrote: > javax/net/ssl/DTLS/WeakCipherSuite.java failed intermittently with > (JDK-8129389 ). It had > been resolved and no new failure was observed in pass round of same > binaries runs. > > It looks necessary to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157530 > > Patch: > > diff -r 7ff61c55b5c6 test/javax/net/ssl/DTLS/WeakCipherSuite.java > --- a/test/javax/net/ssl/DTLS/WeakCipherSuite.java Sat Jun 18 > 16:50:19 2016 -0700 > +++ b/test/javax/net/ssl/DTLS/WeakCipherSuite.java Sun Jun 19 > 22:39:34 2016 -0700 > @@ -27,7 +27,6 @@ > /* > * @test > * @bug 8043758 > - * @key intermittent > * @summary Datagram Transport Layer Security (DTLS) > * @modules java.base/sun.security.util > * @build DTLSOverDatagram > > Thanks, > > Felix > From artem.smotrakov at oracle.com Mon Jun 20 18:12:04 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 20 Jun 2016 11:12:04 -0700 Subject: [9] RFR: 8074580: sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11Exception: CKR_FUNCTION_FAILED Message-ID: <576831F4.90102@oracle.com> Hello, Please review the following patch below for 9. TestKeyPairGenerator.java test intermittently fails with CKR_FUNCTION_FAILED error when NSS crypto libs is used via SunPKCS11 provider. Looks like the root cause is a bug 1012786 in NSS https://bugzilla.mozilla.org/show_bug.cgi?id=1012786 RSA_NewKey() fun?tion may fail with SEC_ERROR_NEED_RANDOM in case of lack of entropy which results to CKR_FUNCTION_FAILED. PKCS11 spec says the following about CKR_FUNCTION_FAILED error: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf ... CKR_FUNCTION_FAILED: ... In any event, although the function call failed, the situation is not necessarily totally hopeless, as it is likely to be when CKR_GENERAL_ERROR is returned. Depending on what the root cause of the error actually was, it is possible that an attempt to make the exact same function call again would succeed. ... In this particular case, CKR_FUNCTION_FAILED error doesn't seem to be hopeless, and next call may succeed. The patch below tries to workaround this problem by calling C_GenerateKeyPair() function again in case of CKR_GENERAL_ERROR. I was not able to reproduce this failure manually on several machines, so unfortunately I am not completely sure it solves the problem. I can back out the fix if we see those failures again. Webrev: http://cr.openjdk.java.net/~asmotrak/8074580/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8074580 Artem From artem.smotrakov at oracle.com Mon Jun 20 20:46:13 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 20 Jun 2016 13:46:13 -0700 Subject: [9] RFR: 8049314: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "Unexpected EOF" message Message-ID: <57685615.6020407@oracle.com> Hello, Please review this patch for SSLSocketSSLEngineTemplate.java test. The test fails intermittently with "Unexpected EOF" error. Please see Brad's comment which explains the issue https://bugs.openjdk.java.net/browse/JDK-8049314?focusedCommentId=13519136&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13519136 Calling compact() method before continuing (as Brad suggested) seems to solve the issue. The patch also updates the test to use a try-with-resource block while reading keystores. sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java test doesn't seems to be affected because it always calls compact() after flip(). Webrev: http://cr.openjdk.java.net/~asmotrak/8049314/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8049314 Artem From xuelei.fan at oracle.com Mon Jun 20 23:51:45 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 21 Jun 2016 07:51:45 +0800 Subject: [9] RFR: 8049314: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "Unexpected EOF" message In-Reply-To: <57685615.6020407@oracle.com> References: <57685615.6020407@oracle.com> Message-ID: <1a081e04-3cb8-95af-1f0a-556038f9f64a@oracle.com> Nice catch! Looks fine to me. Thanks, Xuelei On 6/21/2016 4:46 AM, Artem Smotrakov wrote: > Hello, > > Please review this patch for SSLSocketSSLEngineTemplate.java test. > > The test fails intermittently with "Unexpected EOF" error. Please see > Brad's comment which explains the issue > > https://bugs.openjdk.java.net/browse/JDK-8049314?focusedCommentId=13519136&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13519136 > > > Calling compact() method before continuing (as Brad suggested) seems to > solve the issue. The patch also updates the test to use a > try-with-resource block while reading keystores. > > sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java test > doesn't seems to be affected because it always calls compact() after > flip(). > > Webrev: http://cr.openjdk.java.net/~asmotrak/8049314/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8049314 > > Artem From weijun.wang at oracle.com Tue Jun 21 01:39:50 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Jun 2016 09:39:50 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: <42EDA943-0126-448B-AB61-4AADE285A651@oracle.com> References: <5761D8AE.8030003@redhat.com> <42EDA943-0126-448B-AB61-4AADE285A651@oracle.com> Message-ID: <81f0408a-8d7d-a8f7-53f6-3da98927bfd4@oracle.com> Ping again. On 6/16/2016 10:32, Wang Weijun wrote: > >> On Jun 16, 2016, at 6:37 AM, David M. Lloyd wrote: >> >> This will not work because System.nanoTime() can be negative and wrap around. You can't compare one nanoTime to another, only differences are useful. > > Yes, you are right. How about this then? > > diff --git a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > --- a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > +++ b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java > @@ -354,8 +354,8 @@ > // We wait 250milli quanta, so the minimum wait time > // cannot be under 250milli. > int latch = 0; > - long l = System.currentTimeMillis() + 250; > - while (System.currentTimeMillis() < l) { > + long l = System.nanoTime(); > + while (System.nanoTime() - l < 250000000) { > synchronized(this){}; > latch++; > } > > Thanks > Max > >> >> On 06/15/2016 05:30 PM, Bradford Wetmore wrote: >>> Looks good, Max, thanks for taking this over. >>> >>> Xuelei, it's a threaded accumulator, which feeds into the seed >>> generator. We wait a certain amount of time before generating the values. >>> >>> Brad >>> >>> >>> On 6/15/2016 5:07 AM, Xuelei Fan wrote: >>>> I'm not sure I understand the while loop. But this update looks fine to >>>> me as it does not change the logic of the code except to use elapsed >>>> time. >>>> >>>> Xuelei >>>> >>>> On 6/15/2016 11:12 AM, Wang Weijun wrote: >>>>> Please take a review on the patch >>>>> >>>>> diff --git >>>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>> >>>>> --- >>>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>> +++ >>>>> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>> @@ -354,8 +354,8 @@ >>>>> // We wait 250milli quanta, so the minimum >>>>> wait time >>>>> // cannot be under 250milli. >>>>> int latch = 0; >>>>> - long l = System.currentTimeMillis() + 250; >>>>> - while (System.currentTimeMillis() < l) { >>>>> + long l = System.nanoTime() + 250000000; >>>>> + while (System.nanoTime() < l) { >>>>> synchronized(this){}; >>>>> latch++; >>>>> } >>>>> >>>>> nanoTime() is for elapsed time and should be used here. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >> >> -- >> - DML > From xuelei.fan at oracle.com Tue Jun 21 02:30:59 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 21 Jun 2016 10:30:59 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: <81f0408a-8d7d-a8f7-53f6-3da98927bfd4@oracle.com> References: <5761D8AE.8030003@redhat.com> <42EDA943-0126-448B-AB61-4AADE285A651@oracle.com> <81f0408a-8d7d-a8f7-53f6-3da98927bfd4@oracle.com> Message-ID: <09475100-6236-3a7d-6c37-c1947789a5ff@oracle.com> Looks fine to me. long l = System.nanoTime(); 'l' is easy to be confused with '1'. May be nice to use a meaningful name, for example 'startTime'. Xuelei On 6/21/2016 9:39 AM, Weijun Wang wrote: > Ping again. > > On 6/16/2016 10:32, Wang Weijun wrote: >> >>> On Jun 16, 2016, at 6:37 AM, David M. Lloyd >>> wrote: >>> >>> This will not work because System.nanoTime() can be negative and wrap >>> around. You can't compare one nanoTime to another, only differences >>> are useful. >> >> Yes, you are right. How about this then? >> >> diff --git >> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> --- >> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> +++ >> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >> @@ -354,8 +354,8 @@ >> // We wait 250milli quanta, so the minimum >> wait time >> // cannot be under 250milli. >> int latch = 0; >> - long l = System.currentTimeMillis() + 250; >> - while (System.currentTimeMillis() < l) { >> + long l = System.nanoTime(); >> + while (System.nanoTime() - l < 250000000) { >> synchronized(this){}; >> latch++; >> } >> >> Thanks >> Max >> >>> >>> On 06/15/2016 05:30 PM, Bradford Wetmore wrote: >>>> Looks good, Max, thanks for taking this over. >>>> >>>> Xuelei, it's a threaded accumulator, which feeds into the seed >>>> generator. We wait a certain amount of time before generating the >>>> values. >>>> >>>> Brad >>>> >>>> >>>> On 6/15/2016 5:07 AM, Xuelei Fan wrote: >>>>> I'm not sure I understand the while loop. But this update looks >>>>> fine to >>>>> me as it does not change the logic of the code except to use elapsed >>>>> time. >>>>> >>>>> Xuelei >>>>> >>>>> On 6/15/2016 11:12 AM, Wang Weijun wrote: >>>>>> Please take a review on the patch >>>>>> >>>>>> diff --git >>>>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>>> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>>> >>>>>> >>>>>> --- >>>>>> a/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>>> >>>>>> +++ >>>>>> b/src/java.base/share/classes/sun/security/provider/SeedGenerator.java >>>>>> >>>>>> @@ -354,8 +354,8 @@ >>>>>> // We wait 250milli quanta, so the minimum >>>>>> wait time >>>>>> // cannot be under 250milli. >>>>>> int latch = 0; >>>>>> - long l = System.currentTimeMillis() + 250; >>>>>> - while (System.currentTimeMillis() < l) { >>>>>> + long l = System.nanoTime() + 250000000; >>>>>> + while (System.nanoTime() < l) { >>>>>> synchronized(this){}; >>>>>> latch++; >>>>>> } >>>>>> >>>>>> nanoTime() is for elapsed time and should be used here. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>> >>> >>> -- >>> - DML >> From weijun.wang at oracle.com Tue Jun 21 03:17:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 21 Jun 2016 11:17:48 +0800 Subject: RFR 8157318: ThreadedSeedGenerator uses System.currentTimeMillis and stops generating when time is set back In-Reply-To: <09475100-6236-3a7d-6c37-c1947789a5ff@oracle.com> References: <5761D8AE.8030003@redhat.com> <42EDA943-0126-448B-AB61-4AADE285A651@oracle.com> <81f0408a-8d7d-a8f7-53f6-3da98927bfd4@oracle.com> <09475100-6236-3a7d-6c37-c1947789a5ff@oracle.com> Message-ID: <8C5B020E-5B2D-4CAB-A278-D54EBDB8A9D4@oracle.com> > On Jun 21, 2016, at 10:30 AM, Xuelei Fan wrote: > > Looks fine to me. > > long l = System.nanoTime(); > 'l' is easy to be confused with '1'. May be nice to use a meaningful > name, for example 'startTime'. Thanks. Updated as you suggested and pushed. --Max > > Xuelei From artem.smotrakov at oracle.com Tue Jun 21 17:20:46 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Jun 2016 10:20:46 -0700 Subject: [9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message Message-ID: <5769776E.3090807@oracle.com> Hello, Please review the patch below for javax/net/ssl/TLS/TestJSSE.java test. The test has been observed to fail intermittently with "Unsupported or unrecognized SSL" error. But I couldn't reproduce it manually while running the test in a loop for a couple of days on Linux x64. For now it's not clear why it failed. The patch updates the test with the following: - enabled debug output, so that we can have more info if the test fails again - splitted the test to several files to avoid jtreg's "output overflow" - updated the test to close sockets - some refactoring to make the code/logs more readable (although I believe the test needs even more refactoring) Webrev: http://cr.openjdk.java.net/~asmotrak/8152745/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8152745 Artem From claes.redestad at oracle.com Tue Jun 21 19:32:17 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 21 Jun 2016 21:32:17 +0200 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl In-Reply-To: References: <571E53B5.3060409@oracle.com> <57348732.6020705@oracle.com> <5757240C.7080006@oracle.com> <4b2e273e-2e8d-a65a-d56c-f51a701d14f6@oracle.com> <575A0A48.8070903@oracle.com> <575AA5A5.3090500@oracle.com> Message-ID: <57699641.5030200@oracle.com> After some internal discussions: http://cr.openjdk.java.net/~redestad/8155039/webrev.03/ Drops the PropertiesWrapper and Properties-retrieving approach in favor of a getter to retrieve multiple properties into a Map. /Claes On 2016-06-10 20:13, Mandy Chung wrote: >> On Jun 10, 2016, at 4:33 AM, Sean Mullan wrote: >> >> On 06/09/2016 10:32 PM, Mandy Chung wrote: >>> Hi Claes, >>> >>> I don?t like the PropertiesWrapper idea. The caller should be >>> cautious in storing any sensitive information. For the system >>> properties, these callsites use it in the local scope that I don?t >>> see any reason and benefit to introduce a wrapper. I didn?t follow >>> this discussion closely and I may miss some reason ? >> The original code used multiple calls to System.getProperty wrapped in a doPrivileged. Claes' first iteration of the fix changed this to use a GetPropertyAction.privilegedGetProperties method that returned a Properties object. I expressed a concern that this was now exposing an object that, if accidentally leaked to untrusted code could cause much more damage than the original code (since the code would be able to set/get/remove *any* system property). Hence the current fix which uses a wrapper class which is not exported. > > I actually see the original code is clearer to the reader and involves one single doPrivileged. I would avoid introducing PropertiesWrapper which I don?t think it?s the right way to protect security information. Sean may suggest to revert to the original code which I won?t object. > > Mandy From artem.smotrakov at oracle.com Tue Jun 21 21:31:27 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Jun 2016 14:31:27 -0700 Subject: [9] RFR: 8074580: sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11Exception: CKR_FUNCTION_FAILED In-Reply-To: <576831F4.90102@oracle.com> References: <576831F4.90102@oracle.com> Message-ID: <5769B22F.8090203@oracle.com> I forgot to include PKCS11.java to webrev, here is an updated webrev http://cr.openjdk.java.net/~asmotrak/8074580/webrev.01/ Artem On 06/20/2016 11:12 AM, Artem Smotrakov wrote: > Hello, > > Please review the following patch below for 9. > > TestKeyPairGenerator.java test intermittently fails with > CKR_FUNCTION_FAILED error when NSS crypto libs is used via SunPKCS11 > provider. Looks like the root cause is a bug 1012786 in NSS > > https://bugzilla.mozilla.org/show_bug.cgi?id=1012786 > > RSA_NewKey() fun?tion may fail with SEC_ERROR_NEED_RANDOM in case of > lack of entropy which results to CKR_FUNCTION_FAILED. > > PKCS11 spec says the following about CKR_FUNCTION_FAILED error: > > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf > > ... > CKR_FUNCTION_FAILED: ... In any event, although the function call > failed, the situation is not necessarily totally hopeless, as it is > likely to be when > CKR_GENERAL_ERROR is returned. Depending on what the root cause of the > error actually was, it is possible that an attempt to make the exact > same function call > again would succeed. > ... > > In this particular case, CKR_FUNCTION_FAILED error doesn't seem to be > hopeless, and next call may succeed. The patch below tries to > workaround this problem by calling C_GenerateKeyPair() function again > in case of CKR_GENERAL_ERROR. > > I was not able to reproduce this failure manually on several machines, > so unfortunately I am not completely sure it solves the problem. I can > back out the fix if we see those failures again. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8074580/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8074580 > > Artem From xuelei.fan at oracle.com Wed Jun 22 00:57:48 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 22 Jun 2016 08:57:48 +0800 Subject: [9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message In-Reply-To: <5769776E.3090807@oracle.com> References: <5769776E.3090807@oracle.com> Message-ID: <19a09aaf-6439-3db7-a31b-b8f0114714cf@oracle.com> Looks more like a issue of "Unsupported or unrecognized SSL message". This issue might be impacted by other test cases that running in the same time that using free socket port. It's good to dump the SSL/TLS record for further evaluation. Minor comments: test/javax/net/ssl/TLS/TestJSSE.java 36 System.setProperty("javax.net.debug", "ssl"); What do you think if dump the TLS record, too? System.setProperty("javax.net.debug", "ssl,record"); test/javax/net/ssl/TLS/CipherTestUtils.java line 431-433: Looks like you missed the print the string array. line 379, 498, 509: may exceed 80 characters each line. Please also look at other updated that may exceed 80 characters each line. On 6/22/2016 1:20 AM, Artem Smotrakov wrote: > Hello, > > Please review the patch below for javax/net/ssl/TLS/TestJSSE.java test. > > The test has been observed to fail intermittently with "Unsupported or > unrecognized SSL" error. But I couldn't reproduce it manually while > running the test in a loop for a couple of days on Linux x64. For now > it's not clear why it failed. > > The patch updates the test with the following: > - enabled debug output, so that we can have more info if the test fails > again > - splitted the test to several files to avoid jtreg's "output overflow" Hm, a sort of hack code as these files are not actually 'java' code. But it should work, I think. Thanks, Xuelei > - updated the test to close sockets > - some refactoring to make the code/logs more readable (although I > believe the test needs even more refactoring) > > Webrev: http://cr.openjdk.java.net/~asmotrak/8152745/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8152745 > > Artem From artem.smotrakov at oracle.com Wed Jun 22 01:35:27 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Jun 2016 18:35:27 -0700 Subject: [9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message In-Reply-To: <19a09aaf-6439-3db7-a31b-b8f0114714cf@oracle.com> References: <5769776E.3090807@oracle.com> <19a09aaf-6439-3db7-a31b-b8f0114714cf@oracle.com> Message-ID: <5769EB5F.4060004@oracle.com> Hi Xuelei, Thank you for review. Please see inline. On 06/21/2016 05:57 PM, Xuelei Fan wrote: > Looks more like a issue of "Unsupported or unrecognized SSL message". > This issue might be impacted by other test cases that running in the > same time that using free socket port. It's good to dump the SSL/TLS > record for further evaluation. > > Minor comments: > > test/javax/net/ssl/TLS/TestJSSE.java > 36 System.setProperty("javax.net.debug", "ssl"); > What do you think if dump the TLS record, too? > System.setProperty("javax.net.debug", "ssl,record"); Sure, "ssl,record" is much better. I checked that it doesn't result to "overflow output". > > test/javax/net/ssl/TLS/CipherTestUtils.java > line 431-433: Looks like you missed the print the string array. Sure, thank you! > > line 379, 498, 509: may exceed 80 characters each line. Please also > look at other updated that may exceed 80 characters each line. Right, a couple of lines are about 81-85 characters. I am not a fan of long lines, but I think they may exceed 80 characters if it makes them more readable. I know that some people use vi, so in some environment they may have problems with lines more than 80 characters. If I recall correctly, there was a discussion about new Java coding guidelines, but I am not sure it has been done. I know about the following draft, but not sure if it is official http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html It has a recommendation about line lengths, but it allows lines more than 80 characters if it makes it more readable. Anyway, I avoided lines more than 80 characters (mostly I renamed variables). Please take a look at updated webrev: http://cr.openjdk.java.net/~asmotrak/8152745/webrev.01/ Artem > > On 6/22/2016 1:20 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review the patch below for javax/net/ssl/TLS/TestJSSE.java test. >> >> The test has been observed to fail intermittently with "Unsupported or >> unrecognized SSL" error. But I couldn't reproduce it manually while >> running the test in a loop for a couple of days on Linux x64. For now >> it's not clear why it failed. >> >> The patch updates the test with the following: >> - enabled debug output, so that we can have more info if the test fails >> again >> - splitted the test to several files to avoid jtreg's "output overflow" > Hm, a sort of hack code as these files are not actually 'java' code. > But it should work, I think. > > Thanks, > Xuelei > >> - updated the test to close sockets >> - some refactoring to make the code/logs more readable (although I >> believe the test needs even more refactoring) >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8152745/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152745 >> >> Artem From xuelei.fan at oracle.com Wed Jun 22 02:11:12 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 22 Jun 2016 10:11:12 +0800 Subject: [9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message In-Reply-To: <5769EB5F.4060004@oracle.com> References: <5769776E.3090807@oracle.com> <19a09aaf-6439-3db7-a31b-b8f0114714cf@oracle.com> <5769EB5F.4060004@oracle.com> Message-ID: <1ab773f5-44fd-d497-bbfa-d75b199047dd@oracle.com> looks fine to me. Thanks, Xuelei On 6/22/2016 9:35 AM, Artem Smotrakov wrote: > Hi Xuelei, > > Thank you for review. Please see inline. > > On 06/21/2016 05:57 PM, Xuelei Fan wrote: >> Looks more like a issue of "Unsupported or unrecognized SSL message". >> This issue might be impacted by other test cases that running in the >> same time that using free socket port. It's good to dump the SSL/TLS >> record for further evaluation. >> >> Minor comments: >> >> test/javax/net/ssl/TLS/TestJSSE.java >> 36 System.setProperty("javax.net.debug", "ssl"); >> What do you think if dump the TLS record, too? >> System.setProperty("javax.net.debug", "ssl,record"); > Sure, "ssl,record" is much better. I checked that it doesn't result to > "overflow output". >> >> test/javax/net/ssl/TLS/CipherTestUtils.java >> line 431-433: Looks like you missed the print the string array. > Sure, thank you! >> >> line 379, 498, 509: may exceed 80 characters each line. Please also >> look at other updated that may exceed 80 characters each line. > Right, a couple of lines are about 81-85 characters. I am not a fan of > long lines, but I think they may exceed 80 characters if it makes them > more readable. I know that some people use vi, so in some environment > they may have problems with lines more than 80 characters. > > If I recall correctly, there was a discussion about new Java coding > guidelines, but I am not sure it has been done. I know about the > following draft, but not sure if it is official > > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > > It has a recommendation about line lengths, but it allows lines more > than 80 characters if it makes it more readable. > > Anyway, I avoided lines more than 80 characters (mostly I renamed > variables). > > Please take a look at updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8152745/webrev.01/ > > Artem >> >> On 6/22/2016 1:20 AM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review the patch below for javax/net/ssl/TLS/TestJSSE.java test. >>> >>> The test has been observed to fail intermittently with "Unsupported or >>> unrecognized SSL" error. But I couldn't reproduce it manually while >>> running the test in a loop for a couple of days on Linux x64. For now >>> it's not clear why it failed. >>> >>> The patch updates the test with the following: >>> - enabled debug output, so that we can have more info if the test fails >>> again >>> - splitted the test to several files to avoid jtreg's "output overflow" >> Hm, a sort of hack code as these files are not actually 'java' code. >> But it should work, I think. >> >> Thanks, >> Xuelei >> >>> - updated the test to close sockets >>> - some refactoring to make the code/logs more readable (although I >>> believe the test needs even more refactoring) >>> >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8152745/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152745 >>> >>> Artem > From tiantian.du at oracle.com Wed Jun 22 06:50:52 2016 From: tiantian.du at oracle.com (Tim Du) Date: Wed, 22 Jun 2016 14:50:52 +0800 Subject: [9] RFR 8146393:sun/security/tools/jarsigner/ts.sh failed on OEL Linux 7 with ar_SA Locale Message-ID: <576A354C.1080008@oracle.com> Hi, Would you please review the path for following bug? bug: https://bugs.openjdk.java.net/browse/JDK-8146393 webrev: http://cr.openjdk.java.net/~tidu/8146393/webrev.00/ The test failed when using String.format() to format the server port on ar_SA Locale, Adding Locale.ROOT arguments to avoid the locale sensitive operations. It could pass on ar_SA locale platform after this code change.Thanks Regards Tim From weijun.wang at oracle.com Wed Jun 22 10:27:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 22 Jun 2016 18:27:46 +0800 Subject: [9] RFR 8146393:sun/security/tools/jarsigner/ts.sh failed on OEL Linux 7 with ar_SA Locale In-Reply-To: <576A354C.1080008@oracle.com> References: <576A354C.1080008@oracle.com> Message-ID: Change looks fine. BTW, have you run the test with that special locale on? Thanks Max > On Jun 22, 2016, at 2:50 PM, Tim Du wrote: > > Hi, > > Would you please review the path for following bug? > > bug: https://bugs.openjdk.java.net/browse/JDK-8146393 > webrev: http://cr.openjdk.java.net/~tidu/8146393/webrev.00/ > > The test failed when using String.format() to format the server port on ar_SA Locale, Adding Locale.ROOT arguments to avoid the locale sensitive operations. It could pass on ar_SA locale platform after this code change.Thanks > > Regards > Tim From valerie.peng at oracle.com Wed Jun 22 19:47:59 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 22 Jun 2016 12:47:59 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> Message-ID: <576AEB6F.8040406@oracle.com> Max, Thanks for the comments~ The String.valueOf() calls are for handling null values. The name and id fields are also of type String and they use the String.valueOf() calls when putting in the Provider.id attribute values, so I follow the same convention. I also updated the parseVersionStr(String) utility method to handle null or invalid version strings though, and assign 0d if parsing fails. According to the Verona JEP, "java.specification.version" should be $VNUM which is a non-empty sequence of non- negative integer numerals, without leading zeros, separated by period characters. I am not sure if we can assume the same format for supplied version string though. So, the current impl of parsing of version string can take the $VSTR (again in Verona JEP) which consists of $VUM optionally followed by pre-release and build info, i.e. $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)? Webrev updated: http://cr.openjdk.java.net/~valeriep/8130181/webrev.01 Valerie On 6/15/2016 8:33 PM, Wang Weijun wrote: > You used String.valueOf(provider.getVersionStr()) on lines 70 and 861. Why not just provider.getVersionStr()? > > For parseVersionStr(), where is the spec for "java.specification.version"? Can we just use regex /(^\d+(\.\d+)?)/ to match the substring and turn it into a double? > > --Max > >> On Jun 16, 2016, at 8:48 AM, Valerie Peng wrote: >> >> >> Any one has cycles to review this? Although the number of updated files are not trivial, but the key changes are in only 2 files, i.e. >> src/java.base/share/classes/java/security/Provider.java and src/java.base/share/classes/java/security/AuthProvider.java. >> >> The rest of files are all very trivial, just changing the double version number to string. >> Instead of hardcoded values, I make most of them refer to the new PROVIDER_VER field of the sun.security.util.SecurityConstants class, so the providers would be automatically updated and use the "java.specification.version" system property value as its version string. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130181 >> Webrev: http://cr.openjdk.java.net/~valeriep/8130181/webrev.00/ >> >> Valerie From valerie.peng at oracle.com Wed Jun 22 22:45:16 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 22 Jun 2016 15:45:16 -0700 Subject: [9] RFR: 8074580: sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11Exception: CKR_FUNCTION_FAILED In-Reply-To: <5769B22F.8090203@oracle.com> References: <576831F4.90102@oracle.com> <5769B22F.8090203@oracle.com> Message-ID: <576B14FC.7050204@oracle.com> The webrev looks fine. Thanks, Valerie On 6/21/2016 2:31 PM, Artem Smotrakov wrote: > I forgot to include PKCS11.java to webrev, here is an updated webrev > > http://cr.openjdk.java.net/~asmotrak/8074580/webrev.01/ > > Artem > > On 06/20/2016 11:12 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review the following patch below for 9. >> >> TestKeyPairGenerator.java test intermittently fails with >> CKR_FUNCTION_FAILED error when NSS crypto libs is used via SunPKCS11 >> provider. Looks like the root cause is a bug 1012786 in NSS >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1012786 >> >> RSA_NewKey() fun?tion may fail with SEC_ERROR_NEED_RANDOM in case of >> lack of entropy which results to CKR_FUNCTION_FAILED. >> >> PKCS11 spec says the following about CKR_FUNCTION_FAILED error: >> >> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf >> >> ... >> CKR_FUNCTION_FAILED: ... In any event, although the function call >> failed, the situation is not necessarily totally hopeless, as it is >> likely to be when >> CKR_GENERAL_ERROR is returned. Depending on what the root cause of the >> error actually was, it is possible that an attempt to make the exact >> same function call >> again would succeed. >> ... >> >> In this particular case, CKR_FUNCTION_FAILED error doesn't seem to be >> hopeless, and next call may succeed. The patch below tries to >> workaround this problem by calling C_GenerateKeyPair() function again >> in case of CKR_GENERAL_ERROR. >> >> I was not able to reproduce this failure manually on several >> machines, so unfortunately I am not completely sure it solves the >> problem. I can back out the fix if we see those failures again. >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8074580/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074580 >> >> Artem > From tiantian.du at oracle.com Thu Jun 23 02:44:31 2016 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 23 Jun 2016 10:44:31 +0800 Subject: [9] RFR 8146393:sun/security/tools/jarsigner/ts.sh failed on OEL Linux 7 with ar_SA Locale In-Reply-To: References: <576A354C.1080008@oracle.com> Message-ID: <576B4D0F.5080204@oracle.com> On 2016/6/22 18:27, Wang Weijun wrote: > Change looks fine. > > BTW, have you run the test with that special locale on? Yes, I have run the test on ru_RU , ko_KR, it_CH, fr_FR, hi_IN and ar_SA locales, only failed on ar_SA. After patching the codes change , it could passed on all of them. Regards Tim > > Thanks > Max > >> On Jun 22, 2016, at 2:50 PM, Tim Du wrote: >> >> Hi, >> >> Would you please review the path for following bug? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8146393 >> webrev: http://cr.openjdk.java.net/~tidu/8146393/webrev.00/ >> >> The test failed when using String.format() to format the server port on ar_SA Locale, Adding Locale.ROOT arguments to avoid the locale sensitive operations. It could pass on ar_SA locale platform after this code change.Thanks >> >> Regards >> Tim From weijun.wang at oracle.com Thu Jun 23 02:58:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 23 Jun 2016 10:58:33 +0800 Subject: [9] RFR 8146393:sun/security/tools/jarsigner/ts.sh failed on OEL Linux 7 with ar_SA Locale In-Reply-To: <576B4D0F.5080204@oracle.com> References: <576A354C.1080008@oracle.com> <576B4D0F.5080204@oracle.com> Message-ID: Brilliant! Thanks Max > On Jun 23, 2016, at 10:44 AM, Tim Du wrote: > > On 2016/6/22 18:27, Wang Weijun wrote: >> Change looks fine. >> >> BTW, have you run the test with that special locale on? > Yes, I have run the test on ru_RU , ko_KR, it_CH, fr_FR, hi_IN and ar_SA locales, only failed on ar_SA. After patching the codes change , it could passed on all of them. > > Regards > Tim From weijun.wang at oracle.com Thu Jun 23 03:35:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 23 Jun 2016 11:35:08 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <576AEB6F.8040406@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> Message-ID: In fact, now that getVersion() is deprecated, can we just always return 0d? On the other hand, your parseVersionStr(s) is not able to handle "9.0d". --Max > On Jun 23, 2016, at 3:47 AM, Valerie Peng wrote: > > Max, > > Thanks for the comments~ > > The String.valueOf() calls are for handling null values. > The name and id fields are also of type String and they use the String.valueOf() calls when putting in the Provider.id attribute values, so I follow the same convention. I also updated the parseVersionStr(String) utility method to handle null or invalid version strings though, and assign 0d if parsing fails. > > According to the Verona JEP, "java.specification.version" should be $VNUM which is a non-empty sequence of non- negative integer numerals, without leading zeros, separated by period characters. > I am not sure if we can assume the same format for supplied version string though. So, the current impl of parsing of version string can take the $VSTR (again in Verona JEP) which consists of $VUM optionally followed by pre-release and build info, i.e. $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)? > > Webrev updated: > http://cr.openjdk.java.net/~valeriep/8130181/webrev.01 > > Valerie > > On 6/15/2016 8:33 PM, Wang Weijun wrote: >> You used String.valueOf(provider.getVersionStr()) on lines 70 and 861. Why not just provider.getVersionStr()? >> >> For parseVersionStr(), where is the spec for "java.specification.version"? Can we just use regex /(^\d+(\.\d+)?)/ to match the substring and turn it into a double? >> >> --Max From svetlana.nikandrova at oracle.com Thu Jun 23 18:20:32 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 23 Jun 2016 21:20:32 +0300 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered Message-ID: <576C2870.7020601@oracle.com> Hello, could you please review and approve this supportability fix for JDK-8147969 . In jdk 9 this issue has been already addressed as part of the update for JDK-8072452 . JBS: 8147969: Print size of DH keysize when errors are encountered https://bugs.openjdk.java.net/browse/JDK-8147969 Webrev: http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ Thank you, Svetlana -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jun 23 23:33:11 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 Jun 2016 07:33:11 +0800 Subject: Code Review Request 8157712, Mark deprecated javax.security.cert and com.sun.net.ssl APIs with forRem,oval=true Message-ID: <652e1298-bbb1-c7da-8324-ebb25ef9b71b@oracle.com> Hi, Please review this update for JDK 9: http://cr.openjdk.java.net/~xuelei/8157712/webrev.00/ See http://openjdk.java.net/jeps/277 for details of the enhanced deprecation annotation. The JCE provider "com.sun.net.ssl.internal.ssl.Provider" would be deprecated since JDK 9, too. Thanks, Xuelei From valerie.peng at oracle.com Fri Jun 24 01:11:23 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 23 Jun 2016 18:11:23 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> Message-ID: <576C88BB.9010206@oracle.com> I am not sure if we can always return 0d for getVersion() even if we deprecate this method. Doubt that people are relying on this, but don't we normally keep the functionality the same after deprecating a method? "9.0d" is not the supported version format. The new version string syntax follows what's suggested in Verona JEP, not the the direct string representation of double. 9.0d is only for specifying double value in the older constructor. I don't think it means you can call the new constructor by just adding a quote around it to convert it into a String. Maybe we need to document it somewhere to prevent this potential user error? Valerie On 6/22/2016 8:35 PM, Wang Weijun wrote: > In fact, now that getVersion() is deprecated, can we just always return 0d? > > On the other hand, your parseVersionStr(s) is not able to handle "9.0d". > > --Max > >> On Jun 23, 2016, at 3:47 AM, Valerie Peng wrote: >> >> Max, >> >> Thanks for the comments~ >> >> The String.valueOf() calls are for handling null values. >> The name and id fields are also of type String and they use the String.valueOf() calls when putting in the Provider.id attribute values, so I follow the same convention. I also updated the parseVersionStr(String) utility method to handle null or invalid version strings though, and assign 0d if parsing fails. >> >> According to the Verona JEP, "java.specification.version" should be $VNUM which is a non-empty sequence of non- negative integer numerals, without leading zeros, separated by period characters. >> I am not sure if we can assume the same format for supplied version string though. So, the current impl of parsing of version string can take the $VSTR (again in Verona JEP) which consists of $VUM optionally followed by pre-release and build info, i.e. $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)? >> >> Webrev updated: >> http://cr.openjdk.java.net/~valeriep/8130181/webrev.01 >> >> Valerie >> >> On 6/15/2016 8:33 PM, Wang Weijun wrote: >>> You used String.valueOf(provider.getVersionStr()) on lines 70 and 861. Why not just provider.getVersionStr()? >>> >>> For parseVersionStr(), where is the spec for "java.specification.version"? Can we just use regex /(^\d+(\.\d+)?)/ to match the substring and turn it into a double? >>> >>> --Max From weijun.wang at oracle.com Fri Jun 24 01:15:20 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 24 Jun 2016 09:15:20 +0800 Subject: Code Review Request 8157712, Mark deprecated javax.security.cert and com.sun.net.ssl APIs with forRem, oval=true In-Reply-To: <652e1298-bbb1-c7da-8324-ebb25ef9b71b@oracle.com> References: <652e1298-bbb1-c7da-8324-ebb25ef9b71b@oracle.com> Message-ID: Looks fine. Only one thing uncertain: Since com.sun.* is not a part of Java SE, maybe you should write "This class is subject to removal in a future version of JDK". Also, since it's forRemoval, you can file another RFE targeting jdk10 for the actual removal. Thanks Max > On Jun 24, 2016, at 7:33 AM, Xuelei Fan wrote: > > Hi, > > Please review this update for JDK 9: > http://cr.openjdk.java.net/~xuelei/8157712/webrev.00/ > > See http://openjdk.java.net/jeps/277 for details of the enhanced > deprecation annotation. > > The JCE provider "com.sun.net.ssl.internal.ssl.Provider" would be > deprecated since JDK 9, too. > > Thanks, > Xuelei From weijun.wang at oracle.com Fri Jun 24 01:22:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 24 Jun 2016 09:22:09 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <576C88BB.9010206@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> Message-ID: <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> > On Jun 24, 2016, at 9:11 AM, Valerie Peng wrote: > > > I am not sure if we can always return 0d for getVersion() even if we deprecate this method. > Doubt that people are relying on this, but don't we normally keep the functionality the same after deprecating a method? I accept this. > > "9.0d" is not the supported version format. The new version string syntax follows what's suggested in Verona JEP, not the the direct string representation of double. 9.0d is only for specifying double value in the older constructor. I don't think it means you can call the new constructor by just adding a quote around it to convert it into a String. > Maybe we need to document it somewhere to prevent this potential user error? Yes. In the new Provider constructor, you mentioned 233 * @implNote The JDK implementation will process the specified version 234 * string by keeping only the major and minor versions and then 235 * convert the result into a double for {@code getVersion()}. If parsing 236 * failed, value 0 will be returned. but the meaning of "major and minor versions" is actually undefined. Do we really require a 3rd party vendor to use the Verona version style? Thanks Max From valerie.peng at oracle.com Fri Jun 24 01:56:38 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 23 Jun 2016 18:56:38 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> Message-ID: <576C9356.80108@oracle.com> Well, we have to define something for the version syntax and how it converts to the legacy double version. I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? Valerie On 6/23/2016 6:22 PM, Wang Weijun wrote: >> On Jun 24, 2016, at 9:11 AM, Valerie Peng wrote: >> >> >> I am not sure if we can always return 0d for getVersion() even if we deprecate this method. >> Doubt that people are relying on this, but don't we normally keep the functionality the same after deprecating a method? > I accept this. > >> "9.0d" is not the supported version format. The new version string syntax follows what's suggested in Verona JEP, not the the direct string representation of double. 9.0d is only for specifying double value in the older constructor. I don't think it means you can call the new constructor by just adding a quote around it to convert it into a String. >> Maybe we need to document it somewhere to prevent this potential user error? > Yes. > > In the new Provider constructor, you mentioned > > 233 * @implNote The JDK implementation will process the specified version > 234 * string by keeping only the major and minor versions and then > 235 * convert the result into a double for {@code getVersion()}. If parsing > 236 * failed, value 0 will be returned. > > but the meaning of "major and minor versions" is actually undefined. Do we really require a 3rd party vendor to use the Verona version style? > > Thanks > Max > From weijun.wang at oracle.com Fri Jun 24 01:59:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 24 Jun 2016 09:59:08 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <576C9356.80108@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> Message-ID: <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> If you mandate the use of Verona version style, can we just use the Version class in the constructor? > On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: > > > Well, we have to define something for the version syntax and how it converts to the legacy double version. > I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. > > Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? > Valerie From sean.coffey at oracle.com Fri Jun 24 06:59:52 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 24 Jun 2016 07:59:52 +0100 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <576C2870.7020601@oracle.com> References: <576C2870.7020601@oracle.com> Message-ID: <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> src/share/classes/sun/security/ssl/ServerHandshaker.java : ! "Unsupported customized DH key size: " + ! customizedDHKeySize + ". " + ! "The key size must be multiple of 64, " + ! "and can only range from 1024 to 2048 (inclusive)"); You can remove the "multiple of 64" text. That condition was only introduced into JDK 9 from what I read. Looks good otherwise. Don't forget to get new signed jar files generated when integrating. Regards, Sean. On 23/06/2016 19:20, Svetlana Nikandrova wrote: > Hello, > > could you please review and approve this supportability fix for > JDK-8147969 . > In jdk 9 this issue has been already addressed as part of the update > for JDK-8072452 . > > JBS: > 8147969: Print size of DH keysize when errors are encountered > https://bugs.openjdk.java.net/browse/JDK-8147969 > Webrev: > http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ > > > Thank you, > Svetlana -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Fri Jun 24 08:55:53 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 24 Jun 2016 16:55:53 +0800 Subject: [9] RFR 8157667: sun/security/x509/URICertStore/ExtensionsWithLDAP.java has to be updated due to JDK-8134577 Message-ID: <5717b5e1-605f-2c46-2cfd-d0dff631dd5c@oracle.com> Hi, Due to JDK-8134577, the test sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve hosts from a local name service provider. This fix creates a simple Socks4 proxy, and use it to resolve hosts from Socket. Issue: https://bugs.openjdk.java.net/browse/JDK-8157667 Webrev: http://cr.openjdk.java.net/~jjiang/8157667/webrev.01 Please note that, this fix provides two separated local hosts files. Each of them contains only one host entry. And the test is executed twice in deed. Each time, the test focus only one specific host, and uses one hosts file accordingly. If one hosts file includes two entries, like the below, 127.0.0.1 ldap.host.for.crldp 127.0.0.1 ldap.host.for.aia then, only the first host, ldap.host.for.crldp, is resolved by the proxy. If I misunderstand something, or you have better solution, please let me know. Thanks! John Jiang From xuelei.fan at oracle.com Fri Jun 24 10:26:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 24 Jun 2016 18:26:15 +0800 Subject: Code Review Request 8157712, Mark deprecated javax.security.cert and com.sun.net.ssl APIs with forRem,oval=true In-Reply-To: References: <652e1298-bbb1-c7da-8324-ebb25ef9b71b@oracle.com> Message-ID: On 6/24/2016 9:15 AM, Wang Weijun wrote: > Looks fine. > > Only one thing uncertain: Since com.sun.* is not a part of Java SE, maybe you should write "This class is subject to removal in a future version of JDK". > Updated in the new webrev: http://cr.openjdk.java.net/~xuelei/8157712/webrev.01/ > Also, since it's forRemoval, you can file another RFE targeting jdk10 for the actual removal. > A new RFE was filed: https://bugs.openjdk.java.net/browse/JDK-8160247 Thanks, Xuelei > Thanks > Max > > >> On Jun 24, 2016, at 7:33 AM, Xuelei Fan wrote: >> >> Hi, >> >> Please review this update for JDK 9: >> http://cr.openjdk.java.net/~xuelei/8157712/webrev.00/ >> >> See http://openjdk.java.net/jeps/277 for details of the enhanced >> deprecation annotation. >> >> The JCE provider "com.sun.net.ssl.internal.ssl.Provider" would be >> deprecated since JDK 9, too. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Fri Jun 24 10:47:07 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 24 Jun 2016 18:47:07 +0800 Subject: Code Review Request 8157712, Mark deprecated javax.security.cert and com.sun.net.ssl APIs with forRem, oval=true In-Reply-To: References: <652e1298-bbb1-c7da-8324-ebb25ef9b71b@oracle.com> Message-ID: <4FC63E41-E22D-444C-862E-550793B6BB06@oracle.com> Change looks fine. Thanks Max > ? 2016?6?24??18:26?Xuelei Fan ??? > >> On 6/24/2016 9:15 AM, Wang Weijun wrote: >> Looks fine. >> >> Only one thing uncertain: Since com.sun.* is not a part of Java SE, maybe you should write "This class is subject to removal in a future version of JDK". > Updated in the new webrev: > http://cr.openjdk.java.net/~xuelei/8157712/webrev.01/ > >> Also, since it's forRemoval, you can file another RFE targeting jdk10 for the actual removal. > A new RFE was filed: > https://bugs.openjdk.java.net/browse/JDK-8160247 > > Thanks, > Xuelei > >> Thanks >> Max >> >> >>> On Jun 24, 2016, at 7:33 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> Please review this update for JDK 9: >>> http://cr.openjdk.java.net/~xuelei/8157712/webrev.00/ >>> >>> See http://openjdk.java.net/jeps/277 for details of the enhanced >>> deprecation annotation. >>> >>> The JCE provider "com.sun.net.ssl.internal.ssl.Provider" would be >>> deprecated since JDK 9, too. >>> >>> Thanks, >>> Xuelei > From svetlana.nikandrova at oracle.com Fri Jun 24 11:48:30 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 24 Jun 2016 14:48:30 +0300 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> References: <576C2870.7020601@oracle.com> <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> Message-ID: <576D1E0E.9090501@oracle.com> Sean, thank you for spotting this "multiple of 64". Please see updated weberv: http://cr.openjdk.java.net/~snikandrova/8147969/webrev.01/ Thank you for your reminder. Surely, I have signed sunjce_provider.jar and sunpkcs11.jar in my pocket (I believe changes in ServerHandshaker.java should not affect them, so I don't need a new version because of that). Thank you, Svetlana On 24.06.2016 9:59, Se?n Coffey wrote: > > src/share/classes/sun/security/ssl/ServerHandshaker.java : > > ! "Unsupported customized DH key size: " + > ! customizedDHKeySize + ". " + > ! "The key size must be multiple of 64, " + > ! "and can only range from 1024 to 2048 > (inclusive)"); > > You can remove the "multiple of 64" text. That condition was only > introduced into JDK 9 from what I read. > > Looks good otherwise. Don't forget to get new signed jar files > generated when integrating. > > Regards, > Sean. > On 23/06/2016 19:20, Svetlana Nikandrova wrote: >> Hello, >> >> could you please review and approve this supportability fix for >> JDK-8147969 . >> In jdk 9 this issue has been already addressed as part of the update >> for JDK-8072452 . >> >> JBS: >> 8147969: Print size of DH keysize when errors are encountered >> https://bugs.openjdk.java.net/browse/JDK-8147969 >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ >> >> >> Thank you, >> Svetlana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Jun 24 12:06:55 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 24 Jun 2016 13:06:55 +0100 Subject: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered In-Reply-To: <576D1E0E.9090501@oracle.com> References: <576C2870.7020601@oracle.com> <04d170d0-d0db-ad3c-a861-d362c8ffabbc@oracle.com> <576D1E0E.9090501@oracle.com> Message-ID: <576D225F.3020800@oracle.com> Looks good. Approved for jdk8u-dev. Please add a suitable noreg- label to the bug report. Regards, Sean. On 24/06/16 12:48, Svetlana Nikandrova wrote: > Sean, > > thank you for spotting this "multiple of 64". Please see updated weberv: > > http://cr.openjdk.java.net/~snikandrova/8147969/webrev.01/ > > > Thank you for your reminder. Surely, I have signed sunjce_provider.jar > and sunpkcs11.jar in my pocket (I believe changes in > ServerHandshaker.java should not affect them, so I don't need a new > version because of that). > > Thank you, > Svetlana > > On 24.06.2016 9:59, Se?n Coffey wrote: >> >> src/share/classes/sun/security/ssl/ServerHandshaker.java : >> >> ! "Unsupported customized DH key size: " + >> ! customizedDHKeySize + ". " + >> ! "The key size must be multiple of 64, " + >> ! "and can only range from 1024 to 2048 >> (inclusive)"); >> >> You can remove the "multiple of 64" text. That condition was only >> introduced into JDK 9 from what I read. >> >> Looks good otherwise. Don't forget to get new signed jar files >> generated when integrating. >> >> Regards, >> Sean. >> On 23/06/2016 19:20, Svetlana Nikandrova wrote: >>> Hello, >>> >>> could you please review and approve this supportability fix for >>> JDK-8147969 . >>> In jdk 9 this issue has been already addressed as part of the update >>> for JDK-8072452 . >>> >>> JBS: >>> 8147969: Print size of DH keysize when errors are encountered >>> https://bugs.openjdk.java.net/browse/JDK-8147969 >>> Webrev: >>> http://cr.openjdk.java.net/~snikandrova/8147969/webrev.00/ >>> >>> >>> Thank you, >>> Svetlana >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Jun 24 23:50:52 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 24 Jun 2016 16:50:52 -0700 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> Message-ID: <576DC75C.9060503@oracle.com> I thought about it, but as Provider object is serializable, if the field is of new type Runtime.Version class, the (de-)serialization against older releases may break. What exactly is the version style that you have in mind then? I think the major.minor thing is quite reasonable. 1.9d does not really look like a version to me. Do you want to special handling this just because the earlier version is a double? Valerie On 6/23/2016 6:59 PM, Wang Weijun wrote: > If you mandate the use of Verona version style, can we just use the Version class in the constructor? > >> On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: >> >> >> Well, we have to define something for the version syntax and how it converts to the legacy double version. >> I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. >> >> Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? >> Valerie From weijun.wang at oracle.com Sat Jun 25 00:05:11 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 25 Jun 2016 08:05:11 +0800 Subject: [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String) In-Reply-To: <576DC75C.9060503@oracle.com> References: <5761F777.5030506@oracle.com> <9100FADE-23BE-4466-A8CD-85D0DCA9C7BB@oracle.com> <576AEB6F.8040406@oracle.com> <576C88BB.9010206@oracle.com> <5797C341-9708-4BA6-AEA7-12E37AEF6C0E@oracle.com> <576C9356.80108@oracle.com> <8A58454E-C7BA-43B0-93F9-F239DAC8EF8E@oracle.com> <576DC75C.9060503@oracle.com> Message-ID: <745DFC74-5E81-4E57-B4D8-C1AD018CDA62@oracle.com> > On Jun 25, 2016, at 7:50 AM, Valerie Peng wrote: > > I thought about it, but as Provider object is serializable, if the field is of new type Runtime.Version class, the (de-)serialization against older releases may break. I see. > > What exactly is the version style that you have in mind then? I think the major.minor thing is quite reasonable. > 1.9d does not really look like a version to me. Do you want to special handling this just because the earlier version is a double? Since you mentioned "major" and "minor" in the spec, we have to define it. Either referring to the Version class, or define one inside Provider. My preference is later, with a regex /(^\d+(\.\d+)?)/, which is a superset of Version. --Max > > Valerie > > On 6/23/2016 6:59 PM, Wang Weijun wrote: >> If you mandate the use of Verona version style, can we just use the Version class in the constructor? >> >>> On Jun 24, 2016, at 9:56 AM, Valerie Peng wrote: >>> >>> >>> Well, we have to define something for the version syntax and how it converts to the legacy double version. >>> I think it makes sense to follow the Verona JEP as that's the JDK version syntax which seems to fit the normal convention of release numbering. >>> >>> Maybe we can clarify major and minor by referring to java.lang.Runtime.Version class? >>> Valerie > From jvanek at redhat.com Mon Jun 27 09:37:42 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 27 Jun 2016 11:37:42 +0200 Subject: RFE/RFC reproducible policies In-Reply-To: References: <573DF2C0.7070000@oracle.com> <573EC702.7050608@oracle.com> <2fff94c8-c2b0-067e-b19c-863ac20d63c0@redhat.com> Message-ID: On 05/27/2016 12:37 AM, Bradford Wetmore wrote: > Hi Jiri, > > This is open issue #2 from JEP-220 [1] that we still need to address for JDK 9, so your patch will > likely be moot soon. It's possible that the jar will be going away. > > If you would like to watch the progress, please add yourself to: > > JDK-8061842: Package jurisdiction policy files as something other than JAR Hello! Any updates on this bug or generally on this patch? Maybe this patch[1] can go in, as - if policies will be persisted, then they should be build by reproducible way - if the policies will be removed (and that would be nice) then the code which is this patch affected will be removed anyway. > > Thanks for the forward Erik, I'm not able to follow build-dev all that closely lately. > > Brad > > [1] http://openjdk.java.net/jeps/220 Thanx! J. [1] https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/ From mandy.chung at oracle.com Mon Jun 27 19:27:06 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 27 Jun 2016 12:27:06 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> Message-ID: I?m including security-dev which would be a better list to review this test fix. Valerie, Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. See my comments below. > On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: > > Hi. > > Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. > > The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 > The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ The copyright header start year of the new tests should be 2016. I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., - drop @requires - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. Mandy From sha.jiang at oracle.com Mon Jun 27 22:42:23 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 28 Jun 2016 06:42:23 +0800 Subject: [9] RFR 8157667: sun/security/x509/URICertStore/ExtensionsWithLDAP.java has to be updated due to JDK-8134577 In-Reply-To: <5717b5e1-605f-2c46-2cfd-d0dff631dd5c@oracle.com> References: <5717b5e1-605f-2c46-2cfd-d0dff631dd5c@oracle.com> Message-ID: <8a63a9eb-1788-ca91-8ae9-627649426bb8@oracle.com> Please review this patch. Thanks! John Jiang On 2016/6/24 16:55, John Jiang wrote: > Hi, > Due to JDK-8134577, the test > sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve > hosts from a local name service provider. > This fix creates a simple Socks4 proxy, and use it to resolve hosts > from Socket. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157667 > Webrev: http://cr.openjdk.java.net/~jjiang/8157667/webrev.01 > > Please note that, this fix provides two separated local hosts files. > Each of them contains only one host entry. > And the test is executed twice in deed. Each time, the test focus only > one specific host, and uses one hosts file accordingly. > If one hosts file includes two entries, like the below, > 127.0.0.1 ldap.host.for.crldp > 127.0.0.1 ldap.host.for.aia > then, only the first host, ldap.host.for.crldp, is resolved by the proxy. > If I misunderstand something, or you have better solution, please let > me know. > > Thanks! > > John Jiang > > From artem.smotrakov at oracle.com Tue Jun 28 01:12:23 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 27 Jun 2016 18:12:23 -0700 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout Message-ID: <5771CEF7.8060400@oracle.com> Hello, Please review this patch for javax/net/ssl/DTLS tests. A couple of DTLS tests fail intermittently on Mac with timeout or "Too many handshake loops ..." error. The tests use UDP to transfer DTLS records. It happens sometimes that server cannot receive UDP packets with DatagramSocket.receive() method even if client tries to re-send them multiple times. Please see logs in the bug. At the moment, it is not clear why UDP packets can't be delivered to server. If someone has seen something similar before, or has some ideas what might be the root cause, please let me know. I think that the tests and DTLS implementation are fine here. Since the tests are for DTLS, we can workaround this issue by avoiding real UDP connections. To avoid changing test logic much, we can use a custom DatagramSocketImpl and DatagramSocketImplFactory implementations to replace system UDP implementation. The patch below updates the tests with the following: - added custom DatagramSocketImpl and DatagramSocketImplFactory implementations to avoid real UDP connections - added more test output, so that we can have more info it the tests fail again I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on all supported generic platforms, and they worked fine. Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ Artem From xuelei.fan at oracle.com Tue Jun 28 01:25:20 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 28 Jun 2016 09:25:20 +0800 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout In-Reply-To: <5771CEF7.8060400@oracle.com> References: <5771CEF7.8060400@oracle.com> Message-ID: <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> On 6/28/2016 9:12 AM, Artem Smotrakov wrote: > Hello, > > Please review this patch for javax/net/ssl/DTLS tests. > > A couple of DTLS tests fail intermittently on Mac with timeout or "Too > many handshake loops ..." error. The tests use UDP to transfer DTLS > records. It happens sometimes that server cannot receive UDP packets > with DatagramSocket.receive() method even if client tries to re-send > them multiple times. Please see logs in the bug. > > At the moment, it is not clear why UDP packets can't be delivered to > server. If someone has seen something similar before, or has some ideas > what might be the root cause, please let me know. > UDP is not reliable. It could happen that the packets get lost. > I think that the tests and DTLS implementation are fine here. Since the > tests are for DTLS, we can workaround this issue by avoiding real UDP > connections. To avoid changing test logic much, we can use a custom > DatagramSocketImpl and DatagramSocketImplFactory implementations to > replace system UDP implementation. > > The patch below updates the tests with the following: > - added custom DatagramSocketImpl and DatagramSocketImplFactory > implementations to avoid real UDP connections Tests for real connections in practice are needed. If we update this test this way, we need to add other tests to test real application usage. I don't think this is the right direction to avoid real UDP connections. > - added more test output, so that we can have more info it the tests > fail again > I agree with this point. Xuelei > I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, > and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on > all supported generic platforms, and they worked fine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 > http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ > > Artem From artem.smotrakov at oracle.com Tue Jun 28 17:02:21 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 28 Jun 2016 10:02:21 -0700 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout In-Reply-To: <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> References: <5771CEF7.8060400@oracle.com> <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> Message-ID: <5772AD9D.4000101@oracle.com> Hi Xuelei, Even if the tests keep using UDP to transfer data, they may not be realistic since they run on local host. UDP implementation is based on functions provided by OS. If I remember correctly, Solaris may do some optimizations for localhost connections, so that no real networking stack is used at all. If we want to test DTLS with real connections, I believe we should do the following: 1. Use two different machines 2. Make tests expect some issues with network and other environment #1 requires starting server and client on different hosts which doesn't seem to be possible with jtreg. Another option is to set up a remote server. #2 may require ignoring errors, and re-trying connections. I am not sure that we want to update existing tests with this. I think it is better to focus on DTLS testing, and make tests more stable. That's why I am proposing to use custom UDP sockets. If we want to test real connections, then it should be different tests which take into account #1 and #2 above. Artem On 06/27/2016 06:25 PM, Xuelei Fan wrote: > On 6/28/2016 9:12 AM, Artem Smotrakov wrote: >> Hello, >> >> Please review this patch for javax/net/ssl/DTLS tests. >> >> A couple of DTLS tests fail intermittently on Mac with timeout or "Too >> many handshake loops ..." error. The tests use UDP to transfer DTLS >> records. It happens sometimes that server cannot receive UDP packets >> with DatagramSocket.receive() method even if client tries to re-send >> them multiple times. Please see logs in the bug. >> >> At the moment, it is not clear why UDP packets can't be delivered to >> server. If someone has seen something similar before, or has some ideas >> what might be the root cause, please let me know. >> > UDP is not reliable. It could happen that the packets get lost. > >> I think that the tests and DTLS implementation are fine here. Since the >> tests are for DTLS, we can workaround this issue by avoiding real UDP >> connections. To avoid changing test logic much, we can use a custom >> DatagramSocketImpl and DatagramSocketImplFactory implementations to >> replace system UDP implementation. >> >> The patch below updates the tests with the following: >> - added custom DatagramSocketImpl and DatagramSocketImplFactory >> implementations to avoid real UDP connections > Tests for real connections in practice are needed. If we update this > test this way, we need to add other tests to test real application > usage. I don't think this is the right direction to avoid real UDP > connections. > >> - added more test output, so that we can have more info it the tests >> fail again >> > I agree with this point. > > Xuelei > >> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, >> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on >> all supported generic platforms, and they worked fine. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 >> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ >> >> Artem From mstjohns at comcast.net Tue Jun 28 17:36:56 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 28 Jun 2016 13:36:56 -0400 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout In-Reply-To: <5772AD9D.4000101@oracle.com> References: <5771CEF7.8060400@oracle.com> <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> <5772AD9D.4000101@oracle.com> Message-ID: <246b32eb-04a9-87fb-bcf5-863a3389a7d0@comcast.net> On 6/28/2016 1:02 PM, Artem Smotrakov wrote: > Hi Xuelei, > > Even if the tests keep using UDP to transfer data, they may not be > realistic since they run on local host. UDP implementation is based on > functions provided by OS. If I remember correctly, Solaris may do some > optimizations for localhost connections, so that no real networking > stack is used at all. Generically, the loopback address (127.0.0.1) is treated only marginally differently from using the normal interface IP address. I'm not sure what Solaris does, but for the most part you should be fine if you use one of the real interface addresses. > > If we want to test DTLS with real connections, I believe we should do > the following: > 1. Use two different machines > 2. Make tests expect some issues with network and other environment Instead take a look at https://sandilands.info/sgordon/dropping-packets-in-ubuntu-linux-using-tc-and-iptables - depending on the availability of these commands and functions, you should be able to do the testing on a single machine over the loopback address and get pseudo-real network behavior. Mike > > #1 requires starting server and client on different hosts which > doesn't seem to be possible with jtreg. Another option is to set up a > remote server. > > #2 may require ignoring errors, and re-trying connections. I am not > sure that we want to update existing tests with this. > > I think it is better to focus on DTLS testing, and make tests more > stable. That's why I am proposing to use custom UDP sockets. If we > want to test real connections, then it should be different tests which > take into account #1 and #2 above. > > Artem > > On 06/27/2016 06:25 PM, Xuelei Fan wrote: >> On 6/28/2016 9:12 AM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review this patch for javax/net/ssl/DTLS tests. >>> >>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too >>> many handshake loops ..." error. The tests use UDP to transfer DTLS >>> records. It happens sometimes that server cannot receive UDP packets >>> with DatagramSocket.receive() method even if client tries to re-send >>> them multiple times. Please see logs in the bug. >>> >>> At the moment, it is not clear why UDP packets can't be delivered to >>> server. If someone has seen something similar before, or has some ideas >>> what might be the root cause, please let me know. >>> >> UDP is not reliable. It could happen that the packets get lost. >> >>> I think that the tests and DTLS implementation are fine here. Since the >>> tests are for DTLS, we can workaround this issue by avoiding real UDP >>> connections. To avoid changing test logic much, we can use a custom >>> DatagramSocketImpl and DatagramSocketImplFactory implementations to >>> replace system UDP implementation. >>> >>> The patch below updates the tests with the following: >>> - added custom DatagramSocketImpl and DatagramSocketImplFactory >>> implementations to avoid real UDP connections >> Tests for real connections in practice are needed. If we update this >> test this way, we need to add other tests to test real application >> usage. I don't think this is the right direction to avoid real UDP >> connections. >> >>> - added more test output, so that we can have more info it the tests >>> fail again >>> >> I agree with this point. >> >> Xuelei >> >>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, >>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on >>> all supported generic platforms, and they worked fine. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 >>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ >>> >>> Artem > From artem.smotrakov at oracle.com Tue Jun 28 18:14:40 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 28 Jun 2016 11:14:40 -0700 Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout In-Reply-To: <246b32eb-04a9-87fb-bcf5-863a3389a7d0@comcast.net> References: <5771CEF7.8060400@oracle.com> <694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com> <5772AD9D.4000101@oracle.com> <246b32eb-04a9-87fb-bcf5-863a3389a7d0@comcast.net> Message-ID: <5772BE90.8060202@oracle.com> Hi Mike, On 06/28/2016 10:36 AM, Michael StJohns wrote: > On 6/28/2016 1:02 PM, Artem Smotrakov wrote: >> Hi Xuelei, >> >> Even if the tests keep using UDP to transfer data, they may not be >> realistic since they run on local host. UDP implementation is based >> on functions provided by OS. If I remember correctly, Solaris may do >> some optimizations for localhost connections, so that no real >> networking stack is used at all. > Generically, the loopback address (127.0.0.1) is treated only > marginally differently from using the normal interface IP address. > I'm not sure what Solaris does, but for the most part you should be > fine if you use one of the real interface addresses. Agree. Solaris is just an example that the loopback address may not use real network stack. >> >> If we want to test DTLS with real connections, I believe we should do >> the following: >> 1. Use two different machines >> 2. Make tests expect some issues with network and other environment > > Instead take a look at > https://sandilands.info/sgordon/dropping-packets-in-ubuntu-linux-using-tc-and-iptables > - depending on the availability of these commands and functions, you > should be able to do the testing on a single machine over the loopback > address and get pseudo-real network behavior. Thank you for this link! That's really useful for me, recently I was looking for similar tools like "tc". Artem > > Mike > >> >> #1 requires starting server and client on different hosts which >> doesn't seem to be possible with jtreg. Another option is to set up a >> remote server. >> >> #2 may require ignoring errors, and re-trying connections. I am not >> sure that we want to update existing tests with this. >> >> I think it is better to focus on DTLS testing, and make tests more >> stable. That's why I am proposing to use custom UDP sockets. If we >> want to test real connections, then it should be different tests >> which take into account #1 and #2 above. >> >> Artem >> >> On 06/27/2016 06:25 PM, Xuelei Fan wrote: >>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review this patch for javax/net/ssl/DTLS tests. >>>> >>>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too >>>> many handshake loops ..." error. The tests use UDP to transfer DTLS >>>> records. It happens sometimes that server cannot receive UDP packets >>>> with DatagramSocket.receive() method even if client tries to re-send >>>> them multiple times. Please see logs in the bug. >>>> >>>> At the moment, it is not clear why UDP packets can't be delivered to >>>> server. If someone has seen something similar before, or has some >>>> ideas >>>> what might be the root cause, please let me know. >>>> >>> UDP is not reliable. It could happen that the packets get lost. >>> >>>> I think that the tests and DTLS implementation are fine here. Since >>>> the >>>> tests are for DTLS, we can workaround this issue by avoiding real UDP >>>> connections. To avoid changing test logic much, we can use a custom >>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to >>>> replace system UDP implementation. >>>> >>>> The patch below updates the tests with the following: >>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory >>>> implementations to avoid real UDP connections >>> Tests for real connections in practice are needed. If we update this >>> test this way, we need to add other tests to test real application >>> usage. I don't think this is the right direction to avoid real UDP >>> connections. >>> >>>> - added more test output, so that we can have more info it the tests >>>> fail again >>>> >>> I agree with this point. >>> >>> Xuelei >>> >>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac, >>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS >>>> tests on >>>> all supported generic platforms, and they worked fine. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416 >>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/ >>>> >>>> Artem >> > From anthony.scarpino at oracle.com Tue Jun 28 21:17:10 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 28 Jun 2016 14:17:10 -0700 Subject: RFR: 8154015 Apply algorithm constraints to timestamped code Message-ID: <5772E956.4010305@oracle.com> Hi, I need a review of the below code. It's a continuation of the previous certpath related changes. Additional constraints checking on timestamped jars being checked by the deploy code http://cr.openjdk.java.net/~ascarpino/8154015/webrev.01/ thanks Tony From alexandre.iline at oracle.com Tue Jun 28 17:41:43 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 28 Jun 2016 10:41:43 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> Message-ID: Copyrights fixed in place. Thank you, Mandy. Shura > On Jun 27, 2016, at 12:27 PM, Mandy Chung wrote: > > I?m including security-dev which would be a better list to review this test fix. > > Valerie, > Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. > > See my comments below. > >> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >> >> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >> >> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ > > The copyright header start year of the new tests should be 2016. > > I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., > - drop @requires > - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list > > If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. > > Mandy > From valerie.peng at oracle.com Wed Jun 29 00:22:04 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 28 Jun 2016 17:22:04 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> Message-ID: <577314AC.2090202@oracle.com> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). The original test already detects the OS and will skip certain providers accordingly. Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. If we can't query what modules are available, then we may have to think of something else. Valerie On 6/27/2016 12:27 PM, Mandy Chung wrote: > I?m including security-dev which would be a better list to review this test fix. > > Valerie, > Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. > > See my comments below. > >> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >> >> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >> >> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ > The copyright header start year of the new tests should be 2016. > > I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., > - drop @requires > - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list > > If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. > > Mandy > From weijun.wang at oracle.com Wed Jun 29 01:09:57 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 29 Jun 2016 09:09:57 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <42EAA796-09E7-4209-9C7E-8788D66CF67E@oracle.com> <56C6E200.3070800@oracle.com> <4BB3D736-BC1C-4CAE-9C04-43AE882DDBC9@oracle.com> <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> Message-ID: Ping again to security-dev. Anyone can approve it? The latest webrev is at http://cr.openjdk.java.net/~weijun/8130302/webrev.06 Change from webrev.05 [1] is tiny. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html > On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: > > >> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >> >> No big difference to me. > > Good, I'll remove the cast. > > @security-dev, can someone approve the whole webrev.05? > > http://cr.openjdk.java.net/~weijun/8130302/webrev.05 > > Thanks > Max > >> Valerie >> >> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>> >>>>>> 241 throw (InvalidParameterException) >>>>>> >>>>>> This cast should not be needed? >>>>>> >>>>> } catch (UcryptoException ue) { >>>>> throw (InvalidParameterException) >>>>> new InvalidParameterException("Error using " + configArg). >>>>> initCause(ue.getCause()); >>>>> } >>>>> >>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>> >>>> Perhaps have a local variable for InvalidParameterException exception. >>> Valerie, are you OK with this? >>> >>> --Max >>> >>>> Mandy > From valerie.peng at oracle.com Wed Jun 29 01:12:46 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 28 Jun 2016 18:12:46 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> Message-ID: <5773208E.6040505@oracle.com> I will take a look tomorrow. Thanks, Valerie On 6/28/2016 6:09 PM, Wang Weijun wrote: > Ping again to security-dev. Anyone can approve it? > > The latest webrev is at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.06 > > Change from webrev.05 [1] is tiny. > > Thanks > Max > > [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html > >> On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: >> >> >>> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >>> >>> No big difference to me. >> Good, I'll remove the cast. >> >> @security-dev, can someone approve the whole webrev.05? >> >> http://cr.openjdk.java.net/~weijun/8130302/webrev.05 >> >> Thanks >> Max >> >>> Valerie >>> >>> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>>> >>>>>>> 241 throw (InvalidParameterException) >>>>>>> >>>>>>> This cast should not be needed? >>>>>>> >>>>>> } catch (UcryptoException ue) { >>>>>> throw (InvalidParameterException) >>>>>> new InvalidParameterException("Error using " + configArg). >>>>>> initCause(ue.getCause()); >>>>>> } >>>>>> >>>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>>> >>>>> Perhaps have a local variable for InvalidParameterException exception. >>>> Valerie, are you OK with this? >>>> >>>> --Max >>>> >>>>> Mandy From jamil.j.nimeh at oracle.com Wed Jun 29 01:18:43 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 28 Jun 2016 18:18:43 -0700 Subject: RFR 8143302: javax/net/ssl/Stapling/SSLSocketWithStapling.java fails intermittently: Server died Message-ID: <577321F3.5070507@oracle.com> Hi all, This fixes a couple problems. The first is a file descriptor leak in the SSLSocketWithStapling test. The second is a thread exhaustion issue that can happen when many many (> 1000) SSLContext objects are created with StatusResponseManagers. I think this is a pretty far flung edge case in the real world, but our test framework manages to hit it from time to time. By allowing the core threads in the StatusResponseManager to time out, it prevents the system from running out of threads when so many SSLContext objects are created and used to support servers that have stapling enabled (all of that has to be true to run into this issue). I was able to create over 100K SSLContext objects in rapid succession without running into any kind of thread exhaustion with this fix. I also added a discard policy for another rare case (one I haven't seen happen) where the thread pool could be completely busy and another job needs to be serviced. Rather than the default policy which throws an exception, it is better to discard the job so the connection can proceed, even if the result might be that stapling is disabled for that connection. Again, an exceedingly rare edge case, one never seen even in performance tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8143302 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8143302/webrev.01/ Thanks, --Jamil From tiantian.du at oracle.com Wed Jun 29 09:32:42 2016 From: tiantian.du at oracle.com (Tim Du) Date: Wed, 29 Jun 2016 17:32:42 +0800 Subject: [9] RFR 8160415:Mark sun/security/tools/keytool/standard.sh as intermittently failing Message-ID: <577395BA.1080103@oracle.com> Hi , May I request to review for marking test sun/security/tools/keytool/standard.sh with key intermittent, it has been seen intermittently failed JDK-8144806 . bug: https://bugs.openjdk.java.net/browse/JDK-8160415 webrev: http://cr.openjdk.java.net/~tidu/8160415/webrev.00/ diff -r 73e1dc20396a test/sun/security/tools/keytool/standard.sh --- a/test/sun/security/tools/keytool/standard.sh Tue Jun 28 14:39:09 2016 +0800 +++ b/test/sun/security/tools/keytool/standard.sh Wed Jun 29 02:15:12 2016 -0700 @@ -25,6 +25,7 @@ # @summary (almost) all keytool behaviors # @author Weijun Wang # @run shell/timeout=600 standard.sh +# @key intermittent # # This test is always excecuted. # Thanks Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jun 29 10:20:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 29 Jun 2016 18:20:43 +0800 Subject: [9] RFR 8160415:Mark sun/security/tools/keytool/standard.sh as intermittently failing In-Reply-To: <577395BA.1080103@oracle.com> References: <577395BA.1080103@oracle.com> Message-ID: <73E184D7-15B8-4AB4-83A9-A8104151F955@oracle.com> Sure, please add. Thanks Max > On Jun 29, 2016, at 5:32 PM, Tim Du wrote: > > Hi , > > May I request to review for marking test sun/security/tools/keytool/standard.sh with key intermittent, it has been seen intermittently failed JDK-8144806 . > > bug: https://bugs.openjdk.java.net/browse/JDK-8160415 > webrev: http://cr.openjdk.java.net/~tidu/8160415/webrev.00/ > > diff -r 73e1dc20396a test/sun/security/tools/keytool/standard.sh > --- a/test/sun/security/tools/keytool/standard.sh Tue Jun 28 14:39:09 2016 +0800 > +++ b/test/sun/security/tools/keytool/standard.sh Wed Jun 29 02:15:12 2016 -0700 > @@ -25,6 +25,7 @@ > # @summary (almost) all keytool behaviors > # @author Weijun Wang > # @run shell/timeout=600 standard.sh > +# @key intermittent > # > # This test is always excecuted. > # > > Thanks > Tim From ivan.gerasimov at oracle.com Wed Jun 29 15:20:31 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 29 Jun 2016 18:20:31 +0300 Subject: RFR: 8153948: sun/security/mscapi/ShortRSAKey1024.sh fails with "Field length overflow" Message-ID: Hello! The mentioned test was seen failing on a machine, where the keystore contains a lot of certificates because they overflowed the maximum allowed list of authorities in the CertificateRequest TLS message. To make the test more robust, it is proposed to create a custom TrustManager, which will filter out all the certificates except the one really used in the test. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153948 WEBREV: http://cr.openjdk.java.net/~igerasim/8153948/01/webrev/ Would you please help review this fix? With kind regard, Ivan From valerie.peng at oracle.com Wed Jun 29 17:41:37 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 Jun 2016 10:41:37 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> Message-ID: <57740851.5040402@oracle.com> It's not like the test silently passes as the test still covers the cross-platform modules. The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. Just my .02, Valerie On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >> >> >> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >> >> The original test already detects the OS and will skip certain providers accordingly. >> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? > ModuleFinder.ofSystem().find(String). > > We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. > > So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. > > This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. > > Mandy? > > Shura > >> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >> >> If we can't query what modules are available, then we may have to think of something else. >> Valerie >> >> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>> I?m including security-dev which would be a better list to review this test fix. >>> >>> Valerie, >>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>> >>> See my comments below. >>> >>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>> >>>> Hi. >>>> >>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>> >>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>> >>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>> The copyright header start year of the new tests should be 2016. >>> >>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>> - drop @requires >>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>> >>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>> >>> Mandy >>> From mandy.chung at oracle.com Wed Jun 29 17:50:58 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jun 2016 10:50:58 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <57740851.5040402@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> Message-ID: <0C8CD227-06A1-4964-861B-857992B700F1@oracle.com> Valerie?s suggestion is a good one. The test will require a minimum image with cross-platform security providers to run the test while it can still verify other platform-specific providers. Mandy > On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: > > > It's not like the test silently passes as the test still covers the cross-platform modules. > The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. > > Just my .02, > Valerie > > On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>> >>> >>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>> >>> The original test already detects the OS and will skip certain providers accordingly. >>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >> ModuleFinder.ofSystem().find(String). >> >> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >> >> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >> >> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >> >> Mandy? >> >> Shura >> >>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>> >>> If we can't query what modules are available, then we may have to think of something else. >>> Valerie >>> >>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>> I?m including security-dev which would be a better list to review this test fix. >>>> >>>> Valerie, >>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>> >>>> See my comments below. >>>> >>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>> >>>>> Hi. >>>>> >>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>> >>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>> >>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>> The copyright header start year of the new tests should be 2016. >>>> >>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>> - drop @requires >>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>> >>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>> >>>> Mandy >>>> > From anthony.scarpino at oracle.com Wed Jun 29 18:50:50 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 29 Jun 2016 11:50:50 -0700 Subject: RFR: 8159180 Remove default setting for jdk.security.provider.preferred Message-ID: <5774188A.7090400@oracle.com> Hi, I need a review of this simple change to to undo the default settings for the jdk.security.provider.preferred. The only code changes are test related. The test now sets the property to test the previous default functionality. http://cr.openjdk.java.net/~ascarpino/8159180/webrev/ thanks Tony From alexandre.iline at oracle.com Wed Jun 29 17:22:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 29 Jun 2016 10:22:57 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <577314AC.2090202@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> Message-ID: <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> > On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: > > > One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). > > The original test already detects the OS and will skip certain providers accordingly. > Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? ModuleFinder.ofSystem().find(String). We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. Mandy? Shura > If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. > > If we can't query what modules are available, then we may have to think of something else. > Valerie > > On 6/27/2016 12:27 PM, Mandy Chung wrote: >> I?m including security-dev which would be a better list to review this test fix. >> >> Valerie, >> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >> >> See my comments below. >> >>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>> >>> Hi. >>> >>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>> >>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>> >>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >> The copyright header start year of the new tests should be 2016. >> >> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >> - drop @requires >> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >> >> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >> >> Mandy >> > From alexandre.iline at oracle.com Wed Jun 29 17:43:33 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 29 Jun 2016 10:43:33 -0700 Subject: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java In-Reply-To: <57740851.5040402@oracle.com> References: <3F96663F-0934-4EE9-9B21-F136DA3ABCF2@oracle.com> <577314AC.2090202@oracle.com> <4667C37F-EAD7-498D-91CF-3F69CF48129A@oracle.com> <57740851.5040402@oracle.com> Message-ID: > On Jun 29, 2016, at 10:41 AM, Valerie Peng wrote: > > > It's not like the test silently passes as the test still covers the cross-platform modules. > The way I view this is that the platform=specific modules are "optional" and we update the expected result by detecting their presence (or the not). It's not a hack or workaround, but rather an enhancement for the test to handle different images. Oh ? that makes more sense. I mis-understood it originally. Let me fix it like this. Shura > > Just my .02, > Valerie > > On 6/29/2016 10:22 AM, Alexandre (Shura) Iline wrote: >>> On Jun 28, 2016, at 5:22 PM, Valerie Peng wrote: >>> >>> >>> One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). >>> >>> The original test already detects the OS and will skip certain providers accordingly. >>> Instead of splitting the test into multiple platform-specific tests, maybe we can keep the original test but add module-presence checking? Is there API available to query if certain module are present? >> ModuleFinder.ofSystem().find(String). >> >> We can have only the cross-platform modules listed in @modules and make the test to pass silently if the required platform-specific modules are not present. >> >> So, for example, on windows, if the test would be executed against an image which have no jdk.crypto.mscapi, the test will not run any checks and report pass. >> >> This would help to avoid the additional test creation, but it will add another silently passing test, which is less clean. >> >> Mandy? >> >> Shura >> >>> If yes, then we can leave out the platform-specific providers from the @modules line and skip the providers if either the OS does not match or the module is not present. >>> >>> If we can't query what modules are available, then we may have to think of something else. >>> Valerie >>> >>> On 6/27/2016 12:27 PM, Mandy Chung wrote: >>>> I?m including security-dev which would be a better list to review this test fix. >>>> >>>> Valerie, >>>> Does this test have to be order-sensitive? I think this test would be cleaner to make it order-insensitive and simply test the security provider initialization. >>>> >>>> See my comments below. >>>> >>>>> On Jun 27, 2016, at 8:21 AM, Alexandre (Shura) Iline wrote: >>>>> >>>>> Hi. >>>>> >>>>> Please take a look on a suggested for for the java/lang/SecurityManager/CheckSecurityProvider.java test. >>>>> >>>>> The test in question depend on a list of modules, some of them are platform-specific. Listing all the dependencies in one test is causing the test to be skipped on every platform. In an offline conversation it was decided that it is better to split this tests into a few tests to declare the per-platform module dependencies. >>>>> >>>>> The bug: https://bugs.openjdk.java.net/browse/JDK-8158670 >>>>> The suggested fix: http://cr.openjdk.java.net/~shurailine/8158670/webrev.00/ >>>> The copyright header start year of the new tests should be 2016. >>>> >>>> I would suggest to make CheckSecurityProvide a platform-neutral test, i.e., >>>> - drop @requires >>>> - make line 94-97 to ignore the platform-dependent provider if it?s present in the white list >>>> >>>> If we could make this test order-insensitive, it?d be cleaner to maintain a platform-neutral list of security providers and one list for the platform-dependent security providers for each platform. Just an idea. >>>> >>>> Mandy >>>> > From xuelei.fan at oracle.com Thu Jun 30 00:16:26 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 30 Jun 2016 08:16:26 +0800 Subject: RFR: 8159180 Remove default setting for jdk.security.provider.preferred In-Reply-To: <5774188A.7090400@oracle.com> References: <5774188A.7090400@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/30/2016 2:50 AM, Anthony Scarpino wrote: > Hi, > > I need a review of this simple change to to undo the default settings > for the jdk.security.provider.preferred. The only code changes are test > related. The test now sets the property to test the previous default > functionality. > > http://cr.openjdk.java.net/~ascarpino/8159180/webrev/ > > thanks > > Tony From xuelei.fan at oracle.com Thu Jun 30 00:33:51 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 30 Jun 2016 08:33:51 +0800 Subject: RFR 8143302: javax/net/ssl/Stapling/SSLSocketWithStapling.java fails intermittently: Server died In-Reply-To: <577321F3.5070507@oracle.com> References: <577321F3.5070507@oracle.com> Message-ID: <63031ae4-413c-8e8e-e6e5-d0d54be671a2@oracle.com> Nice fix! Thanks, Xuelei On 6/29/2016 9:18 AM, Jamil Nimeh wrote: > Hi all, > > This fixes a couple problems. The first is a file descriptor leak in > the SSLSocketWithStapling test. The second is a thread exhaustion issue > that can happen when many many (> 1000) SSLContext objects are created > with StatusResponseManagers. I think this is a pretty far flung edge > case in the real world, but our test framework manages to hit it from > time to time. By allowing the core threads in the StatusResponseManager > to time out, it prevents the system from running out of threads when so > many SSLContext objects are created and used to support servers that > have stapling enabled (all of that has to be true to run into this > issue). I was able to create over 100K SSLContext objects in rapid > succession without running into any kind of thread exhaustion with this > fix. > > I also added a discard policy for another rare case (one I haven't seen > happen) where the thread pool could be completely busy and another job > needs to be serviced. Rather than the default policy which throws an > exception, it is better to discard the job so the connection can > proceed, even if the result might be that stapling is disabled for that > connection. Again, an exceedingly rare edge case, one never seen even > in performance tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143302 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8143302/webrev.01/ > > Thanks, > --Jamil From valerie.peng at oracle.com Thu Jun 30 01:39:55 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 Jun 2016 18:39:55 -0700 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> Message-ID: <5774786B.9010307@oracle.com> Hi Max, Changes look fine. Just some comments/questions as below. - line 46, fix this {0} as well? - line 151, maybe it should be calling the createUsingTestJDK? Otherwise the default is to use the compiler JDK - line 53, better to use -providerClass? Thanks, Valerie On 6/28/2016 6:09 PM, Wang Weijun wrote: > Ping again to security-dev. Anyone can approve it? > > The latest webrev is at > > http://cr.openjdk.java.net/~weijun/8130302/webrev.06 > > Change from webrev.05 [1] is tiny. > > Thanks > Max > > [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html > >> On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: >> >> >>> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >>> >>> No big difference to me. >> Good, I'll remove the cast. >> >> @security-dev, can someone approve the whole webrev.05? >> >> http://cr.openjdk.java.net/~weijun/8130302/webrev.05 >> >> Thanks >> Max >> >>> Valerie >>> >>> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>>> >>>>>>> 241 throw (InvalidParameterException) >>>>>>> >>>>>>> This cast should not be needed? >>>>>>> >>>>>> } catch (UcryptoException ue) { >>>>>> throw (InvalidParameterException) >>>>>> new InvalidParameterException("Error using " + configArg). >>>>>> initCause(ue.getCause()); >>>>>> } >>>>>> >>>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>>> >>>>> Perhaps have a local variable for InvalidParameterException exception. >>>> Valerie, are you OK with this? >>>> >>>> --Max >>>> >>>>> Mandy From weijun.wang at oracle.com Thu Jun 30 03:18:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 30 Jun 2016 11:18:03 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <5774786B.9010307@oracle.com> References: <301EAFFD-F524-40F8-A09E-65E486E237DC@oracle.com> <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> Message-ID: > On Jun 30, 2016, at 9:39 AM, Valerie Peng wrote: > > Hi Max, > > Changes look fine. Just some comments/questions as below. > > > - line 46, fix this {0} as well? I don't see {0} in keytool/Resources.java. There is one in jarsigner/Resources.java: 46 {"signerClass.is.not.a.signing.mechanism", "{0} is not a signing mechanism"}, You mean it's useless now? > > > - line 151, maybe it should be calling the createUsingTestJDK? Otherwise the default is to use the compiler JDK Yes. I don't know this method before. > > > - line 53, better to use -providerClass? Both should work. -addprovider works because SUN is already a loaded provider. -providerclass works because sun.security.provider.Sun is a public class in the same module. I prefer -addprovider because -providerclass is only for legacy providers loaded with reflection. In fact, I noticed that SUN is also not in ServiceLoader.load(Provider.class), which means it is not a service. Is that why you suggest the test load it with -providerclass? Thanks Max > > Thanks, > Valerie > > On 6/28/2016 6:09 PM, Wang Weijun wrote: >> Ping again to security-dev. Anyone can approve it? >> >> The latest webrev is at >> >> http://cr.openjdk.java.net/~weijun/8130302/webrev.06 >> >> Change from webrev.05 [1] is tiny. >> >> Thanks >> Max >> >> [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html >> >>> On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: >>> >>> >>>> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >>>> >>>> No big difference to me. >>> Good, I'll remove the cast. >>> >>> @security-dev, can someone approve the whole webrev.05? >>> >>> http://cr.openjdk.java.net/~weijun/8130302/webrev.05 >>> >>> Thanks >>> Max >>> >>>> Valerie >>>> >>>> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>>>> >>>>>>>> 241 throw (InvalidParameterException) >>>>>>>> >>>>>>>> This cast should not be needed? >>>>>>>> >>>>>>> } catch (UcryptoException ue) { >>>>>>> throw (InvalidParameterException) >>>>>>> new InvalidParameterException("Error using " + configArg). >>>>>>> initCause(ue.getCause()); >>>>>>> } >>>>>>> >>>>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>>>> >>>>>> Perhaps have a local variable for InvalidParameterException exception. >>>>> Valerie, are you OK with this? >>>>> >>>>> --Max >>>>> >>>>>> Mandy > From jamil.j.nimeh at oracle.com Thu Jun 30 07:39:12 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 30 Jun 2016 00:39:12 -0700 Subject: RFR: Fix typographical errors in Cipher.java (JDK-8030132 and JDK-8160222) Message-ID: <5774CCA0.3080009@oracle.com> Hello all, This fixes a few typos in the Javadoc for Cipher.java. Bug: https://bugs.openjdk.java.net/browse/JDK-8030132 https://bugs.openjdk.java.net/browse/JDK-8160222 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8030132/webrev.01/ --Jamil From weijun.wang at oracle.com Thu Jun 30 10:10:55 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 30 Jun 2016 18:10:55 +0800 Subject: RFR: Fix typographical errors in Cipher.java (JDK-8030132 and JDK-8160222) In-Reply-To: <5774CCA0.3080009@oracle.com> References: <5774CCA0.3080009@oracle.com> Message-ID: <6423BF85-7A6D-4C45-B916-F9F65B29EC5E@oracle.com> Change looks fine. Thanks Max > On Jun 30, 2016, at 3:39 PM, Jamil Nimeh wrote: > > Hello all, > > This fixes a few typos in the Javadoc for Cipher.java. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8030132 > https://bugs.openjdk.java.net/browse/JDK-8160222 > > Webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/8030132/webrev.01/ > > --Jamil From sean.coffey at oracle.com Thu Jun 30 10:59:44 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 30 Jun 2016 11:59:44 +0100 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> Message-ID: <7d7becf2-42b7-d302-9e89-56e98876d74e@oracle.com> minor comment from me Max. src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java > 293 throw new IllegalArgumentException("No provider found"); Can you print the provider name that was being searched for in your exception ? Regards, Sean. On 30/06/2016 04:18, Wang Weijun wrote: >> On Jun 30, 2016, at 9:39 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Changes look fine. Just some comments/questions as below. >> >> >> - line 46, fix this {0} as well? > I don't see {0} in keytool/Resources.java. > > There is one in jarsigner/Resources.java: > > 46 {"signerClass.is.not.a.signing.mechanism", "{0} is not a signing mechanism"}, > > You mean it's useless now? > >> >> - line 151, maybe it should be calling the createUsingTestJDK? Otherwise the default is to use the compiler JDK > Yes. I don't know this method before. > >> >> - line 53, better to use -providerClass? > Both should work. > > -addprovider works because SUN is already a loaded provider. > -providerclass works because sun.security.provider.Sun is a public class in the same module. > > I prefer -addprovider because -providerclass is only for legacy providers loaded with reflection. > > In fact, I noticed that SUN is also not in ServiceLoader.load(Provider.class), which means it is not a service. Is that why you suggest the test load it with -providerclass? > > Thanks > Max > >> Thanks, >> Valerie >> >> On 6/28/2016 6:09 PM, Wang Weijun wrote: >>> Ping again to security-dev. Anyone can approve it? >>> >>> The latest webrev is at >>> >>> http://cr.openjdk.java.net/~weijun/8130302/webrev.06 >>> >>> Change from webrev.05 [1] is tiny. >>> >>> Thanks >>> Max >>> >>> [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html >>> >>>> On Jun 16, 2016, at 9:33 AM, Wang Weijun wrote: >>>> >>>> >>>>> On Jun 16, 2016, at 7:50 AM, Valerie Peng wrote: >>>>> >>>>> No big difference to me. >>>> Good, I'll remove the cast. >>>> >>>> @security-dev, can someone approve the whole webrev.05? >>>> >>>> http://cr.openjdk.java.net/~weijun/8130302/webrev.05 >>>> >>>> Thanks >>>> Max >>>> >>>>> Valerie >>>>> >>>>> On 6/15/2016 8:40 AM, Wang Weijun wrote: >>>>>>> On Jun 15, 2016, at 10:57 PM, Mandy Chung wrote: >>>>>>> >>>>>>>>> 241 throw (InvalidParameterException) >>>>>>>>> >>>>>>>>> This cast should not be needed? >>>>>>>>> >>>>>>>> } catch (UcryptoException ue) { >>>>>>>> throw (InvalidParameterException) >>>>>>>> new InvalidParameterException("Error using " + configArg). >>>>>>>> initCause(ue.getCause()); >>>>>>>> } >>>>>>>> >>>>>>>> initCause() returns Throwable but the method's signature throws InvalidParameterException. >>>>>>>> >>>>>>> Perhaps have a local variable for InvalidParameterException exception. >>>>>> Valerie, are you OK with this? >>>>>> >>>>>> --Max >>>>>> >>>>>>> Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Jun 30 13:24:11 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 30 Jun 2016 16:24:11 +0300 Subject: RFR: Fix typographical errors in Cipher.java (JDK-8030132 and JDK-8160222) In-Reply-To: <5774CCA0.3080009@oracle.com> References: <5774CCA0.3080009@oracle.com> Message-ID: <3d758f4a-600c-280c-921e-1fd3c89c2300@oracle.com> Looks good! Similar typo is found in another file: java.security.jgss/share/classes/sun/security/jgss/spi/GSSContextSpi.java: * Return the mechanism-specific attribute associated with (@code type}. May be worth fixing it together. With kind regards, Ivan On 30.06.2016 10:39, Jamil Nimeh wrote: > Hello all, > > This fixes a few typos in the Javadoc for Cipher.java. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8030132 > https://bugs.openjdk.java.net/browse/JDK-8160222 > > Webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/8030132/webrev.01/ > > --Jamil > From weijun.wang at oracle.com Thu Jun 30 13:44:21 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 30 Jun 2016 21:44:21 +0800 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <7d7becf2-42b7-d302-9e89-56e98876d74e@oracle.com> References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <7d7bec! f2-42b7-d302-9e89-56e98876d74e@oracle.com> Message-ID: <2199A7D1-677C-434B-A856-8DE33315CC5E@oracle.com> Hi Sean Thanks for the comment. This exception is thrown by a helper class, which is then caught by the application class and a new localized error message including the provider name is shown to the user. Is that enough? Thanks Max > On Jun 30, 2016, at 6:59 PM, Se?n Coffey wrote: > > minor comment from me Max. > src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java > > >> 293 throw new IllegalArgumentException("No provider found"); > Can you print the provider name that was being searched for in your exception ? > > > Regards, > Sean. >>>> >>>> http://cr.openjdk.java.net/~weijun/8130302/webrev.06 From sean.coffey at oracle.com Thu Jun 30 13:46:14 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 30 Jun 2016 14:46:14 +0100 Subject: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules In-Reply-To: <2199A7D1-677C-434B-A856-8DE33315CC5E@oracle.com> References: <04F33E30-05B6-4156-BE5D-3838D945CE5C@oracle.com> <54FEEAB6-BEA4-427D-8CE7-0AF25BBDF75E@oracle.com> <53302B38-A13E-43B3-ACEF-CC6905793856@oracle.com> <4CB0E2B3-79F2-459E-A6F6-267C534EE17A@oracle.com> <50bdfe70-b3f3-27db-08bc-16bd4657df81@oracle.com> <69B6E9F9-C991-42AD-BC36-71C0F26CC4F0@oracle.com> <87C5A9A1-8030-4EEB-BD93-135C1566D0EE@oracle.com> <59DE66B0-9C12-4D0E-9DE8-378A47D0B8DD@oracle.com> <032A3399-24D1-469F-9A7E-99E0A6FF53A3@oracle.com> <7A8A9004-C1DB-4CCD-9119-62DF352C5888@ora! ! cle.com> <5761E9DA.6040205@oracle.com> <5774786B.9010307@oracle.com> <7d7becf2-42b7-d302-9e89-56e98876d74e@oracle.com> <2199A7D1-677C-434B-A856-8DE33315CC5E@oracle.com> Message-ID: On 30/06/2016 14:44, Wang Weijun wrote: > Hi Sean > > Thanks for the comment. This exception is thrown by a helper class, which is then caught by the application class and a new localized error message including the provider name is shown to the user. Is that enough? Perfect. That should do! thanks, Sean. > > Thanks > Max > > >> On Jun 30, 2016, at 6:59 PM, Se?n Coffey wrote: >> >> minor comment from me Max. >> src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java >> >> >>> 293 throw new IllegalArgumentException("No provider found"); >> Can you print the provider name that was being searched for in your exception ? >> >> >> Regards, >> Sean. >>>>> http://cr.openjdk.java.net/~weijun/8130302/webrev.06 From sean.mullan at oracle.com Thu Jun 30 19:00:27 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 Jun 2016 15:00:27 -0400 Subject: RFR: 8154015 Apply algorithm constraints to timestamped code In-Reply-To: <5772E956.4010305@oracle.com> References: <5772E956.4010305@oracle.com> Message-ID: <57756C4B.3030701@oracle.com> Just a few comments - AlgorithmChecker.java: 79 private Date pkixdate = null; 81 private Timestamp jarTimestamp = null; These can be marked final I think. 150 * {@code AlgorithmConstraints}. s/AlgorithmConstraints/Timestamp/ 153 * path for JAR files from deploy. Avoid using "from deploy". s/JAR files from deploy/signed JAR files that are timestamped./ 159 this(certPathDefaultConstraints, jarTimestamp.getTimestamp()); This will throw NPE if jarTimestamp is null. 177 public AlgorithmChecker(AlgorithmConstraints constraints, Date pkixdate) { I think this should be private. You are only calling it within the class. Also, the javadoc ctor description needs to be updated a little. SunJSSE doesn't call this ctor AFAICT. PKIX.java: 107 this.params = ((PKIXTimestampParameters) params).getPKIXBuilderParameters(); Shouldn't this be: this.params = (PKIXBuilderParameters) params; 201 Timestamp getTimestamp() { Can you rename this to timestamp() to be consistent with rest of classes methods that return params. CertConstraintParameters.java 44 // Timestamp of the JAR file from deploy s/JAR file from deploy/signed JAR file/ PKIXValidator.java Since Timestamp is a new supported parameter, can you update the javadoc of Validator.validate() to describe it? PKIXTimestampParameters.java - missing copyright and class description 30 public PKIXBuilderParameters getPKIXBuilderParameters() { Do you need this method? See above comment on line 107 of PKIX.java 44 public void setTimestampTrustAnchors(Set t) Does anyone call this method? Can it be removed? --Sean On 06/28/2016 05:17 PM, Anthony Scarpino wrote: > Hi, > > I need a review of the below code. It's a continuation of the previous > certpath related changes. Additional constraints checking on > timestamped jars being checked by the deploy code > > http://cr.openjdk.java.net/~ascarpino/8154015/webrev.01/ > > thanks > > Tony From anthony.scarpino at oracle.com Thu Jun 30 21:31:53 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 30 Jun 2016 14:31:53 -0700 Subject: RFR: 8154015 Apply algorithm constraints to timestamped code In-Reply-To: <57756C4B.3030701@oracle.com> References: <5772E956.4010305@oracle.com> <57756C4B.3030701@oracle.com> Message-ID: <57758FC9.9040507@oracle.com> Unless otherwise specified below, it was accepted.. http://cr.openjdk.java.net/~ascarpino/8154015/webrev.02/ Tony On 06/30/2016 12:00 PM, Sean Mullan wrote: > Just a few comments - > > AlgorithmChecker.java: > > 79 private Date pkixdate = null; > 81 private Timestamp jarTimestamp = null; > > These can be marked final I think. Bcause the below NPE issue, it make sense to make them final. I can't nest the constructors like I wanted to. > > 150 * {@code AlgorithmConstraints}. > > s/AlgorithmConstraints/Timestamp/ > > 153 * path for JAR files from deploy. > > Avoid using "from deploy". > > s/JAR files from deploy/signed JAR files that are timestamped./ > > 159 this(certPathDefaultConstraints, jarTimestamp.getTimestamp()); > > This will throw NPE if jarTimestamp is null. > > 177 public AlgorithmChecker(AlgorithmConstraints constraints, Date > pkixdate) { > > I think this should be private. You are only calling it within the > class. Also, the javadoc ctor description needs to be updated a little. > SunJSSE doesn't call this ctor AFAICT. Actually the whole constructor isn't needed because of the previous NPE possibility > > PKIX.java: > > 107 this.params = ((PKIXTimestampParameters) > params).getPKIXBuilderParameters(); > > Shouldn't this be: > > this.params = (PKIXBuilderParameters) params; The passed in params doesn't itself contain the original PKIXBuilderParamters data. It's the wrapper with an internal PKIXBuilderParameter object it holds the data. getPKIXBuilderParameters() passes the orignal PKIXBuilderParameters object. Without it being setup this way I don't see how I can get and set the timestamp. > > 201 Timestamp getTimestamp() { > > Can you rename this to timestamp() to be consistent with rest of classes > methods that return params. > > CertConstraintParameters.java > > 44 // Timestamp of the JAR file from deploy > > s/JAR file from deploy/signed JAR file/ > > PKIXValidator.java > > Since Timestamp is a new supported parameter, can you update the javadoc > of Validator.validate() to describe it? Yes it should. I didn't notice that > > PKIXTimestampParameters.java > > - missing copyright and class description > > 30 public PKIXBuilderParameters getPKIXBuilderParameters() { > > Do you need this method? See above comment on line 107 of PKIX.java See response in PKIX.. > > 44 public void setTimestampTrustAnchors(Set t) > > Does anyone call this method? Can it be removed? yes it can... > > --Sean > > On 06/28/2016 05:17 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of the below code. It's a continuation of the previous >> certpath related changes. Additional constraints checking on >> timestamped jars being checked by the deploy code >> >> http://cr.openjdk.java.net/~ascarpino/8154015/webrev.01/ >> >> thanks >> >> Tony