From hai-may.chao at oracle.com Tue Aug 4 18:28:35 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 4 Aug 2020 11:28:35 -0700 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: References: Message-ID: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> Hi Muneer, Looks good with one minor comment. #58: suggest that the SECURITY_WARNING will also include ?and is disabled? at the end to make it clear. Thanks, Hai-May > On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: > > Hi All, > > This is a new test int the area of jarsigner and keytool for the restricted/disabled algorithms. > > Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 > > Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ > > Description: > > Adding a test for key generation, jar signing and verification with all disabled algorithms and key sizes which are in the property jdk.jar.disabledAlgorithms. > Covered the scenario of with and without these disabled entries in jdk.jar.disabledAlgorithms. > > Whenever the entries are in the property jdk.jar.disabledAlgorithms, corresponding warning or error message should shown, otherwise everything should work fine without any related error or warning. > > This test covers all entries listed in "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, include jdk.disabled.namedCurves". In case of disabled curves, this test covers only one curve secp112r1. > > Tested in Linux, Windows and Mac Osx platforms and all are working fine. > > -Muneer > From mbalao at redhat.com Tue Aug 4 21:03:40 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 4 Aug 2020 18:03:40 -0300 Subject: RFR 8251117: Cannot check P11Key size in P11Cipher and P11AEADCipher Message-ID: <16045186-e1af-7962-78e0-1aca1dc2b9e8@redhat.com> Hi, I'd like to propose a fix for 8251117 [1], on behalf of Zdenek Zambersky (Red Hat employee - OCA signed). Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8251117/8251117.webrev.00/ As noted in the ticket [1], the fix is about using P11Key::length method for retrieving P11Key sizes when initializing P11Cipher and P11AEADCipher instances. By doing that, we avoid NullPointerExceptions that happens when the P11Key is CKA_SENSITIVE and cannot be extracted in plain (this is the case for NSS software token keys configured in FIPS mode). I found no regressions in sun/security/pkcs11 tests. I've also done manual testing in my NSS-FIPS environment. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8251117 From abdul.kolarkunnu at oracle.com Wed Aug 5 02:26:25 2020 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Wed, 5 Aug 2020 07:56:25 +0530 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> References: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> Message-ID: <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> Thanks Hai-May for review. Updated the webrev with your comment -http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.01/ -Muneer On 04/08/20 11:58 pm, Hai-May Chao wrote: > Hi Muneer, > > Looks good with one minor comment. > > #58: suggest that the SECURITY_WARNING will also include ?and is disabled? at the end to make it clear. > > Thanks, > Hai-May > >> On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: >> >> Hi All, >> >> This is a new test int the area of jarsigner and keytool for the restricted/disabled algorithms. >> >> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 >> >> Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ >> >> Description: >> >> Adding a test for key generation, jar signing and verification with all disabled algorithms and key sizes which are in the property jdk.jar.disabledAlgorithms. >> Covered the scenario of with and without these disabled entries in jdk.jar.disabledAlgorithms. >> >> Whenever the entries are in the property jdk.jar.disabledAlgorithms, corresponding warning or error message should shown, otherwise everything should work fine without any related error or warning. >> >> This test covers all entries listed in "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, include jdk.disabled.namedCurves". In case of disabled curves, this test covers only one curve secp112r1. >> >> Tested in Linux, Windows and Mac Osx platforms and all are working fine. >> >> -Muneer >> From hai-may.chao at oracle.com Wed Aug 5 03:13:58 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 4 Aug 2020 20:13:58 -0700 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> References: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> Message-ID: <67A4EDA0-C530-4334-949B-76E4D56FC387@oracle.com> Hi Muneer, Updated webrev looks good. Thanks, Hai-May > On Aug 4, 2020, at 7:26 PM, abdul.kolarkunnu at oracle.com wrote: > > Thanks Hai-May for review. > > Updated the webrev with your comment -http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.01/ > > -Muneer > > On 04/08/20 11:58 pm, Hai-May Chao wrote: >> Hi Muneer, >> >> Looks good with one minor comment. >> >> #58: suggest that the SECURITY_WARNING will also include ?and is disabled? at the end to make it clear. >> >> Thanks, >> Hai-May >> >>> On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: >>> >>> Hi All, >>> >>> This is a new test int the area of jarsigner and keytool for the restricted/disabled algorithms. >>> >>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 >>> >>> Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ >>> >>> Description: >>> >>> Adding a test for key generation, jar signing and verification with all disabled algorithms and key sizes which are in the property jdk.jar.disabledAlgorithms. >>> Covered the scenario of with and without these disabled entries in jdk.jar.disabledAlgorithms. >>> >>> Whenever the entries are in the property jdk.jar.disabledAlgorithms, corresponding warning or error message should shown, otherwise everything should work fine without any related error or warning. >>> >>> This test covers all entries listed in "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, include jdk.disabled.namedCurves". In case of disabled curves, this test covers only one curve secp112r1. >>> >>> Tested in Linux, Windows and Mac Osx platforms and all are working fine. >>> >>> -Muneer >>> From armin.schrenk at skymatic.de Thu Aug 6 10:09:27 2020 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Thu, 06 Aug 2020 12:09:27 +0200 Subject: Accessing windows key =?utf-8?q?store=3A?= Different provider than =?utf-8?q?SunMSCAPI=3F?==?utf-8?q?_=2F?= JDK-8251134 Message-ID: Hello, currently in one of our planned projects we intended to use private-public keypairs stored in the Windows key store to wrap/unwrap the actual content encryption keys. Unfortunately, this is not possible due to bug JDK-8251134 (https://bugs.openjdk.java.net/browse/JDK-8251134). My question is now, does another provider apart from the SunMSCAPI to read the windows key store exists? If not, can somebody point me somewhere (maybe another member of this list) to get further help? Microsoft started recently to contribute to the JDK, so perhaps they wrote the code to access CNG keys and can quickly solve the problem. Regards, Armin ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Aug 6 14:30:41 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 6 Aug 2020 10:30:41 -0400 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: <67A4EDA0-C530-4334-949B-76E4D56FC387@oracle.com> References: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> <67A4EDA0-C530-4334-949B-76E4D56FC387@oracle.com> Message-ID: <66c93335-3e0b-4b9e-31e0-e19377b23ab4@oracle.com> You should also add a test for MD2 and MD5 for the jarsigner -digestalg option. 125 private static void testJarsignerSiginig(String sigAlg, String alias) typo: s/Siginig/Signing/ All else looks fine. --Sean On 8/4/20 11:13 PM, Hai-May Chao wrote: > Hi Muneer, > > Updated webrev looks good. > > Thanks, > Hai-May > > >> On Aug 4, 2020, at 7:26 PM, abdul.kolarkunnu at oracle.com wrote: >> >> Thanks Hai-May for review. >> >> Updated the webrev with your comment -http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.01/ >> >> -Muneer >> >> On 04/08/20 11:58 pm, Hai-May Chao wrote: >>> Hi Muneer, >>> >>> Looks good with one minor comment. >>> >>> #58: suggest that the SECURITY_WARNING will also include ?and is disabled? at the end to make it clear. >>> >>> Thanks, >>> Hai-May >>> >>>> On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: >>>> >>>> Hi All, >>>> >>>> This is a new test int the area of jarsigner and keytool for the restricted/disabled algorithms. >>>> >>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 >>>> >>>> Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ >>>> >>>> Description: >>>> >>>> Adding a test for key generation, jar signing and verification with all disabled algorithms and key sizes which are in the property jdk.jar.disabledAlgorithms. >>>> Covered the scenario of with and without these disabled entries in jdk.jar.disabledAlgorithms. >>>> >>>> Whenever the entries are in the property jdk.jar.disabledAlgorithms, corresponding warning or error message should shown, otherwise everything should work fine without any related error or warning. >>>> >>>> This test covers all entries listed in "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, include jdk.disabled.namedCurves". In case of disabled curves, this test covers only one curve secp112r1. >>>> >>>> Tested in Linux, Windows and Mac Osx platforms and all are working fine. >>>> >>>> -Muneer >>>> > From abdul.kolarkunnu at oracle.com Fri Aug 7 09:04:01 2020 From: abdul.kolarkunnu at oracle.com (abdul.kolarkunnu at oracle.com) Date: Fri, 7 Aug 2020 14:34:01 +0530 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: <66c93335-3e0b-4b9e-31e0-e19377b23ab4@oracle.com> References: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> <67A4EDA0-C530-4334-949B-76E4D56FC387@oracle.com> <66c93335-3e0b-4b9e-31e0-e19377b23ab4@oracle.com> Message-ID: <75801aa2-2f94-aac3-d7bc-7f8dbba6bdc9@oracle.com> Thanks Sean for the review. Addressed your comments on? new webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.02/ -Muneer On 06/08/20 8:00 pm, Sean Mullan wrote: > You should also add a test for MD2 and MD5 for the jarsigner > -digestalg option. > > ?125???? private static void testJarsignerSiginig(String sigAlg, > String alias) > > typo: s/Siginig/Signing/ > > All else looks fine. > > --Sean > > On 8/4/20 11:13 PM, Hai-May Chao wrote: >> Hi Muneer, >> >> Updated webrev looks good. >> >> Thanks, >> Hai-May >> >> >>> On Aug 4, 2020, at 7:26 PM, abdul.kolarkunnu at oracle.com wrote: >>> >>> Thanks Hai-May for review. >>> >>> Updated the webrev with your comment >>> -http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.01/ >>> >>> -Muneer >>> >>> On 04/08/20 11:58 pm, Hai-May Chao wrote: >>>> Hi Muneer, >>>> >>>> Looks good with one minor comment. >>>> >>>> #58: suggest that the SECURITY_WARNING will also include ?and is >>>> disabled? at the end to make it clear. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>>> On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: >>>>> >>>>> Hi All, >>>>> >>>>> This is a new test int the area of jarsigner and keytool for the >>>>> restricted/disabled algorithms. >>>>> >>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 >>>>> >>>>> Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ >>>>> >>>>> Description: >>>>> >>>>> Adding a test for key generation, jar signing and verification >>>>> with all disabled algorithms and key sizes which are in the >>>>> property jdk.jar.disabledAlgorithms. >>>>> Covered the scenario of with and without these disabled entries in >>>>> jdk.jar.disabledAlgorithms. >>>>> >>>>> Whenever the entries are in the property >>>>> jdk.jar.disabledAlgorithms, corresponding warning or error message >>>>> should shown, otherwise everything should work fine without any >>>>> related error or warning. >>>>> >>>>> This test covers all entries listed in >>>>> "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA >>>>> keySize < 1024, include jdk.disabled.namedCurves". In case of >>>>> disabled curves, this test covers only one curve secp112r1. >>>>> >>>>> Tested in Linux, Windows and Mac Osx platforms and all are working >>>>> fine. >>>>> >>>>> -Muneer >>>>> >> From norman.maurer at googlemail.com Fri Aug 7 12:00:56 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 7 Aug 2020 14:00:56 +0200 Subject: "Blocking operation" during SSLEngineImpl.unwrap() Message-ID: Hi there, In netty we support using BlockHound[1] to detect if people do blocking operations within the EventLoop and so notify them that this should not be done. While running our integration tests with TLS1.3 we noticed that unwrap(?) may trigger an FileInputStream.read(?) which in theory could block for a long time. I was assuming that such an operation should only be done after SSLEngine.* returns NEED_TASK and so be delegated to another ThreadPool via getTask(). Now the question(s): * Is my assumption incorrect ? * If my assumption is correct should we fix this ? Here is the stack trace when such a blocking call is detected: reactor.blockhound.BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes at java.base/java.io.FileInputStream.readBytes(FileInputStream.java) at java.base/java.io.FileInputStream.read(FileInputStream.java:273) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424) at java.base/sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526) at java.base/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545) at java.base/sun.security.provider.NativePRNG$NonBlocking.engineNextBytes(NativePRNG.java:318) at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:741) at java.base/sun.security.ssl.RandomCookie.(RandomCookie.java:67) at java.base/sun.security.ssl.SessionId.(SessionId.java:45) at java.base/sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:225) at java.base/sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1100) at java.base/sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:867) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:418) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433) at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634) at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282) at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380) at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275) at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322) [1] https://github.com/reactor/BlockHound -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Aug 7 14:01:30 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Aug 2020 10:01:30 -0400 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects Message-ID: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> Please review this change to deprecate the following APIs: java.security.cert.X509Certificate.getIssuerDN() java.security.cert.X509Certificate.getSubjectDN() java.security.cert.X509CRL.getIssuerDN() java.security.cert.X509CertSelector.setIssuer(String) java.security.cert.X509CertSelector.setSubject(String) java.security.cert.X509CertSelector.getIssuerAsString() java.security.cert.X509CertSelector.getSubjectAsString() java.security.cert.X509CRLSelector.addIssuerName(String) These APIs either take or return Distinguished Names as Principal or String objects which can cause issues due to loss of encoding information or differences when comparing names across different Principal implementations. All of them have alternative APIs which use X500Principal objects instead. They have long had warnings in the javadoc and have been discouraged from being used. There are no plans to remove the APIs at this time, as they have been in the platform for a long time and removing them would be a much higher compatibility risk. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 bug: https://bugs.openjdk.java.net/browse/JDK-8241003 --Sean From xuelei.fan at oracle.com Fri Aug 7 15:00:20 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Aug 2020 08:00:20 -0700 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: References: Message-ID: Hm, it's an interesting bug. I filed the issue on the Java Bug System. https://bugs.openjdk.java.net/browse/JDK-8251304 Thanks, Xuelei On 8/7/2020 5:00 AM, Norman Maurer wrote: > Hi there, > > In netty we support using BlockHound[1] to detect if people do blocking > operations within the EventLoop and so notify them that this should not > be done. While running our integration tests with TLS1.3 we noticed that > unwrap(?) may trigger an FileInputStream.read(?) which in theory could > block for a long time. I was assuming that such an operation should only > be done after SSLEngine.* returns NEED_TASK and so be delegated to > another ThreadPool via getTask(). > > Now the question(s): > > * Is my assumption incorrect ? > * If my assumption is correct should we fix this ? > > Here is the stack trace when such a blocking call is detected: > > reactor.blockhound.BlockingOperationError: Blocking call! > java.io.FileInputStream#readBytes > at java.base/java.io.FileInputStream.readBytes(FileInputStream.java) > at java.base/java.io.FileInputStream.read(FileInputStream.java:273) > at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) > at > java.base/sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424) > at > java.base/sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526) > at > java.base/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545) > at > java.base/sun.security.provider.NativePRNG$NonBlocking.engineNextBytes(NativePRNG.java:318) > at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:741) > at java.base/sun.security.ssl.RandomCookie.(RandomCookie.java:67) > at java.base/sun.security.ssl.SessionId.(SessionId.java:45) > at > java.base/sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:225) > at > java.base/sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1100) > at > java.base/sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:867) > at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > at > java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) > at > java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:418) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) > at > java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) > at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433) > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634) > at > io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282) > at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380) > at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275) > at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322) > > [1] https://github.com/reactor/BlockHound From norman.maurer at googlemail.com Fri Aug 7 15:02:27 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 7 Aug 2020 17:02:27 +0200 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: References: Message-ID: Thanks a lot? So seems like my assumption is correct then :) Bye Norman > On 7. Aug 2020, at 17:00, Xuelei Fan wrote: > > Hm, it's an interesting bug. I filed the issue on the Java Bug System. > https://bugs.openjdk.java.net/browse/JDK-8251304 > > Thanks, > Xuelei > > On 8/7/2020 5:00 AM, Norman Maurer wrote: >> Hi there, >> In netty we support using BlockHound[1] to detect if people do blocking operations within the EventLoop and so notify them that this should not be done. While running our integration tests with TLS1.3 we noticed that unwrap(?) may trigger an FileInputStream.read(?) which in theory could block for a long time. I was assuming that such an operation should only be done after SSLEngine.* returns NEED_TASK and so be delegated to another ThreadPool via getTask(). >> Now the question(s): >> * Is my assumption incorrect ? >> * If my assumption is correct should we fix this ? >> Here is the stack trace when such a blocking call is detected: >> reactor.blockhound.BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes >> at java.base/java.io.FileInputStream.readBytes(FileInputStream.java) >> at java.base/java.io.FileInputStream.read(FileInputStream.java:273) >> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) >> at java.base/sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424) >> at java.base/sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526) >> at java.base/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545) >> at java.base/sun.security.provider.NativePRNG$NonBlocking.engineNextBytes(NativePRNG.java:318) >> at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:741) >> at java.base/sun.security.ssl.RandomCookie.(RandomCookie.java:67) >> at java.base/sun.security.ssl.SessionId.(SessionId.java:45) >> at java.base/sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:225) >> at java.base/sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1100) >> at java.base/sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:867) >> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) >> at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:418) >> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) >> at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) >> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) >> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433) >> at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634) >> at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282) >> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380) >> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275) >> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322) >> [1] https://github.com/reactor/BlockHound From Alan.Bateman at oracle.com Fri Aug 7 16:13:16 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Aug 2020 17:13:16 +0100 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: References: Message-ID: On 07/08/2020 16:00, Xuelei Fan wrote: > Hm, it's an interesting bug.? I filed the issue on the Java Bug System. > ?? https://bugs.openjdk.java.net/browse/JDK-8251304 It is a bug that a new random cookie is needed or it has from read from /dev/urandom? I don't think the stack trace is enough to know if read is really blocked. -Alan From norman.maurer at googlemail.com Fri Aug 7 16:16:21 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 7 Aug 2020 18:16:21 +0200 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: References: Message-ID: I think the possibility that it may block should be enough to signal and so offload to a task. If it never blocks then it?s not a bug... that?s why I asked the question in the first place . Bye Norman > Am 07.08.2020 um 18:13 schrieb Alan Bateman : > > ?On 07/08/2020 16:00, Xuelei Fan wrote: >> Hm, it's an interesting bug. I filed the issue on the Java Bug System. >> https://bugs.openjdk.java.net/browse/JDK-8251304 > It is a bug that a new random cookie is needed or it has from read from /dev/urandom? I don't think the stack trace is enough to know if read is really blocked. > > -Alan From sean.mullan at oracle.com Fri Aug 7 16:53:03 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Aug 2020 12:53:03 -0400 Subject: RFR [16] [JDK-8248745] Add jarsigner and keytool tests for restricted algorithms In-Reply-To: <75801aa2-2f94-aac3-d7bc-7f8dbba6bdc9@oracle.com> References: <40A0F96A-6959-46FC-AC8E-6F2744B9427D@oracle.com> <27f1a095-1849-5f5e-1bcb-d63a73058ac0@oracle.com> <67A4EDA0-C530-4334-949B-76E4D56FC387@oracle.com> <66c93335-3e0b-4b9e-31e0-e19377b23ab4@oracle.com> <75801aa2-2f94-aac3-d7bc-7f8dbba6bdc9@oracle.com> Message-ID: Looks good. --Sean On 8/7/20 5:04 AM, abdul.kolarkunnu at oracle.com wrote: > Thanks Sean for the review. > > Addressed your comments on? new webrev - > http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.02/ > > -Muneer > > On 06/08/20 8:00 pm, Sean Mullan wrote: >> You should also add a test for MD2 and MD5 for the jarsigner >> -digestalg option. >> >> ?125???? private static void testJarsignerSiginig(String sigAlg, >> String alias) >> >> typo: s/Siginig/Signing/ >> >> All else looks fine. >> >> --Sean >> >> On 8/4/20 11:13 PM, Hai-May Chao wrote: >>> Hi Muneer, >>> >>> Updated webrev looks good. >>> >>> Thanks, >>> Hai-May >>> >>> >>>> On Aug 4, 2020, at 7:26 PM, abdul.kolarkunnu at oracle.com wrote: >>>> >>>> Thanks Hai-May for review. >>>> >>>> Updated the webrev with your comment >>>> -http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.01/ >>>> >>>> -Muneer >>>> >>>> On 04/08/20 11:58 pm, Hai-May Chao wrote: >>>>> Hi Muneer, >>>>> >>>>> Looks good with one minor comment. >>>>> >>>>> #58: suggest that the SECURITY_WARNING will also include ?and is >>>>> disabled? at the end to make it clear. >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>>> On Jul 27, 2020, at 9:15 AM, abdul.kolarkunnu at oracle.com wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> This is a new test int the area of jarsigner and keytool for the >>>>>> restricted/disabled algorithms. >>>>>> >>>>>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8248745 >>>>>> >>>>>> Webrev - http://cr.openjdk.java.net/~akolarkunnu/8248745/webrev.00/ >>>>>> >>>>>> Description: >>>>>> >>>>>> Adding a test for key generation, jar signing and verification >>>>>> with all disabled algorithms and key sizes which are in the >>>>>> property jdk.jar.disabledAlgorithms. >>>>>> Covered the scenario of with and without these disabled entries in >>>>>> jdk.jar.disabledAlgorithms. >>>>>> >>>>>> Whenever the entries are in the property >>>>>> jdk.jar.disabledAlgorithms, corresponding warning or error message >>>>>> should shown, otherwise everything should work fine without any >>>>>> related error or warning. >>>>>> >>>>>> This test covers all entries listed in >>>>>> "jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA >>>>>> keySize < 1024, include jdk.disabled.namedCurves". In case of >>>>>> disabled curves, this test covers only one curve secp112r1. >>>>>> >>>>>> Tested in Linux, Windows and Mac Osx platforms and all are working >>>>>> fine. >>>>>> >>>>>> -Muneer >>>>>> >>> From anthony.scarpino at oracle.com Fri Aug 7 17:27:09 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 7 Aug 2020 10:27:09 -0700 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: References: Message-ID: <1748e9a9-5cf7-d014-7725-4194a99ce902@oracle.com> Well if there were a bug it's with NativePRNG as the operation is suppose to be non-blocking. Even so, /dev/urandom is nonblocking. The only reason this looks to have been detected by the tool is because it's a blocking read op. This all seems like an extremely unlikely situation. I don't see this as something SSLEngine should be compensating for. Tony On 8/7/20 9:16 AM, Norman Maurer wrote: > I think the possibility that it may block should be enough to signal and so offload to a task. > > If it never blocks then it?s not a bug... that?s why I asked the question in the first place . > > Bye > Norman >> Am 07.08.2020 um 18:13 schrieb Alan Bateman : >> >> ?On 07/08/2020 16:00, Xuelei Fan wrote: >>> Hm, it's an interesting bug. I filed the issue on the Java Bug System. >>> https://bugs.openjdk.java.net/browse/JDK-8251304 >> It is a bug that a new random cookie is needed or it has from read from /dev/urandom? I don't think the stack trace is enough to know if read is really blocked. >> >> -Alan From Alan.Bateman at oracle.com Fri Aug 7 18:24:11 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Aug 2020 19:24:11 +0100 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: <1748e9a9-5cf7-d014-7725-4194a99ce902@oracle.com> References: <1748e9a9-5cf7-d014-7725-4194a99ce902@oracle.com> Message-ID: <42e2e845-4f5b-bf93-a91f-047c22a47043@oracle.com> On 07/08/2020 18:27, Anthony Scarpino wrote: > Well if there were a bug it's with NativePRNG as the operation is > suppose to be non-blocking.? Even so, /dev/urandom is nonblocking.? > The only reason this looks to have been detected by the tool is > because it's a blocking read op.? This all seems like an extremely > unlikely situation.? I don't see this as something SSLEngine should be > compensating for. Right, /dev/random is blocking, /dev/urandom is non-blocking. I just checked BlockHound and it seems to have the names of private methods in the java.io and java.net classes and I think instruments these methods on the assumption that they are blocking calls. The list seems to have been generated from an older JDK too, not really in sync with release JDK releases. So not clear to me that there is really an issue here. -Alan From valerie.peng at oracle.com Fri Aug 7 21:30:02 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 7 Aug 2020 14:30:02 -0700 Subject: RFR 8251117: Cannot check P11Key size in P11Cipher and P11AEADCipher In-Reply-To: <16045186-e1af-7962-78e0-1aca1dc2b9e8@redhat.com> References: <16045186-e1af-7962-78e0-1aca1dc2b9e8@redhat.com> Message-ID: <0154c412-121f-8fb3-9b54-bfa61fce03a1@oracle.com> Sure, looks fine to me as well. Thanks, Valerie On 8/4/2020 2:03 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for 8251117 [1], on behalf of Zdenek Zambersky > (Red Hat employee - OCA signed). > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8251117/8251117.webrev.00/ > > As noted in the ticket [1], the fix is about using P11Key::length method > for retrieving P11Key sizes when initializing P11Cipher and > P11AEADCipher instances. By doing that, we avoid NullPointerExceptions > that happens when the P11Key is CKA_SENSITIVE and cannot be extracted in > plain (this is the case for NSS software token keys configured in FIPS > mode). > > I found no regressions in sun/security/pkcs11 tests. I've also done > manual testing in my NSS-FIPS environment. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8251117 > From ecki at zusammenkunft.net Tue Aug 11 00:49:06 2020 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 11 Aug 2020 02:49:06 +0200 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com Message-ID: Hallo, is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting to https://www.google.com? I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked). javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]", "compression methods" : "00", "extensions" : [ "server_name (0)": { type=host_name (0), value=www.google.com }, "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "supported_versions (43)": { "versions": [TLSv1.3] }, "psk_key_exchange_modes (45)": { "ke_modes": [psk_dhe_ke] }, "key_share (51)": { "client_shares": [ { "named group": secp256r1 "key_exchange": { 0000: 04 A4 C2 58 EF 8B 62 3D 47 C4 21 FE 7D 4A 85 2B ...X..b=G.!..J.+ 0010: AE 99 7D 3C 30 08 F4 00 F3 B0 A9 17 DE 0E B1 16 ...<0........... 0020: 0D 45 46 87 42 B0 83 68 FB 15 E9 79 D2 40 8C DA .EF.B..h...y. at .. 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 8.vR.@ ...9u.y... 0040: E1 } }, ] } ] } ) ... javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message ( "Alert": { "level" : "fatal", "description": "protocol_version" } ) Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Aug 11 01:11:14 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 10 Aug 2020 18:11:14 -0700 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: References: Message-ID: <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360.? What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true?? That should get you past it.? This is mentioned in the release notes for 8u261: https://www.oracle.com/java/technologies/javase/8u261-relnotes.html --Jamil On 8/10/2020 5:49 PM, Bernd wrote: > Hallo, > > is the upcoming Java8u?TLS backport supposed to work with > "-Djdk.tls.client.protocols=TLSv1.3" when connecting to > https://www.google.com? > > I get an alert when I try to HttpsURLConnection.open to it. This > happens with the Zulu port of this feature as well as the 8u261GA from > Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. > > The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, > it does handshake correctly with Google (so only difference i can see > is an additional OCSP request and chacha cipher which is not picked). > > javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 > CEST|Logger.java:765|Produced ClientHello handshake message ( > "ClientHello": { > ? "client version"? ? ? : "TLSv1.2", > ? "random"? ? ? ? ? ? ? : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 > 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", > ? "session id"? ? ? ? ? : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 > 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", > ? "cipher suites"? ? ? ?: "[TLS_AES_128_GCM_SHA256(0x1301), > TLS_AES_256_GCM_SHA384(0x1302)]", > ? "compression methods" : "00", > ? "extensions"? ? ? ? ? : [ > ? ? "server_name (0)": { > ? ? ? type=host_name (0), value=www.google.com > ? ? }, > ? ? "supported_groups (10)": { > ? ? ? "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, > ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] > ? ? }, > ? ? "signature_algorithms (13)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] > ? ? }, > "signature_algorithms_cert (50)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] > ? ? }, > ? ? "supported_versions (43)": { > ? ? ? "versions": [TLSv1.3] > ? ? }, > ? ? "psk_key_exchange_modes (45)": { > ? ? ? "ke_modes": [psk_dhe_ke] > ? ? }, > ? ? "key_share (51)": { > ? ? ? "client_shares": [ > ? ? ? ? { > ? ? ? ? ? "named group": secp256r1 > ? ? ? ? ? "key_exchange": { > ? ? ? ? ? ? 0000: 04 A4 C2 58 EF 8B 62 3D? ?47 C4 21 FE 7D 4A 85 2B > ...X..b=G.!..J.+ > ? ? ? ? ? ? 0010: AE 99 7D 3C 30 08 F4 00? ?F3 B0 A9 17 DE 0E B1 16 > ...<0........... > ? ? ? ? ? ? 0020: 0D 45 46 87 42 B0 83 68? ?FB 15 E9 79 D2 40 8C DA > .EF.B..h...y. at .. > ? ? ? ? ? ? 0030: 38 FF 76 52 1D 40 10 A0? ?BE 39 75 8B 79 F0 CD A1 > 8.vR. at ...9u.y... > ? ? ? ? ? ? 0040: E1 > ? ? ? ? ? } > ? ? ? ? }, > ? ? ? ] > ? ? } > ? ] > } > ) > ... > javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 > CEST|Logger.java:765|Received alert message ( > "Alert": { > ? "level"? ? ? : "fatal", > ? "description": "protocol_version" > } > ) > > > > Gruss > Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Tue Aug 11 02:10:54 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 11 Aug 2020 02:10:54 +0000 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> References: , <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> Message-ID: Hello Jamil, Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension is sent in ClientHello. I naturally disabled it and I can see in the debug log that the extension is no longer requested - HOWEVER the handshake with google.com still succeeds with OpenJSSE. WAT? :) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Jamil Nimeh Gesendet: Tuesday, August 11, 2020 3:11:14 AM An: security-dev at openjdk.java.net Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360. What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true? That should get you past it. This is mentioned in the release notes for 8u261: https://www.oracle.com/java/technologies/javase/8u261-relnotes.html --Jamil On 8/10/2020 5:49 PM, Bernd wrote: Hallo, is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting to https://www.google.com? I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked). javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]", "compression methods" : "00", "extensions" : [ "server_name (0)": { type=host_name (0), value=www.google.com }, "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "supported_versions (43)": { "versions": [TLSv1.3] }, "psk_key_exchange_modes (45)": { "ke_modes": [psk_dhe_ke] }, "key_share (51)": { "client_shares": [ { "named group": secp256r1 "key_exchange": { 0000: 04 A4 C2 58 EF 8B 62 3D 47 C4 21 FE 7D 4A 85 2B ...X..b=G.!..J.+ 0010: AE 99 7D 3C 30 08 F4 00 F3 B0 A9 17 DE 0E B1 16 ...<0........... 0020: 0D 45 46 87 42 B0 83 68 FB 15 E9 79 D2 40 8C DA .EF.B..h...y. at .. 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 8.vR. at ...9u.y... 0040: E1 } }, ] } ] } ) ... javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message ( "Alert": { "level" : "fatal", "description": "protocol_version" } ) Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Tue Aug 11 02:18:43 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 11 Aug 2020 02:18:43 +0000 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: References: , <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com>, Message-ID: Jamil, just a folllw up, I noticed in the bug comets that there are multiple conditions where boringSSL fails, seems like OpenJSSE somehow does not trigger the fingerprint match w/ and w/o status request. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Bernd Eckenfels Gesendet: Tuesday, August 11, 2020 4:10:54 AM An: Jamil Nimeh ; security-dev at openjdk.java.net Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com Hello Jamil, Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension is sent in ClientHello. I naturally disabled it and I can see in the debug log that the extension is no longer requested - HOWEVER the handshake with google.com still succeeds with OpenJSSE. WAT? :) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Jamil Nimeh Gesendet: Tuesday, August 11, 2020 3:11:14 AM An: security-dev at openjdk.java.net Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360. What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true? That should get you past it. This is mentioned in the release notes for 8u261: https://www.oracle.com/java/technologies/javase/8u261-relnotes.html --Jamil On 8/10/2020 5:49 PM, Bernd wrote: Hallo, is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting to https://www.google.com? I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked). javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]", "compression methods" : "00", "extensions" : [ "server_name (0)": { type=host_name (0), value=www.google.com }, "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] }, "supported_versions (43)": { "versions": [TLSv1.3] }, "psk_key_exchange_modes (45)": { "ke_modes": [psk_dhe_ke] }, "key_share (51)": { "client_shares": [ { "named group": secp256r1 "key_exchange": { 0000: 04 A4 C2 58 EF 8B 62 3D 47 C4 21 FE 7D 4A 85 2B ...X..b=G.!..J.+ 0010: AE 99 7D 3C 30 08 F4 00 F3 B0 A9 17 DE 0E B1 16 ...<0........... 0020: 0D 45 46 87 42 B0 83 68 FB 15 E9 79 D2 40 8C DA .EF.B..h...y. at .. 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 8.vR. at ...9u.y... 0040: E1 } }, ] } ] } ) ... javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message ( "Alert": { "level" : "fatal", "description": "protocol_version" } ) Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Aug 11 02:23:32 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 10 Aug 2020 19:23:32 -0700 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: References: <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> Message-ID: <61f0cd6a-196f-526c-185c-d56092b71b5f@oracle.com> Hi Bernd, Without seeing the respective traces it is hard to know for certain, but I can tell you that BoringSSL looks for a specific "fingerprint" in the client hello which it attributes to the original JDK 11 client hello.? They did this to work around specific bugs in the initial TLS 1.3 implementation released with JDK 11. If the client hello is structured such that it doesn't match the fingerprint then things proceed with no issues.? There are many ways to change the fingerprint.? It can even be accomplished by using the identical set of extensions that cause the failure, but ordering them differently.? I had more than a few "WAT?" moments getting my head around that when we were characterizing this issue back in April.? :) If we were to look at the client hellos from that Zulu OpenJSSE provider, I'm sure we could identify the element that changes the fingerprint such that it works. --Jamil On 8/10/2020 7:10 PM, Bernd Eckenfels wrote: > Hello Jamil, > > Thanks for responding, you are correct, this system property resolves > my problem (on both the Oracle as well as Azure JRE). > > There is however something fishy going on. With the OpenJSSE provider > (as provided by Zulu) the default for this option seems to be =true, > as the extension is sent in ClientHello. I naturally disabled it and I > can see in the debug log that the extension is no longer requested - > HOWEVER the handshake with google.com still succeeds with OpenJSSE. > WAT? :) > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Jamil Nimeh > *Gesendet:* Tuesday, August 11, 2020 3:11:14 AM > *An:* security-dev at openjdk.java.net > *Betreff:* Re: [TLS-backport8] Does TLSv1.3 work with www.google.com > > Hmmm, looks a lot like this issue: > https://bugs.openjdk.java.net/browse/JDK-8241360 > .? What happens if > you run it with -Djdk.tls.client.enableStatusRequestExtension=true?? > That should get you past it.? This is mentioned in the release notes > for 8u261: > > https://www.oracle.com/java/technologies/javase/8u261-relnotes.html > > --Jamil > > On 8/10/2020 5:49 PM, Bernd wrote: >> Hallo, >> >> is the upcoming Java8u?TLS backport supposed to work with >> "-Djdk.tls.client.protocols=TLSv1.3" when connecting to >> https://www.google.com? >> >> I get an alert when I try to HttpsURLConnection.open to it. This >> happens with the Zulu port of this feature as well as the 8u261GA >> from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a >> v2 cipher. >> >> The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, >> it does handshake correctly with Google (so only difference i can see >> is an additional OCSP request and chacha cipher which is not picked). >> >> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 >> CEST|Logger.java:765|Produced ClientHello handshake message ( >> "ClientHello": { >> ? "client version" : "TLSv1.2", >> ? "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 >> 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", >> ? "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 >> 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", >> ? "cipher suites" ?: "[TLS_AES_128_GCM_SHA256(0x1301), >> TLS_AES_256_GCM_SHA384(0x1302)]", >> ? "compression methods" : "00", >> ? "extensions" : [ >> ? ? "server_name (0)": { >> ? ? ? type=host_name (0), value=www.google.com >> ? ? }, >> ? ? "supported_groups (10)": { >> ? ? ? "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, >> ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >> ? ? }, >> "signature_algorithms (13)": { >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, >> rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >> ? ? }, >> "signature_algorithms_cert (50)": { >> ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, >> ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, >> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, >> rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >> ? ? }, >> ? ? "supported_versions (43)": { >> ? ? ? "versions": [TLSv1.3] >> ? ? }, >> "psk_key_exchange_modes (45)": { >> ? ? ? "ke_modes": [psk_dhe_ke] >> ? ? }, >> ? ? "key_share (51)": { >> ? ? ? "client_shares": [ >> ? ? ? ? { >> ? ? ? ? ? "named group": secp256r1 >> "key_exchange": { >> ? ? ? ? ? ? 0000: 04 A4 C2 58 EF 8B 62 3D? ?47 C4 21 FE 7D 4A 85 2B >> ...X..b=G.!..J.+ >> ? ? ? ? ? ? 0010: AE 99 7D 3C 30 08 F4 00? ?F3 B0 A9 17 DE 0E B1 16 >> ...<0........... >> ? ? ? ? ? ? 0020: 0D 45 46 87 42 B0 83 68? ?FB 15 E9 79 D2 40 8C DA >> .EF.B..h...y. at .. >> ? ? ? ? ? ? 0030: 38 FF 76 52 1D 40 10 A0? ?BE 39 75 8B 79 F0 CD A1 >> 8.vR. at ...9u.y ... >> ? ? ? ? ? ? 0040: E1 >> ? ? ? ? ? } >> ? ? ? ? }, >> ? ? ? ] >> ? ? } >> ? ] >> } >> ) >> ... >> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 >> CEST|Logger.java:765|Received alert message ( >> "Alert": { >> ? "level"? ? ? : "fatal", >> ? "description": "protocol_version" >> } >> ) >> >> >> >> Gruss >> Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Tue Aug 11 06:48:06 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 11 Aug 2020 08:48:06 +0200 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: <61f0cd6a-196f-526c-185c-d56092b71b5f@oracle.com> References: <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> <61f0cd6a-196f-526c-185c-d56092b71b5f@oracle.com> Message-ID: Just FTW I think they still enable the TLS1.3 detection logic via their BoringSSL usage just like others noted: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_jdk11_workaround Bye Norman > On 11. Aug 2020, at 04:23, Jamil Nimeh wrote: > > Hi Bernd, > > Without seeing the respective traces it is hard to know for certain, but I can tell you that BoringSSL looks for a specific "fingerprint" in the client hello which it attributes to the original JDK 11 client hello. They did this to work around specific bugs in the initial TLS 1.3 implementation released with JDK 11. > > If the client hello is structured such that it doesn't match the fingerprint then things proceed with no issues. There are many ways to change the fingerprint. It can even be accomplished by using the identical set of extensions that cause the failure, but ordering them differently. I had more than a few "WAT?" moments getting my head around that when we were characterizing this issue back in April. :) > > If we were to look at the client hellos from that Zulu OpenJSSE provider, I'm sure we could identify the element that changes the fingerprint such that it works. > > --Jamil > > On 8/10/2020 7:10 PM, Bernd Eckenfels wrote: >> Hello Jamil, >> >> Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). >> >> There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension is sent in ClientHello. I naturally disabled it and I can see in the debug log that the extension is no longer requested - HOWEVER the handshake with google.com still succeeds with OpenJSSE. WAT? :) >> >> Gruss >> Bernd >> >> >> -- >> http://bernd.eckenfels.net >> Von: security-dev im Auftrag von Jamil Nimeh >> Gesendet: Tuesday, August 11, 2020 3:11:14 AM >> An: security-dev at openjdk.java.net >> Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com >> >> Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360 . What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true? That should get you past it. This is mentioned in the release notes for 8u261: >> >> https://www.oracle.com/java/technologies/javase/8u261-relnotes.html >> --Jamil >> >> On 8/10/2020 5:49 PM, Bernd wrote: >>> Hallo, >>> >>> is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting tohttps://www.google.com ? >>> >>> I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. >>> >>> The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked). >>> >>> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message ( >>> "ClientHello": { >>> "client version" : "TLSv1.2", >>> "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", >>> "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", >>> "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]", >>> "compression methods" : "00", >>> "extensions" : [ >>> "server_name (0)": { >>> type=host_name (0), value=www.google.com >>> }, >>> "supported_groups (10)": { >>> "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >>> }, >>> "signature_algorithms (13)": { >>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >>> }, >>> "signature_algorithms_cert (50)": { >>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >>> }, >>> "supported_versions (43)": { >>> "versions": [TLSv1.3] >>> }, >>> "psk_key_exchange_modes (45)": { >>> "ke_modes": [psk_dhe_ke] >>> }, >>> "key_share (51)": { >>> "client_shares": [ >>> { >>> "named group": secp256r1 >>> "key_exchange": { >>> 0000: 04 A4 C2 58 EF 8B 62 3D 47 C4 21 FE 7D 4A 85 2B ...X..b=G.!..J.+ >>> 0010: AE 99 7D 3C 30 08 F4 00 F3 B0 A9 17 DE 0E B1 16 ...<0........... >>> 0020: 0D 45 46 87 42 B0 83 68 FB 15 E9 79 D2 40 8C DA .EF.B..h...y. at .. >>> 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 8.vR. at ...9u.y ... >>> 0040: E1 >>> } >>> }, >>> ] >>> } >>> ] >>> } >>> ) >>> ... >>> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message ( >>> "Alert": { >>> "level" : "fatal", >>> "description": "protocol_version" >>> } >>> ) >>> >>> >>> >>> Gruss >>> Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Tue Aug 11 10:45:53 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 11 Aug 2020 10:45:53 +0000 Subject: [TLS-backport8] Does TLSv1.3 work with www.google.com In-Reply-To: References: <80f73b5a-82b7-ffaa-b3b5-e4c47174ed05@oracle.com> Message-ID: <3FD675A6-2284-4C64-B724-A74D3101296A@azul.com> Hello Bernd, The difference between Java8u TLSv1.3 backport and OpenJSSE is TLS_CHACHA20_POLY1305_SHA256 cipher suite support. I've found, that connection to google.com succeeds in case of ClientHello includes Chacha20-Poly1305 in the list of supported cipher suites, even if status request is disabled. Jdk11 and Java8u TLSv1.3 backport does not support ChaCha20-Poly1305 cipher suites, so connection fails w/o status request. Regards Alexey > On 11 Aug 2020, at 05:18, Bernd Eckenfels wrote: > > Jamil, just a folllw up, I noticed in the bug comets that there are multiple conditions where boringSSL fails, seems like OpenJSSE somehow does not trigger the fingerprint match w/ and w/o status request. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > Von: Bernd Eckenfels > Gesendet: Tuesday, August 11, 2020 4:10:54 AM > An: Jamil Nimeh ; security-dev at openjdk.java.net > Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com > > Hello Jamil, > > Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). > > There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension is sent in ClientHello. I naturally disabled it and I can see in the debug log that the extension is no longer requested - HOWEVER the handshake with google.com still succeeds with OpenJSSE. WAT? :) > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > Von: security-dev im Auftrag von Jamil Nimeh > Gesendet: Tuesday, August 11, 2020 3:11:14 AM > An: security-dev at openjdk.java.net > Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com > > Hmmm, looks a lot like this issue: https://bugs.openjdk.java.net/browse/JDK-8241360. What happens if you run it with -Djdk.tls.client.enableStatusRequestExtension=true? That should get you past it. This is mentioned in the release notes for 8u261: > > https://www.oracle.com/java/technologies/javase/8u261-relnotes.html > > --Jamil > > On 8/10/2020 5:49 PM, Bernd wrote: >> Hallo, >> >> is the upcoming Java8u TLS backport supposed to work with "-Djdk.tls.client.protocols=TLSv1.3" when connecting to https://www.google.com? >> >> I get an alert when I try to HttpsURLConnection.open to it. This happens with the Zulu port of this feature as well as the 8u261GA from Oracle. When specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher. >> >> The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it does handshake correctly with Google (so only difference i can see is an additional OCSP request and chacha cipher which is not picked). >> >> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 CEST|Logger.java:765|Produced ClientHello handshake message ( >> "ClientHello": { >> "client version" : "TLSv1.2", >> "random" : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1", >> "session id" : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8", >> "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302)]", >> "compression methods" : "00", >> "extensions" : [ >> "server_name (0)": { >> type=host_name (0), value=www.google.com >> }, >> "supported_groups (10)": { >> "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >> }, >> "signature_algorithms (13)": { >> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >> }, >> "signature_algorithms_cert (50)": { >> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1] >> }, >> "supported_versions (43)": { >> "versions": [TLSv1.3] >> }, >> "psk_key_exchange_modes (45)": { >> "ke_modes": [psk_dhe_ke] >> }, >> "key_share (51)": { >> "client_shares": [ >> { >> "named group": secp256r1 >> "key_exchange": { >> 0000: 04 A4 C2 58 EF 8B 62 3D 47 C4 21 FE 7D 4A 85 2B ...X..b=G.!..J.+ >> 0010: AE 99 7D 3C 30 08 F4 00 F3 B0 A9 17 DE 0E B1 16 ...<0........... >> 0020: 0D 45 46 87 42 B0 83 68 FB 15 E9 79 D2 40 8C DA .EF.B..h...y. at .. >> 0030: 38 FF 76 52 1D 40 10 A0 BE 39 75 8B 79 F0 CD A1 8.vR. at ...9u.y... >> 0040: E1 >> } >> }, >> ] >> } >> ] >> } >> ) >> ... >> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.288 CEST|Logger.java:765|Received alert message ( >> "Alert": { >> "level" : "fatal", >> "description": "protocol_version" >> } >> ) >> >> >> >> Gruss >> Bernd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Tue Aug 11 16:44:21 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Aug 2020 09:44:21 -0700 Subject: RFR JDK-8250839: Improve test template SSLEngineTemplate with SSLContextTemplate In-Reply-To: References: Message-ID: ping ... On 7/30/2020 11:26 AM, Xuelei Fan wrote: > Hi, > > May I get the following test code update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/ > > SSLEngineTemplate is a template used for SSLEngine testing, which > depends on binary key store files, and not easy to extend.? This update > makes it easier to extend, by removing the files dependency and using > SSLContextTemplate. > > Thanks, > Xuelei From sergei.tsypanov at yandex.ru Thu Aug 13 11:04:23 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 13 Aug 2020 13:04:23 +0200 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: <616151592850151@mail.yandex.ru> Message-ID: <1395641597315890@mail.yandex.ru> Hello, previously I've sent an email regarding removal of redundant assignments if default values to volatile fields, see https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html There was a concern whether it's completely safe to remove those assignments from JMM point of view, see https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html Recently I've found a thread in concurrency-interest mailing list where Aleksey Shiplive tried to find a constraint agians such removal: http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html It appears that there are no constraitns and Doug Lea mentions in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html that "there is never any reason to explicitly initialize fields to 0/0.0/false/null" Also there we similar code changes in java.base before: - https://bugs.openjdk.java.net/browse/JDK-6736490 - https://bugs.openjdk.java.net/browse/JDK-8035284 - https://bugs.openjdk.java.net/browse/JDK-8145680 So I think now we can accept the patch as the changes appear to be safe. Best regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: volatile.patch Type: text/x-diff Size: 6253 bytes Desc: not available URL: From sean.mullan at oracle.com Thu Aug 13 12:05:36 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 08:05:36 -0400 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: <1395641597315890@mail.yandex.ru> References: <1395641597315890@mail.yandex.ru> Message-ID: <419231a8-c5cb-2d42-22c8-63e51b816333@oracle.com> On 8/13/20 7:04 AM, ?????? ??????? wrote: > Hello, > > previously I've sent an email regarding removal of redundant assignments if default values to volatile fields, see > https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html > > There was a concern whether it's completely safe to remove those assignments from JMM point of view, see > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html > > Recently I've found a thread in concurrency-interest mailing list where Aleksey Shiplive tried to find a constraint > agians such removal: http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html > > It appears that there are no constraitns and Doug Lea mentions in > http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > that "there is never any reason to explicitly initialize fields to 0/0.0/false/null" > > Also there we similar code changes in java.base before: > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > > So I think now we can accept the patch as the changes appear to be safe. Ok, it seems like a good change. Are you able to file a JBS issue for this? After that you can request a formal code review. Thanks, Sean From sergei.tsypanov at yandex.ru Thu Aug 13 13:04:38 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 13 Aug 2020 15:04:38 +0200 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: <419231a8-c5cb-2d42-22c8-63e51b816333@oracle.com> References: <1395641597315890@mail.yandex.ru> <419231a8-c5cb-2d42-22c8-63e51b816333@oracle.com> Message-ID: <408861597323577@mail.yandex.ru> Hi, I don't have account in JBS, so I cannot file an issue. Previously when I submitted patches via core-libs-dev mailing list previleged users filed the issues and created web-reviews. I think this should be a subtask of https://bugs.openjdk.java.net/browse/JDK-6736490, there's already one I've mentioned in previous mail: https://bugs.openjdk.java.net/browse/JDK-8145680 Regards, Sergey Tsypanov 13.08.2020, 14:05, "Sean Mullan" : > On 8/13/20 7:04 AM, ?????? ??????? wrote: >> ?Hello, >> >> ?previously I've sent an email regarding removal of redundant assignments if default values to volatile fields, see >> ?https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html >> >> ?There was a concern whether it's completely safe to remove those assignments from JMM point of view, see >> ?https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html >> >> ?Recently I've found a thread in concurrency-interest mailing list where Aleksey Shiplive tried to find a constraint >> ?agians such removal: http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html >> >> ?It appears that there are no constraitns and Doug Lea mentions in >> ?http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >> ?that "there is never any reason to explicitly initialize fields to 0/0.0/false/null" >> >> ?Also there we similar code changes in java.base before: >> >> ?- https://bugs.openjdk.java.net/browse/JDK-6736490 >> ?- https://bugs.openjdk.java.net/browse/JDK-8035284 >> ?- https://bugs.openjdk.java.net/browse/JDK-8145680 >> >> ?So I think now we can accept the patch as the changes appear to be safe. > > Ok, it seems like a good change. Are you able to file a JBS issue for > this? After that you can request a formal code review. > > Thanks, > Sean From julia.boes at oracle.com Thu Aug 13 15:05:51 2020 From: julia.boes at oracle.com (Julia Boes) Date: Thu, 13 Aug 2020 16:05:51 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: Message-ID: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Hi Vipin, Thanks for providing this fix, I'm happy to sponsor your change. To complete the review, we still need someone to green light the remaining changes below. I'm looping in net-dev and security-dev to have a look. Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ Once the review is completed, please provide me with a patch that includes a changeset comment as described here: https://openjdk.java.net/guide/producingChangeset.html If you have any questions, let me know. Cheers, Julia > --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java > 2020-07-25 23:46:21.233726447 +0530 > +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java > 2020-07-25 23:46:20.721720857 +0530 > @@ -96,8 +96,6 @@ > * @param p the prime modulus > * @param g the base generator > * @param l the private-value length > - * > - * @exception InvalidKeyException if the key cannot be encoded > */ > DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) { > this.x = x; > --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > 2020-07-25 23:46:22.241737383 +0530 > +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java > 2020-07-25 23:46:21.745732013 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2020, 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 > @@ -208,7 +208,7 @@ > * > * @return a CallSite, which, when invoked, will return an instance of the > * functional interface > - * @throws ReflectiveOperationException > + * @throws LambdaConversionException > */ > abstract CallSite buildCallSite() > throws LambdaConversionException; > --- old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java > 2020-07-25 23:46:23.261748361 +0530 > +++ new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java > 2020-07-25 23:46:22.761742991 +0530 > @@ -200,7 +200,6 @@ > * > * @return a CallSite, which, when invoked, will return an instance of the > * functional interface > - * @throws ReflectiveOperationException > * @throws LambdaConversionException If properly formed functional interface > * is not found > */ > --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 > 23:46:26.449782093 +0530 > +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 > 23:46:25.937776742 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2020, 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 > @@ -315,7 +315,7 @@ > /** > * Creates the socket implementation. > * > - * @throws IOException if creation fails > + * @throws SocketException if creation fails > * @since 1.4 > */ > void createImpl() throws SocketException { > --- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25 > 23:46:27.485792869 +0530 > +++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25 > 23:46:26.973787565 +0530 > @@ -533,7 +533,7 @@ > * > * @param stream a {@code boolean} value : {@code true} for a TCP socket, > * {@code false} for UDP. > - * @throws IOException if creation fails > + * @throws SocketException if creation fails > * @since 1.4 > */ > void createImpl(boolean stream) throws SocketException { From daniel.fuchs at oracle.com Thu Aug 13 16:07:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Aug 2020 17:07:30 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Message-ID: <17593e07-0ae1-c881-47df-17643698d53f@oracle.com> Hi Vipin, Julia, On 13/08/2020 16:05, Julia Boes wrote: > Hi Vipin, > > Thanks for providing this fix, I'm happy to sponsor your change. To > complete the review, we still need someone to green light the remaining > changes below. I'm looping in net-dev and security-dev to have a look. Changes to Socket and ServerSocket look fine. No CSR needed since this is a package private API. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ best regards, -- daniel From sean.mullan at oracle.com Thu Aug 13 17:13:06 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 13:13:06 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> Message-ID: <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> On 8/13/20 11:05 AM, Julia Boes wrote: > Hi Vipin, > > Thanks for providing this fix, I'm happy to sponsor your change. To > complete the review, we still need someone to green light the remaining > changes below. I'm looping in net-dev and security-dev to have a look. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 > > Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ > > Once the review is completed, please provide me with a patch that > includes a changeset comment as described here: > https://openjdk.java.net/guide/producingChangeset.html > > If you have any questions, let me know. > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >> 2020-07-25 23:46:21.233726447 +0530 >> +++ >> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >> 2020-07-25 23:46:20.721720857 +0530 >> @@ -96,8 +96,6 @@ >> ?????? * @param p the prime modulus >> ?????? * @param g the base generator >> ?????? * @param l the private-value length >> -???? * >> -???? * @exception InvalidKeyException if the key cannot be encoded This should actually remain, but it should be ProviderException which is a RuntimeException. See the other DHPrivateKey ctor as that specifies it correctly. --Sean From sean.mullan at oracle.com Thu Aug 13 17:20:20 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 13:20:20 -0400 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: <408861597323577@mail.yandex.ru> References: <1395641597315890@mail.yandex.ru> <419231a8-c5cb-2d42-22c8-63e51b816333@oracle.com> <408861597323577@mail.yandex.ru> Message-ID: On 8/13/20 9:04 AM, ?????? ??????? wrote: > Hi, > > I don't have account in JBS, so I cannot file an issue. > > Previously when I submitted patches via core-libs-dev mailing list previleged users > filed the issues and created web-reviews. > > I think this should be a subtask of https://bugs.openjdk.java.net/browse/JDK-6736490, there's > already one I've mentioned in previous mail: https://bugs.openjdk.java.net/browse/JDK-8145680 Done: see https://bugs.openjdk.java.net/browse/JDK-8251548 --Sean > > Regards, > Sergey Tsypanov > > > 13.08.2020, 14:05, "Sean Mullan" : >> On 8/13/20 7:04 AM, ?????? ??????? wrote: >>> ?Hello, >>> >>> ?previously I've sent an email regarding removal of redundant assignments if default values to volatile fields, see >>> ?https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html >>> >>> ?There was a concern whether it's completely safe to remove those assignments from JMM point of view, see >>> ?https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html >>> >>> ?Recently I've found a thread in concurrency-interest mailing list where Aleksey Shiplive tried to find a constraint >>> ?agians such removal: https://urldefense.com/v3/__http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html__;!!GqivPVa7Brio!I4TMi9HPzckS0_w9Qmgw0-kGArRRuctFvBSnpthDRPaGGqgvl9yyrjVHboPdHMd6$ >>> >>> ?It appears that there are no constraitns and Doug Lea mentions in >>> ?https://urldefense.com/v3/__http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html__;!!GqivPVa7Brio!I4TMi9HPzckS0_w9Qmgw0-kGArRRuctFvBSnpthDRPaGGqgvl9yyrjVHbvX4nrL2$ >>> ?that "there is never any reason to explicitly initialize fields to 0/0.0/false/null" >>> >>> ?Also there we similar code changes in java.base before: >>> >>> ?- https://bugs.openjdk.java.net/browse/JDK-6736490 >>> ?- https://bugs.openjdk.java.net/browse/JDK-8035284 >>> ?- https://bugs.openjdk.java.net/browse/JDK-8145680 >>> >>> ?So I think now we can accept the patch as the changes appear to be safe. >> >> Ok, it seems like a good change. Are you able to file a JBS issue for >> this? After that you can request a formal code review. >> >> Thanks, >> Sean From jonathan.gibbons at oracle.com Thu Aug 13 17:21:49 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Aug 2020 10:21:49 -0700 Subject: Fix for Javadoc errors in java.base In-Reply-To: <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> Message-ID: On 8/13/20 10:13 AM, Sean Mullan wrote: > On 8/13/20 11:05 AM, Julia Boes wrote: >> Hi Vipin, >> >> Thanks for providing this fix, I'm happy to sponsor your change. To >> complete the review, we still need someone to green light the >> remaining changes below. I'm looping in net-dev and security-dev to >> have a look. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8251542 >> >> Webrev: http://cr.openjdk.java.net/~jboes/webrevs/8251542/webrev/ >> >> Once the review is completed, please provide me with a patch that >> includes a changeset comment as described here: >> https://openjdk.java.net/guide/producingChangeset.html >> >> If you have any questions, let me know. >> >> Cheers, >> >> Julia >> >>> --- >>> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>> 2020-07-25 23:46:21.233726447 +0530 >>> +++ >>> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>> 2020-07-25 23:46:20.721720857 +0530 >>> @@ -96,8 +96,6 @@ >>> ?????? * @param p the prime modulus >>> ?????? * @param g the base generator >>> ?????? * @param l the private-value length >>> -???? * >>> -???? * @exception InvalidKeyException if the key cannot be encoded > > This should actually remain, but it should be ProviderException which > is a RuntimeException. See the other DHPrivateKey ctor as that > specifies it correctly. > > --Sean I note the use of `@exception`, as compared to `@throws`, which is more common. Stats: `@exception` 7322 occurrences `@throws` 21173 occurrences That's probably too many `@exception` to clean up. :-( -- Jon From sean.mullan at oracle.com Thu Aug 13 17:25:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Aug 2020 13:25:57 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> Message-ID: <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> On 8/13/20 1:21 PM, Jonathan Gibbons wrote: >>>> --- >>>> old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>> >>>> 2020-07-25 23:46:21.233726447 +0530 >>>> +++ >>>> new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>> >>>> 2020-07-25 23:46:20.721720857 +0530 >>>> @@ -96,8 +96,6 @@ >>>> ?????? * @param p the prime modulus >>>> ?????? * @param g the base generator >>>> ?????? * @param l the private-value length >>>> -???? * >>>> -???? * @exception InvalidKeyException if the key cannot be encoded >> >> This should actually remain, but it should be ProviderException which >> is a RuntimeException. See the other DHPrivateKey ctor as that >> specifies it correctly. >> >> --Sean > > > I note the use of `@exception`, as compared to `@throws`, which is more > common. > > Stats: > `@exception` 7322 occurrences > `@throws` 21173 occurrences > > That's probably too many `@exception` to clean up. :-( Right, that's probably a separate cleanup activity. However, if you want to change the 3 instances of @exception to @throws in DHPrivateKey, I'm fine with that. --Sean From anthony.scarpino at oracle.com Thu Aug 13 18:13:00 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 13 Aug 2020 11:13:00 -0700 Subject: RFR JDK-8250839: Improve test template SSLEngineTemplate with SSLContextTemplate In-Reply-To: References: Message-ID: On 8/11/20 9:44 AM, Xuelei Fan wrote: > ping ... > > On 7/30/2020 11:26 AM, Xuelei Fan wrote: >> Hi, >> >> May I get the following test code update reviewed? >> ???? http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/ >> >> SSLEngineTemplate is a template used for SSLEngine testing, which >> depends on binary key store files, and not easy to extend.? This >> update makes it easier to extend, by removing the files dependency and >> using SSLContextTemplate. >> >> Thanks, >> Xuelei Just a few nits 109-114: Did you want these commented out? I have no problem leaving it as is. I just wanted to make sure this was your intent. 219: The whitespaces are not aligned Otherwise it looks fine. No need for another webrev. Tony From xuelei.fan at oracle.com Thu Aug 13 19:00:16 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 13 Aug 2020 12:00:16 -0700 Subject: RFR JDK-8250839: Improve test template SSLEngineTemplate with SSLContextTemplate In-Reply-To: References: Message-ID: All good catches! I will update accordingly. Thanks, Xuelei On 8/13/2020 11:13 AM, Anthony Scarpino wrote: > On 8/11/20 9:44 AM, Xuelei Fan wrote: >> ping ... >> >> On 7/30/2020 11:26 AM, Xuelei Fan wrote: >>> Hi, >>> >>> May I get the following test code update reviewed? >>> ???? http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/ >>> >>> SSLEngineTemplate is a template used for SSLEngine testing, which >>> depends on binary key store files, and not easy to extend.? This >>> update makes it easier to extend, by removing the files dependency >>> and using SSLContextTemplate. >>> >>> Thanks, >>> Xuelei > > Just a few nits > > 109-114:? Did you want these? commented out?? I have no problem leaving > it as is.? I just wanted to make sure this was your intent. > > 219:? The whitespaces are not aligned > > Otherwise it looks fine.? No need for another webrev. > > Tony From sergei.tsypanov at yandex.ru Thu Aug 13 20:05:39 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 13 Aug 2020 22:05:39 +0200 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: References: <1395641597315890@mail.yandex.ru> <419231a8-c5cb-2d42-22c8-63e51b816333@oracle.com> <408861597323577@mail.yandex.ru> Message-ID: <88491597349073@mail.yandex.ru> Cool, thanks! Do you know anyone who could sponsor this and create a web-review against the patch? Regards, Sergeyt Tsypanov 13.08.2020, 19:22, "Sean Mullan" : > On 8/13/20 9:04 AM, ?????? ??????? wrote: >> ?Hi, >> >> ?I don't have account in JBS, so I cannot file an issue. >> >> ?Previously when I submitted patches via core-libs-dev mailing list previleged users >> ?filed the issues and created web-reviews. >> >> ?I think this should be a subtask of https://bugs.openjdk.java.net/browse/JDK-6736490, there's >> ?already one I've mentioned in previous mail: https://bugs.openjdk.java.net/browse/JDK-8145680 > > Done: see https://bugs.openjdk.java.net/browse/JDK-8251548 > > --Sean > >> ?Regards, >> ?Sergey Tsypanov >> >> ?13.08.2020, 14:05, "Sean Mullan" : >>> ?On 8/13/20 7:04 AM, ?????? ??????? wrote: >>>> ???Hello, >>>> >>>> ???previously I've sent an email regarding removal of redundant assignments if default values to volatile fields, see >>>> ???https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html >>>> >>>> ???There was a concern whether it's completely safe to remove those assignments from JMM point of view, see >>>> ???https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067341.html >>>> >>>> ???Recently I've found a thread in concurrency-interest mailing list where Aleksey Shiplive tried to find a constraint >>>> ???agians such removal: https://urldefense.com/v3/__http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014767.html__;!!GqivPVa7Brio!I4TMi9HPzckS0_w9Qmgw0-kGArRRuctFvBSnpthDRPaGGqgvl9yyrjVHboPdHMd6$ >>>> >>>> ???It appears that there are no constraitns and Doug Lea mentions in >>>> ???https://urldefense.com/v3/__http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html__;!!GqivPVa7Brio!I4TMi9HPzckS0_w9Qmgw0-kGArRRuctFvBSnpthDRPaGGqgvl9yyrjVHbvX4nrL2$ >>>> ???that "there is never any reason to explicitly initialize fields to 0/0.0/false/null" >>>> >>>> ???Also there we similar code changes in java.base before: >>>> >>>> ???- https://bugs.openjdk.java.net/browse/JDK-6736490 >>>> ???- https://bugs.openjdk.java.net/browse/JDK-8035284 >>>> ???- https://bugs.openjdk.java.net/browse/JDK-8145680 >>>> >>>> ???So I think now we can accept the patch as the changes appear to be safe. >>> >>> ?Ok, it seems like a good change. Are you able to file a JBS issue for >>> ?this? After that you can request a formal code review. >>> >>> ?Thanks, >>> ?Sean From sean.mullan at oracle.com Fri Aug 14 11:50:26 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2020 07:50:26 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> Message-ID: <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> On the property wording, change "for LDAP connection" to "for an LDAP connection". Also, for the definition of the property, can you use the "@systemProperty" annotation instead of "@code"? Does that work inside the module-info.java file? I added my name as Reviewer. --Sean On 7/30/20 6:14 AM, Daniel Fuchs wrote: > Hi Alexey, > > I have added myself as a reviewer to the CSR [1]. > It would be good to get someone from security-dev to do the > same, and then move the CSR state to "Proposed". > > best regards, > > -- daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8247311 > > On 30/07/2020 10:17, Alexey Bakhtin wrote: >> Gentle ping >> >> Regards >> Alexey > From alexey at azul.com Fri Aug 14 12:41:00 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 14 Aug 2020 12:41:00 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> References: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <342c2de2-89a6-41d1-9c27-61f2ed9ed163@oracle.com> <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> Message-ID: <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> Hello Sean, Thank you for review. I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/ Regards Alexey > On 14 Aug 2020, at 14:50, Sean Mullan wrote: > > On the property wording, change "for LDAP connection" to "for an LDAP connection". > > Also, for the definition of the property, can you use the "@systemProperty" annotation instead of "@code"? Does that work inside the module-info.java file? > > I added my name as Reviewer. > > --Sean > > On 7/30/20 6:14 AM, Daniel Fuchs wrote: >> Hi Alexey, >> I have added myself as a reviewer to the CSR [1]. >> It would be good to get someone from security-dev to do the >> same, and then move the CSR state to "Proposed". >> best regards, >> -- daniel >> [1] https://bugs.openjdk.java.net/browse/JDK-8247311 >> On 30/07/2020 10:17, Alexey Bakhtin wrote: >>> Gentle ping >>> >>> Regards >>> Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Fri Aug 14 13:18:54 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2020 09:18:54 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> References: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> Message-ID: <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> On 8/14/20 8:41 AM, Alexey Bakhtin wrote: > Hello Sean, > > Thank you for review. > I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) Thanks. Now that you know it works, I think you should change the other properties documented in that file to @systemProperty to be consistent. I think it is fine to do that as part of this fix. --Sean > > Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/ > > Regards > Alexey > >> On 14 Aug 2020, at 14:50, Sean Mullan wrote: >> >> On the property wording, change "for LDAP connection" to "for an LDAP connection". >> >> Also, for the definition of the property, can you use the "@systemProperty" annotation instead of "@code"? Does that work inside the module-info.java file? >> >> I added my name as Reviewer. >> >> --Sean >> >> On 7/30/20 6:14 AM, Daniel Fuchs wrote: >>> Hi Alexey, >>> I have added myself as a reviewer to the CSR [1]. >>> It would be good to get someone from security-dev to do the >>> same, and then move the CSR state to "Proposed". >>> best regards, >>> -- daniel >>> [1] https://bugs.openjdk.java.net/browse/JDK-8247311 >>> On 30/07/2020 10:17, Alexey Bakhtin wrote: >>>> Gentle ping >>>> >>>> Regards >>>> Alexey > From alexey at azul.com Fri Aug 14 13:26:01 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 14 Aug 2020 13:26:01 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> References: <70A3B5D4-3D0E-426C-8EB3-64CB7A42EC50@oracle.com> <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> Message-ID: <3F4A52FB-B980-489D-9862-DB3FBB12B0E7@azul.com> OK Updated for all properties in the module-info.java Webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v16/ Regards Alexey > On 14 Aug 2020, at 16:18, Sean Mullan wrote: > > On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >> Hello Sean, >> Thank you for review. >> I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) > > Thanks. Now that you know it works, I think you should change the other properties documented in that file to @systemProperty to be consistent. I think it is fine to do that as part of this fix. > > --Sean > >> Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/ >> Regards >> Alexey >>> On 14 Aug 2020, at 14:50, Sean Mullan wrote: >>> >>> On the property wording, change "for LDAP connection" to "for an LDAP connection". >>> >>> Also, for the definition of the property, can you use the "@systemProperty" annotation instead of "@code"? Does that work inside the module-info.java file? >>> >>> I added my name as Reviewer. >>> >>> --Sean >>> >>> On 7/30/20 6:14 AM, Daniel Fuchs wrote: >>>> Hi Alexey, >>>> I have added myself as a reviewer to the CSR [1]. >>>> It would be good to get someone from security-dev to do the >>>> same, and then move the CSR state to "Proposed". >>>> best regards, >>>> -- daniel >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247311 >>>> On 30/07/2020 10:17, Alexey Bakhtin wrote: >>>>> Gentle ping >>>>> >>>>> Regards >>>>> Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From aleksej.efimov at oracle.com Fri Aug 14 14:04:00 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 14 Aug 2020 15:04:00 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <3F4A52FB-B980-489D-9862-DB3FBB12B0E7@azul.com> References: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> <3F4A52FB-B980-489D-9862-DB3FBB12B0E7@azul.com> Message-ID: <435c24f3-1c3f-4938-e26e-c18500b8f235@oracle.com> Hi Sean, Alexey, Adding @systemProperty doesn't look correct here since the properties mentioned in the module-info.java are not system properties, they're standard JNDI environment properties and setting them via system property with the same name won't have any effect, e.g. "java -Dcom.sun.jndi.ldap.tls.cbtype=tls-server-end-point". Best Regards, Aleksei On 14/08/2020 14:26, Alexey Bakhtin wrote: > OK > > Updated for all properties in the module-info.java > Webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v16/ > > Regards > Alexey > >> On 14 Aug 2020, at 16:18, Sean Mullan wrote: >> >> On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >>> Hello Sean, >>> Thank you for review. >>> I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) >> Thanks. Now that you know it works, I think you should change the other properties documented in that file to @systemProperty to be consistent. I think it is fine to do that as part of this fix. >> >> --Sean >> >>> Updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v15/ >>> Regards >>> Alexey >>>> On 14 Aug 2020, at 14:50, Sean Mullan wrote: >>>> >>>> On the property wording, change "for LDAP connection" to "for an LDAP connection". >>>> >>>> Also, for the definition of the property, can you use the "@systemProperty" annotation instead of "@code"? Does that work inside the module-info.java file? >>>> >>>> I added my name as Reviewer. >>>> >>>> --Sean >>>> >>>> On 7/30/20 6:14 AM, Daniel Fuchs wrote: >>>>> Hi Alexey, >>>>> I have added myself as a reviewer to the CSR [1]. >>>>> It would be good to get someone from security-dev to do the >>>>> same, and then move the CSR state to "Proposed". >>>>> best regards, >>>>> -- daniel >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8247311 >>>>> On 30/07/2020 10:17, Alexey Bakhtin wrote: >>>>>> Gentle ping >>>>>> >>>>>> Regards >>>>>> Alexey From daniel.fuchs at oracle.com Fri Aug 14 14:18:54 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 15:18:54 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> References: <2267CBC7-85A9-4105-B405-E7499440B985@azul.com> <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> Message-ID: <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> Hi Sean, Wait wait... Are they system properties really? Only system properties should be documented with @systemProperty. I can't find the place were com.sun.jndi.ldap.connect.timeout or com.sun.jndi.ldap.read.timeout is read from System. I believe they are just plain environment properties that you need to specify in the environment map. best regards, -- daniel On 14/08/2020 14:18, Sean Mullan wrote: > On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >> Hello Sean, >> >> Thank you for review. >> I?ve changed wording and replaced @code with @systemProperty (tested, >> it works for module-info.java) > > Thanks. Now that you know it works, I think you should change the other > properties documented in that file to @systemProperty to be consistent. > I think it is fine to do that as part of this fix. > > --Sean From sean.mullan at oracle.com Fri Aug 14 14:23:41 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2020 10:23:41 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> References: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> Message-ID: <12a66244-2215-f947-c1e4-0877ef39f807@oracle.com> Sorry you are right! Would be nice to have a more general @property for these types of properties and security properties, etc but that's a different change ... --Sean On 8/14/20 10:18 AM, Daniel Fuchs wrote: > Hi Sean, > > Wait wait... Are they system properties really? > > Only system properties should be documented with @systemProperty. > I can't find the place were com.sun.jndi.ldap.connect.timeout or > com.sun.jndi.ldap.read.timeout is read from System. > > I believe they are just plain environment properties > that you need to specify in the environment map. > > best regards, > > -- daniel > > On 14/08/2020 14:18, Sean Mullan wrote: >> On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >>> Hello Sean, >>> >>> Thank you for review. >>> I?ve changed wording and replaced @code with @systemProperty (tested, >>> it works for module-info.java) >> >> Thanks. Now that you know it works, I think you should change the >> other properties documented in that file to @systemProperty to be >> consistent. I think it is fine to do that as part of this fix. >> >> --Sean From alexey at azul.com Fri Aug 14 14:42:26 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 14 Aug 2020 14:42:26 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <12a66244-2215-f947-c1e4-0877ef39f807@oracle.com> References: <8885AB2E-0671-4493-A2D6-88302C48CAF9@oracle.com> <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> <12a66244-2215-f947-c1e4-0877ef39f807@oracle.com> Message-ID: <289A4001-F580-40EF-A337-FA9EB3637D2E@azul.com> Sorry, That?s my bad. I have reverted @systemProperty to @code. The wording is fixed. Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v17/ Regards Alexey > On 14 Aug 2020, at 17:23, Sean Mullan wrote: > > Sorry you are right! Would be nice to have a more general @property for these types of properties and security properties, etc but that's a different change ... > > --Sean > > On 8/14/20 10:18 AM, Daniel Fuchs wrote: >> Hi Sean, >> Wait wait... Are they system properties really? >> Only system properties should be documented with @systemProperty. >> I can't find the place were com.sun.jndi.ldap.connect.timeout or >> com.sun.jndi.ldap.read.timeout is read from System. >> I believe they are just plain environment properties >> that you need to specify in the environment map. >> best regards, >> -- daniel >> On 14/08/2020 14:18, Sean Mullan wrote: >>> On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >>>> Hello Sean, >>>> >>>> Thank you for review. >>>> I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) >>> >>> Thanks. Now that you know it works, I think you should change the other properties documented in that file to @systemProperty to be consistent. I think it is fine to do that as part of this fix. >>> >>> --Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From daniel.fuchs at oracle.com Fri Aug 14 14:50:31 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Aug 2020 15:50:31 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <289A4001-F580-40EF-A337-FA9EB3637D2E@azul.com> References: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> <12a66244-2215-f947-c1e4-0877ef39f807@oracle.com> <289A4001-F580-40EF-A337-FA9EB3637D2E@azul.com> Message-ID: <82f53ce4-22fb-5232-2b13-257ca154df4f@oracle.com> Hi Alexey, LGTM! Thanks, -- daniel On 14/08/2020 15:42, Alexey Bakhtin wrote: > Sorry, > That?s my bad. > I have reverted @systemProperty to @code. The wording is fixed. > > Webrev: > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v17/ > > Regards > Alexey From aleksej.efimov at oracle.com Fri Aug 14 15:01:11 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 14 Aug 2020 16:01:11 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <289A4001-F580-40EF-A337-FA9EB3637D2E@azul.com> References: <070d2335-32d1-d4f6-892f-1a28c6649a31@oracle.com> <85c2e4b8-f61e-920c-5afe-5e3ed3df5c45@oracle.com> <643f3744-cfa2-e871-1284-900d81709f53@oracle.com> <77fb8b44-2438-2f62-07b6-45c12a9c6f34@oracle.com> <7621fa33-26cc-d545-cb33-a93fdbfd48c7@oracle.com> <8804341B-E534-4FA8-A652-86F8A30F18B3@azul.com> <999EF4D0-4084-4EC2-803C-EDC23D3EB8F2@azul.com> <5b7281d3-4bfc-f0ac-07d3-365451835f70@oracle.com> <2D6CC614-0C5E-49C0-87E1-4FFFE2788DAD@azul.com> <55679fee-cc49-9437-d1e5-dc696b9b3a08@oracle.com> <538c29b1-8c12-d410-85a8-43e3ba1665cd@oracle.com> <12a66244-2215-f947-c1e4-0877ef39f807@oracle.com> <289A4001-F580-40EF-A337-FA9EB3637D2E@azul.com> Message-ID: Hi Alexey, The last version looks good to me. Best, Aleksei On 14/08/2020 15:42, Alexey Bakhtin wrote: > Sorry, > That?s my bad. > I have reverted @systemProperty to @code. The wording is fixed. > > Webrev: > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v17/ > > Regards > Alexey > >> On 14 Aug 2020, at 17:23, Sean Mullan wrote: >> >> Sorry you are right! Would be nice to have a more general @property for these types of properties and security properties, etc but that's a different change ... >> >> --Sean >> >> On 8/14/20 10:18 AM, Daniel Fuchs wrote: >>> Hi Sean, >>> Wait wait... Are they system properties really? >>> Only system properties should be documented with @systemProperty. >>> I can't find the place were com.sun.jndi.ldap.connect.timeout or >>> com.sun.jndi.ldap.read.timeout is read from System. >>> I believe they are just plain environment properties >>> that you need to specify in the environment map. >>> best regards, >>> -- daniel >>> On 14/08/2020 14:18, Sean Mullan wrote: >>>> On 8/14/20 8:41 AM, Alexey Bakhtin wrote: >>>>> Hello Sean, >>>>> >>>>> Thank you for review. >>>>> I?ve changed wording and replaced @code with @systemProperty (tested, it works for module-info.java) >>>> Thanks. Now that you know it works, I think you should change the other properties documented in that file to @systemProperty to be consistent. I think it is fine to do that as part of this fix. >>>> >>>> --Sean From vipinsharma85 at gmail.com Fri Aug 14 18:46:40 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Sat, 15 Aug 2020 00:16:40 +0530 Subject: Fix for Javadoc errors in java.base In-Reply-To: <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> Message-ID: Hi Sean, All 3 instances of @exception in DHPrivateKey are now replaced with @throws, added ProviderException similar to other constructor of DHPrivateKey. Updated patch: --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-08-14 23:55:40.921599987 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-08-14 23:55:40.417581423 +0530 @@ -80,7 +80,7 @@ * @param p the prime modulus * @param g the base generator * - * @exception ProviderException if the key cannot be encoded + * @throws ProviderException if the key cannot be encoded */ DHPrivateKey(BigInteger x, BigInteger p, BigInteger g) throws InvalidKeyException { @@ -97,7 +97,7 @@ * @param g the base generator * @param l the private-value length * - * @exception InvalidKeyException if the key cannot be encoded + * @throws ProviderException if the key cannot be encoded */ DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) { this.x = x; @@ -118,7 +118,7 @@ * * @param encodedKey the encoded key * - * @exception InvalidKeyException if the encoded key does not represent + * @throws InvalidKeyException if the encoded key does not represent * a Diffie-Hellman private key */ DHPrivateKey(byte[] encodedKey) throws InvalidKeyException { --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-08-14 23:55:41.953638446 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-08-14 23:55:41.445619497 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2020, 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 @@ -208,7 +208,7 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException + * @throws LambdaConversionException */ abstract CallSite buildCallSite() throws LambdaConversionException; --- old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-08-14 23:55:42.977677096 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-08-14 23:55:42.473658062 +0530 @@ -200,7 +200,6 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException * @throws LambdaConversionException If properly formed functional interface * is not found */ --- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-08-14 23:55:44.409731999 +0530 +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-08-14 23:55:43.889711942 +0530 @@ -5403,7 +5403,7 @@ * * @param n the numerator; must be negative * @param d the denominator; must not be unity - * @return a two-element {@long} array with the remainder and quotient in + * @return a two-element {@code long} array with the remainder and quotient in * the initial and final elements, respectively */ private static long[] divRemNegativeLong(long n, long d) { --- old/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-08-14 23:55:45.905790246 +0530 +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-08-14 23:55:45.397770378 +0530 @@ -145,7 +145,6 @@ * Makes this number an {@code n}-int number all of whose bits are ones. * Used by Burnikel-Ziegler division. * @param n number of ints in the {@code value} array - * @return a number equal to {@code ((1<<(32*n)))-1} */ private void ones(int n) { if (n > value.length) --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-08-14 23:55:46.961831962 +0530 +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-08-14 23:55:46.449811716 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2020, 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 @@ -315,7 +315,7 @@ /** * Creates the socket implementation. * - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl() throws SocketException { --- old/src/java.base/share/classes/java/net/Socket.java 2020-08-14 23:55:48.001873514 +0530 +++ new/src/java.base/share/classes/java/net/Socket.java 2020-08-14 23:55:47.493853209 +0530 @@ -533,7 +533,7 @@ * * @param stream a {@code boolean} value : {@code true} for a TCP socket, * {@code false} for UDP. - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl(boolean stream) throws SocketException { --- old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-08-14 23:55:49.061916354 +0530 +++ new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-08-14 23:55:48.549895649 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2020, 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 @@ -773,7 +773,7 @@ * an "annotation structure" OR two bytes into an annotation * structure (i.e., after the type index). * - * @parameter complete true if the byte buffer points to the beginning + * @param complete true if the byte buffer points to the beginning * of an annotation structure (rather than two bytes in). */ private static void skipAnnotation(ByteBuffer buf, boolean complete) { Regards, Vipin > On Aug 13, 2020, at 10:55 PM, Sean Mullan wrote: > > On 8/13/20 1:21 PM, Jonathan Gibbons wrote: >>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>>> 2020-07-25 23:46:21.233726447 +0530 >>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java >>>>> 2020-07-25 23:46:20.721720857 +0530 >>>>> @@ -96,8 +96,6 @@ >>>>> * @param p the prime modulus >>>>> * @param g the base generator >>>>> * @param l the private-value length >>>>> - * >>>>> - * @exception InvalidKeyException if the key cannot be encoded >>> >>> This should actually remain, but it should be ProviderException which is a RuntimeException. See the other DHPrivateKey ctor as that specifies it correctly. >>> >>> --Sean >> I note the use of `@exception`, as compared to `@throws`, which is more common. >> Stats: >> `@exception` 7322 occurrences >> `@throws` 21173 occurrences >> That's probably too many `@exception` to clean up. :-( > > Right, that's probably a separate cleanup activity. However, if you want to change the 3 instances of @exception to @throws in DHPrivateKey, I'm fine with that. > > --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Aug 14 19:03:13 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2020 15:03:13 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> Message-ID: On 8/14/20 2:46 PM, Vipin Sharma wrote: > Hi Sean, > > All 3 instances of @exception in DHPrivateKey are now replaced with > @throws, added ProviderException similar to other constructor of > DHPrivateKey. Looks good. --Sean From RAJAN.HALADE at ORACLE.COM Tue Aug 18 00:11:12 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Mon, 17 Aug 2020 17:11:12 -0700 Subject: RFR: 8251859: sun/security/validator/PKIXValAndRevCheckTests.java fails Message-ID: <0A14BBA3-5B1A-4694-B02B-D119A01D9B1E@ORACLE.COM> Please review this patch to perform backdated certpath check as test certificate has expired. diff -r cb8450f00ee9 test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java --- a/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java Tue Aug 18 01:08:18 2020 +0200 +++ b/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java Mon Aug 17 17:09:47 2020 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2019, 2020, 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 @@ -374,6 +374,7 @@ // Test 1: Path validation with revocation explicitly turned // off, expected to pass. pkixParams = new PKIXBuilderParameters(trustAnchors, null); + pkixParams.setDate(VALID_DATE); pkixParams.setRevocationEnabled(false); validatePath(goodPath, Collections.emptyList(), pkixParams, null); Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Aug 18 00:14:48 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 17 Aug 2020 17:14:48 -0700 Subject: RFR: 8251859: sun/security/validator/PKIXValAndRevCheckTests.java fails In-Reply-To: <0A14BBA3-5B1A-4694-B02B-D119A01D9B1E@ORACLE.COM> References: <0A14BBA3-5B1A-4694-B02B-D119A01D9B1E@ORACLE.COM> Message-ID: Looks fine to me. --Jamil On 8/17/2020 5:11 PM, Rajan Halade wrote: > Please review this patch to perform backdated certpath check as test > certificate has expired. > > /diff -r cb8450f00ee9 > test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java/ > /--- a/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.javaTue > Aug 18 01:08:18 2020 +0200/ > /+++ b/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.javaMon > Aug 17 17:09:47 2020 -0700/ > /@@ -1,5 +1,5 @@/ > /?/*/ > /- * Copyright (c) 2019, Oracle and/or its affiliates. All rights > reserved./ > /*+ * Copyright (c) 2019, 2020, 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/ > /@@ -374,6 +374,7 @@/ > /? ? ? ? ?// Test 1: Path validation with revocation explicitly turned/ > /? ? ? ? ?// off, expected to pass./ > /? ? ? ? ?pkixParams = new PKIXBuilderParameters(trustAnchors, null);/ > /*+ ?pkixParams.setDate(VALID_DATE);*/ > /?pkixParams.setRevocationEnabled(false);/ > /? ? ? ? ?validatePath(goodPath, Collections.emptyList(), pkixParams, > null);/ > > Thanks, > Rajan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Aug 18 00:21:30 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 17 Aug 2020 17:21:30 -0700 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: <42e2e845-4f5b-bf93-a91f-047c22a47043@oracle.com> References: <1748e9a9-5cf7-d014-7725-4194a99ce902@oracle.com> <42e2e845-4f5b-bf93-a91f-047c22a47043@oracle.com> Message-ID: <3aecda11-814a-772e-3e52-4915263339d7@oracle.com> Hi Norman, There are a couple things in the stack trace that don't make sense. Am I missing something? This looks like a server side trace, so the initialization of the RandomCookie should be inside the Task for the FINISHED message consumption, which kicks off the NewSessionTicket creation before ending. What version of the JDK is this stack trace from? I've looked at our current code and have gone back to our initial TLSv1.3 changeset in jdk-11+20, and I'm not seeing where the initialization of the RandomCookie could be done outside of the FINISHED TASK processing. By chance is Netty replacing any of our sun.security.ssl.SSLEngine code? Here's what the code should look like. "MainThread" at sun.security.ssl.SessionId.(SessionId.java:45) at sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:224) at sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1134) at sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:877) at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) at java.security.AccessController.doPrivileged(AccessController.java) at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) at SSLEngineTemplate.runDelegatedTasks(SSLEngineTemplate.java:317) at SSLEngineTemplate.runTest(SSLEngineTemplate.java:225) at SSLEngineTemplate.main(SSLEngineTemplate.java:136) Thanks, Brad On 8/7/2020 11:24 AM, Alan Bateman wrote: > On 07/08/2020 18:27, Anthony Scarpino wrote: >> Well if there were a bug it's with NativePRNG as the operation is >> suppose to be non-blocking.? Even so, /dev/urandom is nonblocking. The >> only reason this looks to have been detected by the tool is because >> it's a blocking read op.? This all seems like an extremely unlikely >> situation.? I don't see this as something SSLEngine should be >> compensating for. > Right, /dev/random is blocking, /dev/urandom is non-blocking. I just > checked BlockHound and it seems to have the names of private methods in > the java.io and java.net classes and I think instruments these methods > on the assumption that they are blocking calls. The list seems to have > been generated from an older JDK too, not really in sync with release > JDK releases. So not clear to me that there is really an issue here. > > -Alan From xuelei.fan at oracle.com Tue Aug 18 01:38:23 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Aug 2020 18:38:23 -0700 Subject: RFR: 8251859: sun/security/validator/PKIXValAndRevCheckTests.java fails In-Reply-To: <0A14BBA3-5B1A-4694-B02B-D119A01D9B1E@ORACLE.COM> References: <0A14BBA3-5B1A-4694-B02B-D119A01D9B1E@ORACLE.COM> Message-ID: <6a0cedc0-f864-930d-c441-b14398fdb7ec@oracle.com> Looks fine to me. Thanks, Xuelei On 8/17/2020 5:11 PM, Rajan Halade wrote: > Please review this patch to perform backdated certpath check as test > certificate has expired. > > /diff -r cb8450f00ee9 > test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java/ > /--- a/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.javaTue > Aug 18 01:08:18 2020 +0200/ > /+++ b/test/jdk/sun/security/validator/PKIXValAndRevCheckTests.javaMon > Aug 17 17:09:47 2020 -0700/ > /@@ -1,5 +1,5 @@/ > /?/*/ > /- * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved./ > /*+ * Copyright (c) 2019, 2020, 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/ > /@@ -374,6 +374,7 @@/ > /? ? ? ? ?// Test 1: Path validation with revocation explicitly turned/ > /? ? ? ? ?// off, expected to pass./ > /? ? ? ? ?pkixParams = new PKIXBuilderParameters(trustAnchors, null);/ > /*+ ? ? ? ?pkixParams.setDate(VALID_DATE);*/ > /? ? ? ? ?pkixParams.setRevocationEnabled(false);/ > /? ? ? ? ?validatePath(goodPath, Collections.emptyList(), pkixParams, > null);/ > > Thanks, > Rajan > From julia.boes at oracle.com Tue Aug 18 17:02:37 2020 From: julia.boes at oracle.com (Julia Boes) Date: Tue, 18 Aug 2020 18:02:37 +0100 Subject: Fix for Javadoc errors in java.base In-Reply-To: References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> Message-ID: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Hi, The two changes below still need to be reviewed. Any takers? Cheers, Julia > --- > old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 > 23:55:41.953638446 +0530 > +++ > new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 > 23:55:41.445619497 +0530 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2020, 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 > @@ -208,7 +208,7 @@ > ? ? ? * > ? ? ? * @return a CallSite, which, when invoked, will return an > instance of the > ? ? ? * functional interface > - ? ? * @throws ReflectiveOperationException > + ? ? * @throws LambdaConversionException > ? ? ? */ > ? ? ?abstract CallSite buildCallSite() > ? ? ? ? ? ? ?throws LambdaConversionException; > --- > old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 > 23:55:42.977677096 +0530 > +++ > new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 > 23:55:42.473658062 +0530 > @@ -200,7 +200,6 @@ > ? ? ? * > ? ? ? * @return a CallSite, which, when invoked, will return an > instance of the > ? ? ? * functional interface > - ? ? * @throws ReflectiveOperationException > ? ? ? * @throws LambdaConversionException If properly formed > functional interface > ? ? ? * is not found > ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Aug 18 17:05:12 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Aug 2020 10:05:12 -0700 Subject: Fix for Javadoc errors in java.base In-Reply-To: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Message-ID: <4ffac099-db84-c782-2e14-75bde259e86d@oracle.com> Looks fine. Thanks Mandy On 8/18/20 10:02 AM, Julia Boes wrote: > > Hi, > > The two changes below still need to be reviewed. Any takers? > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.953638446 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.445619497 +0530 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2020, 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 >> @@ -208,7 +208,7 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> + ? ? * @throws LambdaConversionException >> ? ? ? */ >> ? ? ?abstract CallSite buildCallSite() >> ? ? ? ? ? ? ?throws LambdaConversionException; >> --- >> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.977677096 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.473658062 +0530 >> @@ -200,7 +200,6 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> ? ? ? * @throws LambdaConversionException If properly formed >> functional interface >> ? ? ? * is not found >> ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Aug 18 19:51:47 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Aug 2020 12:51:47 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider Message-ID: Anyone has cycles to review this somewhat trivial changes? JceSecurity has this shared SecureRandom instance which may lead to NPE when certain 3rd party JCE provider is set as most preferred. Removing this shared instance and change to create default SecureRandom obj when needed. Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Tue Aug 18 20:11:52 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Aug 2020 13:11:52 -0700 Subject: [16] RFR JDK-8172366: Support SHA-3 based signatures Message-ID: <0a2f5cd5-8ea8-f8d8-124f-290814f3e0c8@oracle.com> Can someone help review this SHA-3 based signature support? Note that changes to SunPKCS11 provider will be covered by a separate RFE (JDK-8244154). Current webrev adds SHA-3 digest support to DSA, RSA, ECDSA signature algorithms. I am a bit on the fence for the DSA signature and am including it here mostly for completeness sake. Can remove it if that's preferred. Comments? Will file a CSR for this once we reached consensus on whether to add SHA-3 support to DSA signature. RFE: https://bugs.openjdk.java.net/browse/JDK-8172366 Webrev: http://cr.openjdk.java.net/~valeriep/8172366/webrev.00/ Thanks, Valerie From jamil.j.nimeh at oracle.com Tue Aug 18 20:30:18 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 18 Aug 2020 13:30:18 -0700 Subject: [16] RFR JDK-8172366: Support SHA-3 based signatures In-Reply-To: <0a2f5cd5-8ea8-f8d8-124f-290814f3e0c8@oracle.com> References: <0a2f5cd5-8ea8-f8d8-124f-290814f3e0c8@oracle.com> Message-ID: From just a quick skimming across a few FIPS specs, it looks like DSA with SHA-3 seems worth including.? FIPS 202 is designed to supplement the hash algs in 180-4, and Section 2.3 of 186-4 indicates that SHAx(M) is intended for those algs specified in 180 (and I assume by extension 202).? Since there are OIDs in the NIST arc for dsa-with-sha3-nnn it seems like all the pieces have specification support.? Seems like a good thing to do. --Jamil On 8/18/2020 1:11 PM, Valerie Peng wrote: > > Can someone help review this SHA-3 based signature support? Note that > changes to SunPKCS11 provider will be covered by a separate RFE > (JDK-8244154). Current webrev adds SHA-3 digest support to DSA, RSA, > ECDSA signature algorithms. I am a bit on the fence for the DSA > signature and am including it here mostly for completeness sake. Can > remove it if that's preferred. Comments? > > Will file a CSR for this once we reached consensus on whether to add > SHA-3 support to DSA signature. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8172366 > > Webrev: http://cr.openjdk.java.net/~valeriep/8172366/webrev.00/ > > Thanks, > Valerie From xuelei.fan at oracle.com Tue Aug 18 21:10:46 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Aug 2020 14:10:46 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: References: Message-ID: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> Is there any performance impact? Xuelei On 8/18/2020 12:51 PM, Valerie Peng wrote: > > Anyone has cycles to review this somewhat trivial changes? JceSecurity > has this shared SecureRandom instance which may lead to NPE when certain > 3rd party JCE provider is set as most preferred. Removing this shared > instance and change to create default SecureRandom obj when needed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 > > Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Tue Aug 18 21:43:15 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Aug 2020 14:43:15 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> Message-ID: <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> Using a shared instance is surely faster. However, the API specified that the most preferred SecureRandom impl will be used. To ensure this for all scenarios, creating default SecureRandom obj will provide correct result but shared instance may not. Apps can call other init functions which takes SecureRandom objects to avoid this default SecureRandom obj creation if needed. Valerie On 8/18/2020 2:10 PM, Xuelei Fan wrote: > Is there any performance impact? > > Xuelei > > On 8/18/2020 12:51 PM, Valerie Peng wrote: >> >> Anyone has cycles to review this somewhat trivial changes? >> JceSecurity has this shared SecureRandom instance which may lead to >> NPE when certain 3rd party JCE provider is set as most preferred. >> Removing this shared instance and change to create default >> SecureRandom obj when needed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Tue Aug 18 21:45:01 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Aug 2020 14:45:01 -0700 Subject: [16] RFR JDK-8172366: Support SHA-3 based signatures In-Reply-To: References: <0a2f5cd5-8ea8-f8d8-124f-290814f3e0c8@oracle.com> Message-ID: Thanks for the feedback~ Valerie On 8/18/2020 1:30 PM, Jamil Nimeh wrote: > From just a quick skimming across a few FIPS specs, it looks like DSA > with SHA-3 seems worth including.? FIPS 202 is designed to supplement > the hash algs in 180-4, and Section 2.3 of 186-4 indicates that > SHAx(M) is intended for those algs specified in 180 (and I assume by > extension 202).? Since there are OIDs in the NIST arc for > dsa-with-sha3-nnn it seems like all the pieces have specification > support.? Seems like a good thing to do. > > --Jamil > > On 8/18/2020 1:11 PM, Valerie Peng wrote: >> >> Can someone help review this SHA-3 based signature support? Note that >> changes to SunPKCS11 provider will be covered by a separate RFE >> (JDK-8244154). Current webrev adds SHA-3 digest support to DSA, RSA, >> ECDSA signature algorithms. I am a bit on the fence for the DSA >> signature and am including it here mostly for completeness sake. Can >> remove it if that's preferred. Comments? >> >> Will file a CSR for this once we reached consensus on whether to add >> SHA-3 support to DSA signature. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8172366 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8172366/webrev.00/ >> >> Thanks, >> Valerie From xuelei.fan at oracle.com Wed Aug 19 05:13:42 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 18 Aug 2020 22:13:42 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> Message-ID: <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> On 8/18/2020 2:43 PM, Valerie Peng wrote: > > Using a shared instance is surely faster. However, the API specified > that the most preferred SecureRandom impl will be used. To ensure this > for all scenarios, creating default SecureRandom obj will provide > correct result but shared instance may not. I understand your point. It might not break the spec if a shared instance is used. It depends on the understanding of "most preferred SecureRandom impl" in the context. > Apps can call other init > functions which takes SecureRandom objects to avoid this default > SecureRandom obj creation if needed. > Yes, it's an alternative solution. If an application used the default SecureRandom, it would be nice if there is no performance regression. The SecureRandom initialization may be not cheap in some circumstances. As this bug did not complain about the use of shared instance, it may be fine if we want to avoid the performance impact if the impact exists. Just for your consideration. Xuelei > Valerie > > On 8/18/2020 2:10 PM, Xuelei Fan wrote: >> Is there any performance impact? >> >> Xuelei >> >> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>> >>> Anyone has cycles to review this somewhat trivial changes? >>> JceSecurity has this shared SecureRandom instance which may lead to >>> NPE when certain 3rd party JCE provider is set as most preferred. >>> Removing this shared instance and change to create default >>> SecureRandom obj when needed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>> >>> Thanks, >>> Valerie From sean.mullan at oracle.com Wed Aug 19 12:47:31 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Aug 2020 08:47:31 -0400 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> Message-ID: <6baadbd8-6297-ee48-8b76-d00d54abf842@oracle.com> In the bug report, the following fix was suggested: "The fix to the issue should be simple, just move the initialization of the verificationResults Map BEFORE the SecureRandom initialization in JceSecurity.java" Does that not work for some reason? --Sean On 8/19/20 1:13 AM, Xuelei Fan wrote: > On 8/18/2020 2:43 PM, Valerie Peng wrote: >> >> Using a shared instance is surely faster. However, the API specified >> that the most preferred SecureRandom impl will be used. To ensure this >> for all scenarios, creating default SecureRandom obj will provide >> correct result but shared instance may not. > I understand your point.? It might not break the spec if a shared > instance is used.? It depends on the understanding of "most preferred > SecureRandom impl" in the context. > > >> Apps can call other init functions which takes SecureRandom objects to >> avoid this default SecureRandom obj creation if needed. >> > Yes, it's an alternative solution.? If an application used the default > SecureRandom, it would be nice if there is no performance regression. > > The SecureRandom initialization may be not cheap in some circumstances. > As this bug did not complain about the use of shared instance, it may be > fine if we want to avoid the performance impact if the impact exists. > > Just for your consideration. > > Xuelei > >> Valerie >> >> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>> Is there any performance impact? >>> >>> Xuelei >>> >>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>> >>>> Anyone has cycles to review this somewhat trivial changes? >>>> JceSecurity has this shared SecureRandom instance which may lead to >>>> NPE when certain 3rd party JCE provider is set as most preferred. >>>> Removing this shared instance and change to create default >>>> SecureRandom obj when needed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From Roger.Riggs at oracle.com Wed Aug 19 15:40:44 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 19 Aug 2020 11:40:44 -0400 Subject: Fix for Javadoc errors in java.base In-Reply-To: <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> References: <318a4bbf-1b3e-d34e-d69a-d1a2ee233794@oracle.com> <8e978983-4ec1-8421-2563-d00c61f0d55e@oracle.com> <11adede2-1119-f133-020f-4ddd60c9fc67@oracle.com> <6b31a7d4-3bcd-2c8d-2f3c-4158047c3e31@oracle.com> Message-ID: <00ffb7f0-5301-1f34-93e7-8e3249845434@oracle.com> Looks fine Julia On 8/18/20 1:02 PM, Julia Boes wrote: > > Hi, > > The two changes below still need to be reviewed. Any takers? > > Cheers, > > Julia > >> --- >> old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.953638446 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14 >> 23:55:41.445619497 +0530 >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2012, 2020, 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 >> @@ -208,7 +208,7 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> + ? ? * @throws LambdaConversionException >> ? ? ? */ >> ? ? ?abstract CallSite buildCallSite() >> ? ? ? ? ? ? ?throws LambdaConversionException; >> --- >> old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.977677096 +0530 >> +++ >> new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java2020-08-14 >> 23:55:42.473658062 +0530 >> @@ -200,7 +200,6 @@ >> ? ? ? * >> ? ? ? * @return a CallSite, which, when invoked, will return an >> instance of the >> ? ? ? * functional interface >> - ? ? * @throws ReflectiveOperationException >> ? ? ? * @throws LambdaConversionException If properly formed >> functional interface >> ? ? ? * is not found >> ? ? ? */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Aug 19 17:46:13 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Aug 2020 10:46:13 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <6baadbd8-6297-ee48-8b76-d00d54abf842@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <6baadbd8-6297-ee48-8b76-d00d54abf842@oracle.com> Message-ID: I don't feel it's the right fix, but rather just a workaround... A better workaround would be to switch to "JCAUtil.getSecureRandom()" instead of JceSecurity.RANDOM. ;) Valerie On 8/19/2020 5:47 AM, Sean Mullan wrote: > In the bug report, the following fix was suggested: > > "The fix to the issue should be simple, just move the initialization > of the verificationResults Map BEFORE the SecureRandom initialization > in JceSecurity.java" > > Does that not work for some reason? > > --Sean > > On 8/19/20 1:13 AM, Xuelei Fan wrote: >> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>> >>> Using a shared instance is surely faster. However, the API specified >>> that the most preferred SecureRandom impl will be used. To ensure >>> this for all scenarios, creating default SecureRandom obj will >>> provide correct result but shared instance may not. >> I understand your point.? It might not break the spec if a shared >> instance is used.? It depends on the understanding of "most preferred >> SecureRandom impl" in the context. >> >> >>> Apps can call other init functions which takes SecureRandom objects >>> to avoid this default SecureRandom obj creation if needed. >>> >> Yes, it's an alternative solution.? If an application used the >> default SecureRandom, it would be nice if there is no performance >> regression. >> >> The SecureRandom initialization may be not cheap in some >> circumstances. As this bug did not complain about the use of shared >> instance, it may be fine if we want to avoid the performance impact >> if the impact exists. >> >> Just for your consideration. >> >> Xuelei >> >>> Valerie >>> >>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>> Is there any performance impact? >>>> >>>> Xuelei >>>> >>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has cycles to review this somewhat trivial changes? >>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>> to NPE when certain 3rd party JCE provider is set as most >>>>> preferred. Removing this shared instance and change to create >>>>> default SecureRandom obj when needed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From valerie.peng at oracle.com Wed Aug 19 18:20:53 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Aug 2020 11:20:53 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> Message-ID: <09361e75-9c0f-8da4-a6c9-a710fc35ac23@oracle.com> Hi Xuelei, Please find comments in line. On 8/18/2020 10:13 PM, Xuelei Fan wrote: > On 8/18/2020 2:43 PM, Valerie Peng wrote: >> >> Using a shared instance is surely faster. However, the API specified >> that the most preferred SecureRandom impl will be used. To ensure >> this for all scenarios, creating default SecureRandom obj will >> provide correct result but shared instance may not. > I understand your point.? It might not break the spec if a shared > instance is used.? It depends on the understanding of "most preferred > SecureRandom impl" in the context. My reading of the spec is more strict I guess. I went back and force from 2 approaches, one is to use the slow "new SecureRandom()", the other is to still use a shared instance (located elsewhele instead of the sensitive JceSecurity class which is used when verifying JCE providers). The former is slow but correct at all times, the later can be correct as long as there are no provider changes after the first call. >> Apps can call other init functions which takes SecureRandom objects >> to avoid this default SecureRandom obj creation if needed. >> > Yes, it's an alternative solution.? If an application used the default > SecureRandom, it would be nice if there is no performance regression. > > The SecureRandom initialization may be not cheap in some > circumstances. As this bug did not complain about the use of shared > instance, it may be fine if we want to avoid the performance impact if > the impact exists. Yes, I ran a test to profile the numbers. It's a painful decision to go with "new SecureRandom()"... I can change to my other approach of using JCAUtil.getSecureRandom() depending on Sean's feedback. Thanks, Valerie > > Just for your consideration. > > Xuelei > >> Valerie >> >> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>> Is there any performance impact? >>> >>> Xuelei >>> >>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>> >>>> Anyone has cycles to review this somewhat trivial changes? >>>> JceSecurity has this shared SecureRandom instance which may lead to >>>> NPE when certain 3rd party JCE provider is set as most preferred. >>>> Removing this shared instance and change to create default >>>> SecureRandom obj when needed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From hots.alkan at gmail.com Wed Aug 19 21:46:15 2020 From: hots.alkan at gmail.com (Alkanor Oumbratok) Date: Wed, 19 Aug 2020 23:46:15 +0200 Subject: Recent Java Sandbox escapes Message-ID: Hello people, I am kind of new to this kind of mailing list, so do not hesitate to indicate to me if I have any inappropriate behavior (even if I hope it should not be the case). I recently came upon Java and Java security related aspects, mostly around the SecurityManager and what orbits around. To be precise, I am currently analysing old exploits against the Java sandbox, and trying to understand how freshly discovered exploits within the Java core libraries could be implemented. A logic thought made me search for recently applied patches for high severity CVSS targeting the Java core libraries. So, I came to the CVE CVE-2020-2803 and CVE-2020-2805. However, when observing the two associated patches, I wonder if these are really exploitable, and more generally, who and what is the process which decides the CVSS score of this kind of vulnerability. I explain myself : on the patch for CVE-2020-2803, one can see the position and limit variables are not relatively checked when creating a new *Buffer within the "slice" method. This indeed leads to a potentially undefined behavior. However, the only objects on which this can have an impact are, correctly if I am wrong, the associated native java arrays (like the double hb[] array for HeapDoubleBuffer). And there is no chance any dangerous effect comes from there, as an OutOfBoundException will be raised if any bound is wrong at the end. It would have been different if the same principle can be applied to Direct*Buffer, as these seem to have more impact on raw memory. However, these buffers are not vulnerable in their splice method due to the checks being performed. Am I right for this one ? Concerning the CVE-2020-2805, I must admit I am less confident of what I say regarding the previous one. For me, the patch gives the impression to force a certain MethodType to be in cache instead of "letting" the rtype and ptypes variables possibly being externally modified before readResolve is called (leading to the potential mentioned impact). However, I don't see any way of how these attributes could be modified between the call to ReadObject and the following call to ReadResolve, which should be performed immediately after. I may be wrong on both points, and I would be really grateful if someone could explain why these 2 CVE have been rated this high whereas at first glance there isn't any really exploitable related scenario. Regards, -- Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Gray at entrustdatacard.com Thu Aug 20 13:18:11 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Thu, 20 Aug 2020 13:18:11 +0000 Subject: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <6baadbd8-6297-ee48-8b76-d00d54abf842@oracle.com> Message-ID: Thanks for looking at this issue. I had suggested the simple fix as a way to remove the NPE during initialization, but if you think there are other places where this circular logic could crop up again (or could be easily introduced in the future) then I would agree an alternate fix could be better. Just as long as it isn't too complicated and doesn't break anything else... ?? Cheers, John Gray Entrust Datacard -----Original Message----- From: security-dev On Behalf Of Valerie Peng Sent: Wednesday, August 19, 2020 1:46 PM To: Sean Mullan ; Xuelei Fan ; OpenJDK Dev list Subject: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. I don't feel it's the right fix, but rather just a workaround... A better workaround would be to switch to "JCAUtil.getSecureRandom()" instead of JceSecurity.RANDOM. ;) Valerie On 8/19/2020 5:47 AM, Sean Mullan wrote: > In the bug report, the following fix was suggested: > > "The fix to the issue should be simple, just move the initialization > of the verificationResults Map BEFORE the SecureRandom initialization > in JceSecurity.java" > > Does that not work for some reason? > > --Sean > > On 8/19/20 1:13 AM, Xuelei Fan wrote: >> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>> >>> Using a shared instance is surely faster. However, the API specified >>> that the most preferred SecureRandom impl will be used. To ensure >>> this for all scenarios, creating default SecureRandom obj will >>> provide correct result but shared instance may not. >> I understand your point.? It might not break the spec if a shared >> instance is used.? It depends on the understanding of "most preferred >> SecureRandom impl" in the context. >> >> >>> Apps can call other init functions which takes SecureRandom objects >>> to avoid this default SecureRandom obj creation if needed. >>> >> Yes, it's an alternative solution.? If an application used the >> default SecureRandom, it would be nice if there is no performance >> regression. >> >> The SecureRandom initialization may be not cheap in some >> circumstances. As this bug did not complain about the use of shared >> instance, it may be fine if we want to avoid the performance impact >> if the impact exists. >> >> Just for your consideration. >> >> Xuelei >> >>> Valerie >>> >>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>> Is there any performance impact? >>>> >>>> Xuelei >>>> >>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has cycles to review this somewhat trivial changes? >>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>> to NPE when certain 3rd party JCE provider is set as most >>>>> preferred. Removing this shared instance and change to create >>>>> default SecureRandom obj when needed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From Roger.Riggs at oracle.com Thu Aug 20 15:14:05 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 20 Aug 2020 11:14:05 -0400 Subject: RFR 8252055: Use java.util.Hex encoder and decoder in java.security In-Reply-To: <6743da26-9bae-e868-d242-b359aeec3d21@oracle.com> References: <6743da26-9bae-e868-d242-b359aeec3d21@oracle.com> Message-ID: <0b654cb9-0602-489c-ef41-15e11724c5b8@oracle.com> Please review using the java.util.Hex api in security related classes. (The review of the API is being done on the core-libs-dev at openjdk.java.net). Within the JDK and JDK tests there are multiple implementations to encode and decode hexadecimal strings to byte arrays. Hex encoders and decoders support upper or lower case hexadecimal characters, delimiters, prefix, and suffix. The API is modeled after the java.util.Base64 API providing static factories, immutable threadsafe instances with methods to encode to and decode from string and StringBuilder. Webrev for applying to java.security: ?? http://cr.openjdk.java.net/~rriggs/webrev-hex-security-8252055 Issue for Use in java.security and tests: ?? https://bugs.openjdk.java.net/browse/JDK-8252055 Thanks, Roger p.s. JavaDoc for java.util.Hex: http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html Webrev for Hex encoder and decoder: ?? http://cr.openjdk.java.net/~rriggs/webrev-hex-encoder-8251989 CSR: ?? https://bugs.openjdk.java.net/browse/JDK-8251991 Issue for API and a few uses: ?? https://bugs.openjdk.java.net/browse/JDK-8251989 From valerie.peng at oracle.com Thu Aug 20 17:05:56 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 20 Aug 2020 10:05:56 -0700 Subject: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <6baadbd8-6297-ee48-8b76-d00d54abf842@oracle.com> Message-ID: Yes, thanks for the suggested fix. It's a good starting point. :) Regards, Valerie On 8/20/2020 6:18 AM, John Gray wrote: > Thanks for looking at this issue. > > I had suggested the simple fix as a way to remove the NPE during initialization, but if you think there are other places where this circular logic could crop up again (or could be easily introduced in the future) then I would agree an alternate fix could be better. Just as long as it isn't too complicated and doesn't break anything else... ?? > > Cheers, > > John Gray > Entrust Datacard > > -----Original Message----- > From: security-dev On Behalf Of Valerie Peng > Sent: Wednesday, August 19, 2020 1:46 PM > To: Sean Mullan ; Xuelei Fan ; OpenJDK Dev list > Subject: [EXTERNAL]Re: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > > I don't feel it's the right fix, but rather just a workaround... > > A better workaround would be to switch to "JCAUtil.getSecureRandom()" > instead of JceSecurity.RANDOM. ;) > > Valerie > > On 8/19/2020 5:47 AM, Sean Mullan wrote: >> In the bug report, the following fix was suggested: >> >> "The fix to the issue should be simple, just move the initialization >> of the verificationResults Map BEFORE the SecureRandom initialization >> in JceSecurity.java" >> >> Does that not work for some reason? >> >> --Sean >> >> On 8/19/20 1:13 AM, Xuelei Fan wrote: >>> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>>> Using a shared instance is surely faster. However, the API specified >>>> that the most preferred SecureRandom impl will be used. To ensure >>>> this for all scenarios, creating default SecureRandom obj will >>>> provide correct result but shared instance may not. >>> I understand your point.? It might not break the spec if a shared >>> instance is used.? It depends on the understanding of "most preferred >>> SecureRandom impl" in the context. >>> >>> >>>> Apps can call other init functions which takes SecureRandom objects >>>> to avoid this default SecureRandom obj creation if needed. >>>> >>> Yes, it's an alternative solution.? If an application used the >>> default SecureRandom, it would be nice if there is no performance >>> regression. >>> >>> The SecureRandom initialization may be not cheap in some >>> circumstances. As this bug did not complain about the use of shared >>> instance, it may be fine if we want to avoid the performance impact >>> if the impact exists. >>> >>> Just for your consideration. >>> >>> Xuelei >>> >>>> Valerie >>>> >>>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>>> Is there any performance impact? >>>>> >>>>> Xuelei >>>>> >>>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>>> Anyone has cycles to review this somewhat trivial changes? >>>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>>> to NPE when certain 3rd party JCE provider is set as most >>>>>> preferred. Removing this shared instance and change to create >>>>>> default SecureRandom obj when needed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie From valerie.peng at oracle.com Thu Aug 20 20:28:28 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 20 Aug 2020 13:28:28 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <09361e75-9c0f-8da4-a6c9-a710fc35ac23@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <09361e75-9c0f-8da4-a6c9-a710fc35ac23@oracle.com> Message-ID: <54efe1fd-4f1d-857f-d7cc-299fc59dc444@oracle.com> Updated to use the "JCAUtil.getSecureRandom()" call: http://cr.openjdk.java.net/~valeriep/8246383/webrev.01/ Thanks, Valerie On 8/19/2020 11:20 AM, Valerie Peng wrote: > Hi Xuelei, > > Please find comments in line. > > On 8/18/2020 10:13 PM, Xuelei Fan wrote: >> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>> >>> Using a shared instance is surely faster. However, the API specified >>> that the most preferred SecureRandom impl will be used. To ensure >>> this for all scenarios, creating default SecureRandom obj will >>> provide correct result but shared instance may not. >> I understand your point.? It might not break the spec if a shared >> instance is used.? It depends on the understanding of "most preferred >> SecureRandom impl" in the context. > > My reading of the spec is more strict I guess. I went back and force > from 2 approaches, one is to use the slow "new SecureRandom()", the > other is to still use a shared instance (located elsewhele instead of > the sensitive JceSecurity class which is used when verifying JCE > providers). The former is slow but correct at all times, the later can > be correct as long as there are no provider changes after the first call. > >>> Apps can call other init functions which takes SecureRandom objects >>> to avoid this default SecureRandom obj creation if needed. >>> >> Yes, it's an alternative solution.? If an application used the >> default SecureRandom, it would be nice if there is no performance >> regression. >> >> The SecureRandom initialization may be not cheap in some >> circumstances. As this bug did not complain about the use of shared >> instance, it may be fine if we want to avoid the performance impact >> if the impact exists. > > Yes, I ran a test to profile the numbers. It's a painful decision to > go with "new SecureRandom()"... > > I can change to my other approach of using JCAUtil.getSecureRandom() > depending on Sean's feedback. > > Thanks, > Valerie > > >> >> Just for your consideration. >> >> Xuelei >> >>> Valerie >>> >>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>> Is there any performance impact? >>>> >>>> Xuelei >>>> >>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>> >>>>> Anyone has cycles to review this somewhat trivial changes? >>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>> to NPE when certain 3rd party JCE provider is set as most >>>>> preferred. Removing this shared instance and change to create >>>>> default SecureRandom obj when needed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From xuelei.fan at oracle.com Thu Aug 20 20:49:13 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Aug 2020 13:49:13 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <54efe1fd-4f1d-857f-d7cc-299fc59dc444@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <09361e75-9c0f-8da4-a6c9-a710fc35ac23@oracle.com> <54efe1fd-4f1d-857f-d7cc-299fc59dc444@oracle.com> Message-ID: <3663aa37-5cbb-c89f-b7ee-5021e0a7d319@oracle.com> Looks good to me. Thanks! Xuelei On 8/20/2020 1:28 PM, Valerie Peng wrote: > Updated to use the "JCAUtil.getSecureRandom()" call: > > http://cr.openjdk.java.net/~valeriep/8246383/webrev.01/ > > Thanks, > Valerie > > On 8/19/2020 11:20 AM, Valerie Peng wrote: > >> Hi Xuelei, >> >> Please find comments in line. >> >> On 8/18/2020 10:13 PM, Xuelei Fan wrote: >>> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>>> >>>> Using a shared instance is surely faster. However, the API specified >>>> that the most preferred SecureRandom impl will be used. To ensure >>>> this for all scenarios, creating default SecureRandom obj will >>>> provide correct result but shared instance may not. >>> I understand your point.? It might not break the spec if a shared >>> instance is used.? It depends on the understanding of "most preferred >>> SecureRandom impl" in the context. >> >> My reading of the spec is more strict I guess. I went back and force >> from 2 approaches, one is to use the slow "new SecureRandom()", the >> other is to still use a shared instance (located elsewhele instead of >> the sensitive JceSecurity class which is used when verifying JCE >> providers). The former is slow but correct at all times, the later can >> be correct as long as there are no provider changes after the first call. >> >>>> Apps can call other init functions which takes SecureRandom objects >>>> to avoid this default SecureRandom obj creation if needed. >>>> >>> Yes, it's an alternative solution.? If an application used the >>> default SecureRandom, it would be nice if there is no performance >>> regression. >>> >>> The SecureRandom initialization may be not cheap in some >>> circumstances. As this bug did not complain about the use of shared >>> instance, it may be fine if we want to avoid the performance impact >>> if the impact exists. >> >> Yes, I ran a test to profile the numbers. It's a painful decision to >> go with "new SecureRandom()"... >> >> I can change to my other approach of using JCAUtil.getSecureRandom() >> depending on Sean's feedback. >> >> Thanks, >> Valerie >> >> >>> >>> Just for your consideration. >>> >>> Xuelei >>> >>>> Valerie >>>> >>>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>>> Is there any performance impact? >>>>> >>>>> Xuelei >>>>> >>>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>>> >>>>>> Anyone has cycles to review this somewhat trivial changes? >>>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>>> to NPE when certain 3rd party JCE provider is set as most >>>>>> preferred. Removing this shared instance and change to create >>>>>> default SecureRandom obj when needed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie From valerie.peng at oracle.com Fri Aug 21 00:34:46 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 20 Aug 2020 17:34:46 -0700 Subject: [16] RFR JDK-8246383: NullPointerException in JceSecurity.getVerificationResult when using Entrust provider In-Reply-To: <3663aa37-5cbb-c89f-b7ee-5021e0a7d319@oracle.com> References: <6f8a42be-3b83-33dc-c125-815fdbf840c6@oracle.com> <0173c962-7de5-229a-856e-f8bec09b2e5d@oracle.com> <5f139f37-0bda-eec7-7663-057ecc78202b@oracle.com> <09361e75-9c0f-8da4-a6c9-a710fc35ac23@oracle.com> <54efe1fd-4f1d-857f-d7cc-299fc59dc444@oracle.com> <3663aa37-5cbb-c89f-b7ee-5021e0a7d319@oracle.com> Message-ID: Thanks for the review~ Valerie On 8/20/2020 1:49 PM, Xuelei Fan wrote: > Looks good to me.? Thanks! > > Xuelei > > On 8/20/2020 1:28 PM, Valerie Peng wrote: >> Updated to use the "JCAUtil.getSecureRandom()" call: >> >> http://cr.openjdk.java.net/~valeriep/8246383/webrev.01/ >> >> Thanks, >> Valerie >> >> On 8/19/2020 11:20 AM, Valerie Peng wrote: >> >>> Hi Xuelei, >>> >>> Please find comments in line. >>> >>> On 8/18/2020 10:13 PM, Xuelei Fan wrote: >>>> On 8/18/2020 2:43 PM, Valerie Peng wrote: >>>>> >>>>> Using a shared instance is surely faster. However, the API >>>>> specified that the most preferred SecureRandom impl will be used. >>>>> To ensure this for all scenarios, creating default SecureRandom >>>>> obj will provide correct result but shared instance may not. >>>> I understand your point.? It might not break the spec if a shared >>>> instance is used.? It depends on the understanding of "most >>>> preferred SecureRandom impl" in the context. >>> >>> My reading of the spec is more strict I guess. I went back and force >>> from 2 approaches, one is to use the slow "new SecureRandom()", the >>> other is to still use a shared instance (located elsewhele instead >>> of the sensitive JceSecurity class which is used when verifying JCE >>> providers). The former is slow but correct at all times, the later >>> can be correct as long as there are no provider changes after the >>> first call. >>> >>>>> Apps can call other init functions which takes SecureRandom >>>>> objects to avoid this default SecureRandom obj creation if needed. >>>>> >>>> Yes, it's an alternative solution.? If an application used the >>>> default SecureRandom, it would be nice if there is no performance >>>> regression. >>>> >>>> The SecureRandom initialization may be not cheap in some >>>> circumstances. As this bug did not complain about the use of shared >>>> instance, it may be fine if we want to avoid the performance impact >>>> if the impact exists. >>> >>> Yes, I ran a test to profile the numbers. It's a painful decision to >>> go with "new SecureRandom()"... >>> >>> I can change to my other approach of using JCAUtil.getSecureRandom() >>> depending on Sean's feedback. >>> >>> Thanks, >>> Valerie >>> >>> >>>> >>>> Just for your consideration. >>>> >>>> Xuelei >>>> >>>>> Valerie >>>>> >>>>> On 8/18/2020 2:10 PM, Xuelei Fan wrote: >>>>>> Is there any performance impact? >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 8/18/2020 12:51 PM, Valerie Peng wrote: >>>>>>> >>>>>>> Anyone has cycles to review this somewhat trivial changes? >>>>>>> JceSecurity has this shared SecureRandom instance which may lead >>>>>>> to NPE when certain 3rd party JCE provider is set as most >>>>>>> preferred. Removing this shared instance and change to create >>>>>>> default SecureRandom obj when needed. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246383 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246383/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie From sean.mullan at oracle.com Fri Aug 21 16:24:38 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Aug 2020 12:24:38 -0400 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> Message-ID: Ping ... On 8/7/20 10:01 AM, Sean Mullan wrote: > Please review this change to deprecate the following APIs: > > java.security.cert.X509Certificate.getIssuerDN() > java.security.cert.X509Certificate.getSubjectDN() > java.security.cert.X509CRL.getIssuerDN() > java.security.cert.X509CertSelector.setIssuer(String) > java.security.cert.X509CertSelector.setSubject(String) > java.security.cert.X509CertSelector.getIssuerAsString() > java.security.cert.X509CertSelector.getSubjectAsString() > java.security.cert.X509CRLSelector.addIssuerName(String) > > These APIs either take or return Distinguished Names as Principal or > String objects which can cause issues due to loss of encoding > information or differences when comparing names across different > Principal implementations. All of them have alternative APIs which use > X500Principal objects instead. They have long had warnings in the > javadoc and have been discouraged from being used. There are no plans to > remove the APIs at this time, as they have been in the platform for a > long time and removing them would be a much higher compatibility risk. > > webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 > bug: https://bugs.openjdk.java.net/browse/JDK-8241003 > > --Sean From xuelei.fan at oracle.com Fri Aug 21 18:01:24 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Aug 2020 11:01:24 -0700 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> Message-ID: Looks fine to me. Just a trivial format comment. Some use link for "RFC 2253", some do not. It's OK. And it's good as well if you want to use a uniform style. Xuelei On 8/21/2020 9:24 AM, Sean Mullan wrote: > Ping ... > > On 8/7/20 10:01 AM, Sean Mullan wrote: >> Please review this change to deprecate the following APIs: >> >> java.security.cert.X509Certificate.getIssuerDN() >> java.security.cert.X509Certificate.getSubjectDN() >> java.security.cert.X509CRL.getIssuerDN() >> java.security.cert.X509CertSelector.setIssuer(String) >> java.security.cert.X509CertSelector.setSubject(String) >> java.security.cert.X509CertSelector.getIssuerAsString() >> java.security.cert.X509CertSelector.getSubjectAsString() >> java.security.cert.X509CRLSelector.addIssuerName(String) >> >> These APIs either take or return Distinguished Names as Principal or >> String objects which can cause issues due to loss of encoding >> information or differences when comparing names across different >> Principal implementations. All of them have alternative APIs which use >> X500Principal objects instead. They have long had warnings in the >> javadoc and have been discouraged from being used. There are no plans >> to remove the APIs at this time, as they have been in the platform for >> a long time and removing them would be a much higher compatibility risk. >> >> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 >> bug: https://bugs.openjdk.java.net/browse/JDK-8241003 >> >> --Sean From valerie.peng at oracle.com Fri Aug 21 18:14:01 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 21 Aug 2020 11:14:01 -0700 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> Message-ID: <8da00928-38d2-0c46-b710-7204f75ab261@oracle.com> Is it intentional to use toString() in src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java? Normally, toString() is kind of loose, not as strict as getName(). Valerie On 8/21/2020 11:01 AM, Xuelei Fan wrote: > Looks fine to me. > > Just a trivial format comment.? Some use link for "RFC 2253", some do > not. It's OK.? And it's good as well if you want to use a uniform style. > > Xuelei > > On 8/21/2020 9:24 AM, Sean Mullan wrote: >> Ping ... >> >> On 8/7/20 10:01 AM, Sean Mullan wrote: >>> Please review this change to deprecate the following APIs: >>> >>> java.security.cert.X509Certificate.getIssuerDN() >>> java.security.cert.X509Certificate.getSubjectDN() >>> java.security.cert.X509CRL.getIssuerDN() >>> java.security.cert.X509CertSelector.setIssuer(String) >>> java.security.cert.X509CertSelector.setSubject(String) >>> java.security.cert.X509CertSelector.getIssuerAsString() >>> java.security.cert.X509CertSelector.getSubjectAsString() >>> java.security.cert.X509CRLSelector.addIssuerName(String) >>> >>> These APIs either take or return Distinguished Names as Principal or >>> String objects which can cause issues due to loss of encoding >>> information or differences when comparing names across different >>> Principal implementations. All of them have alternative APIs which >>> use X500Principal objects instead. They have long had warnings in >>> the javadoc and have been discouraged from being used. There are no >>> plans to remove the APIs at this time, as they have been in the >>> platform for a long time and removing them would be a much higher >>> compatibility risk. >>> >>> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8241003 >>> >>> --Sean From John.Gray at entrustdatacard.com Fri Aug 21 20:12:12 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Fri, 21 Aug 2020 20:12:12 +0000 Subject: How to backports make it into openJDK? Message-ID: Hello, I have a question on how the backport process works. Some of my colleagues at Entrust noted that JDK-8180834 was backported to the Oracle 7u191 b31 release (https://www.oracle.com/java/technologies/javase/7-support-relnotes.html#7u191-b31). Essentially it adds GCM Ciphersuite support into JDK 7. I was able to download 7u191 from Oracle?s support site and verified GCM cipher suites are working. However, they want to make use of OpenJDK 7, but it appears OpenJDK 7u191 (and later versions) do not contain the backport. We noticed a couple of things. The fix for JDK-8180834 says it is in ?branch master? of openjdk 7 (CipherSuite.java). If you check the line referenced in this link it says (Unsupported cipher suites from RFC 5289) [RFC5289]. This is the changeset that openjdk made to support GCM in JDK8, If you look at the changes in CipherSuite.java the unsupported GCM cipher suites are now implemented. In the comments of issue JDK-8180834 it says ?Pushed changes to Master?, but what master? Is it a private master? The issue says it is resolved, but it is not closed. These things make us suspect that the changes are not in OpenJDK. Do changes made in master not get automatically picked up by OpenJDK? Does the ?b31? imply a special side branch or is it a build number? What is the process for getting changes added to OpenJDK? Thanks, John Gray Entrust Datacard -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Mon Aug 24 11:55:38 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Mon, 24 Aug 2020 04:55:38 -0700 (PDT) Subject: How to backports make it into openJDK? In-Reply-To: References: Message-ID: <2ab1e1df-a340-431d-af10-1f204a88aec1@default> Hi, ? HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834: Backported to Oracle JDK, 7u191. OpenJDK 7u maintainers are best to answer backport process and OpenJDK 7u porting discussions are best discussed on?HYPERLINK "mailto:jdk7u-dev at openjdk.java.net"jdk7u-dev at openjdk.java.net ? Thanks, Prasad.K ? From: John Gray [mailto:John.Gray at entrustdatacard.com] Sent: Saturday, August 22, 2020 1:42 AM To: OpenJDK Dev list Cc: Jonatan Guill?n ; Carlos Ares Subject: How to backports make it into openJDK? ? Hello,? ? I have a question on how the backport process works.?? Some of my colleagues at Entrust noted that HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 was backported to the Oracle 7u191 b31 release (https://www.oracle.com/java/technologies/javase/7-support-relnotes.html#7u191-b31). ?Essentially it adds GCM Ciphersuite support into JDK 7. ??I was able to download 7u191 from Oracle?s support site and verified GCM cipher suites are working. ? However, they want to make use of OpenJDK 7, but it appears OpenJDK 7u191 (and later versions) do not contain the backport.? ? We noticed a couple of things.?? The fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 ?says it is in ?branch master? of openjdk 7 (HYPERLINK "https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/tip/src/share/classes/sun/security/ssl/CipherSuite.java#l1316"CipherSuite.java). ?If you check the line referenced in this link it says (Unsupported cipher suites from RFC 5289) [HYPERLINK "https://tools.ietf.org/html/rfc5289"RFC5289].?? This is the HYPERLINK "http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/def2e05299b7"changeset that openjdk made to support GCM in JDK8, If you look at the changes in HYPERLINK "http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/diff/def2e05299b7/src/share/classes/sun/security/ssl/CipherSuite.java"CipherSuite.java the unsupported GCM cipher suites are now implemented.? In the comments of issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8180834"JDK-8180834 it says ?Pushed changes to Master?, but what master? Is it a private master? ?The issue says it is resolved, but it is not closed.? ??These things make us suspect that the changes are not in OpenJDK.??? ? Do changes made in master not get automatically picked up by OpenJDK??? Does the ?b31? imply a special side branch or is it a build number? ?What is the process for getting changes added to OpenJDK? ? Thanks, ? John Gray Entrust Datacard ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Mon Aug 24 13:50:14 2020 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 24 Aug 2020 15:50:14 +0200 Subject: "Blocking operation" during SSLEngineImpl.unwrap() In-Reply-To: <3aecda11-814a-772e-3e52-4915263339d7@oracle.com> References: <1748e9a9-5cf7-d014-7725-4194a99ce902@oracle.com> <42e2e845-4f5b-bf93-a91f-047c22a47043@oracle.com> <3aecda11-814a-772e-3e52-4915263339d7@oracle.com> Message-ID: Not that I am aware of. I will look into it later this week again and report back. Bye Norman > On 18. Aug 2020, at 02:21, Bradford Wetmore wrote: > > > Hi Norman, > > There are a couple things in the stack trace that don't make sense. Am I missing something? > > This looks like a server side trace, so the initialization of the RandomCookie should be inside the Task for the FINISHED message consumption, which kicks off the NewSessionTicket creation before ending. > > What version of the JDK is this stack trace from? I've looked at our current code and have gone back to our initial TLSv1.3 changeset in jdk-11+20, and I'm not seeing where the initialization of the RandomCookie could be done outside of the FINISHED TASK processing. > > By chance is Netty replacing any of our sun.security.ssl.SSLEngine code? > > Here's what the code should look like. > > "MainThread" > at sun.security.ssl.SessionId.(SessionId.java:45) > at sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:224) > at sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1134) > at sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:877) > at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) > at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) > at java.security.AccessController.doPrivileged(AccessController.java) > at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) > at SSLEngineTemplate.runDelegatedTasks(SSLEngineTemplate.java:317) > at SSLEngineTemplate.runTest(SSLEngineTemplate.java:225) > at SSLEngineTemplate.main(SSLEngineTemplate.java:136) > > Thanks, > > Brad > > > On 8/7/2020 11:24 AM, Alan Bateman wrote: >> On 07/08/2020 18:27, Anthony Scarpino wrote: >>> Well if there were a bug it's with NativePRNG as the operation is suppose to be non-blocking. Even so, /dev/urandom is nonblocking. The only reason this looks to have been detected by the tool is because it's a blocking read op. This all seems like an extremely unlikely situation. I don't see this as something SSLEngine should be compensating for. >> Right, /dev/random is blocking, /dev/urandom is non-blocking. I just checked BlockHound and it seems to have the names of private methods in the java.io and java.net classes and I think instruments these methods on the assumption that they are blocking calls. The list seems to have been generated from an older JDK too, not really in sync with release JDK releases. So not clear to me that there is really an issue here. >> -Alan From anders.rundgren.net at gmail.com Tue Aug 25 16:33:04 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 25 Aug 2020 18:33:04 +0200 Subject: keytool generates incorrect EC AlgorithmIdentifier Message-ID: The command ?keytool -genkeypair -keyalg ec -keysize 256 -dname "CN=me" -keystore mycert.jks using JDK 11 generates the following signature: 220:???? SEQUENCE ?????????? { 222:???????? OBJECT IDENTIFIER ecdsa-with-Sha256 (1.2.840.10045.4.3.2) 232:???????? NULL ?????????? } 234:???? BIT STRING, encapsulates ?????????? { 237:???????? SEQUENCE ?????????????? { 239:???????????? INTEGER ?????????????????? 71 51 7a 19 ac 22 92 ef 3b 6d f8 1c 5f d6 5f 89 ?????????????????? 3f 69 bf 84 aa ac a3 00 fb 3e 31 ef 3f b3 ea b4 273:???????????? INTEGER ?????????????????? 1a 07 d1 24 fd b8 1d c8 70 ca 0d ab 35 b1 d0 d5 ?????????????????? b6 e2 b7 d7 02 38 36 63 d6 db ff ea 7f f0 7d a9 ?????????????? } ?????????? } ?????? } AFAICT, "NULL" shouldn't be there although it in practice seems to be benign. I could be an idea to fix it for EdDSA which I guess suffers from the same problem. https://tools.ietf.org/html/rfc5758#section-3.2 Regards, Anders From xuelei.fan at oracle.com Tue Aug 25 20:28:06 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Aug 2020 13:28:06 -0700 Subject: RFR 8252055: Use java.util.Hex encoder and decoder in java.security In-Reply-To: <0b654cb9-0602-489c-ef41-15e11724c5b8@oracle.com> References: <6743da26-9bae-e868-d242-b359aeec3d21@oracle.com> <0b654cb9-0602-489c-ef41-15e11724c5b8@oracle.com> Message-ID: <4df0e892-3be2-2700-f573-a7548231ae34@oracle.com> Looks good to me. Thanks, Xuelei On 8/20/2020 8:14 AM, Roger Riggs wrote: > Please review using the java.util.Hex api in security related classes. > (The review of the API is being done on the > core-libs-dev at openjdk.java.net). > > Within the JDK and JDK tests there are multiple implementations to > encode and decode > hexadecimal strings to byte arrays. Hex encoders and decoders support > upper or lower case hexadecimal characters, delimiters, prefix, and suffix. > The API is modeled after the java.util.Base64 API providing static > factories, > immutable threadsafe instances with methods to encode to and decode from > string and StringBuilder. > > Webrev for applying to java.security: > ?? http://cr.openjdk.java.net/~rriggs/webrev-hex-security-8252055 > > Issue for Use in java.security and tests: > ?? https://bugs.openjdk.java.net/browse/JDK-8252055 > > Thanks, Roger > > p.s. > > JavaDoc for java.util.Hex: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html > > Webrev for Hex encoder and decoder: > ?? http://cr.openjdk.java.net/~rriggs/webrev-hex-encoder-8251989 > > CSR: > ?? https://bugs.openjdk.java.net/browse/JDK-8251991 > > Issue for API and a few uses: > ?? https://bugs.openjdk.java.net/browse/JDK-8251989 > > > From sean.mullan at oracle.com Tue Aug 25 20:35:09 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 25 Aug 2020 16:35:09 -0400 Subject: keytool generates incorrect EC AlgorithmIdentifier In-Reply-To: References: Message-ID: <5e6d724f-1678-24b1-cf8d-6bc30d75c86a@oracle.com> On 8/25/20 12:33 PM, Anders Rundgren wrote: > The command > ?keytool -genkeypair -keyalg ec -keysize 256 -dname "CN=me" -keystore > mycert.jks > using JDK 11 generates the following signature: > > 220:???? SEQUENCE > ?????????? { > 222:???????? OBJECT IDENTIFIER ecdsa-with-Sha256 (1.2.840.10045.4.3.2) > 232:???????? NULL > ?????????? } > 234:???? BIT STRING, encapsulates > ?????????? { > 237:???????? SEQUENCE > ?????????????? { > 239:???????????? INTEGER > ?????????????????? 71 51 7a 19 ac 22 92 ef 3b 6d f8 1c 5f d6 5f 89 > ?????????????????? 3f 69 bf 84 aa ac a3 00 fb 3e 31 ef 3f b3 ea b4 > 273:???????????? INTEGER > ?????????????????? 1a 07 d1 24 fd b8 1d c8 70 ca 0d ab 35 b1 d0 d5 > ?????????????????? b6 e2 b7 d7 02 38 36 63 d6 db ff ea 7f f0 7d a9 > ?????????????? } > ?????????? } > ?????? } > > AFAICT, "NULL" shouldn't be there although it in practice seems to be > benign > I could be an idea to fix it for EdDSA which I guess suffers from the > same problem. > > https://tools.ietf.org/html/rfc5758#section-3.2 Right. The RFC says: When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding MUST omit the parameters field. I'll file a bug. Did you test EdDSA? Looking at the latest JDK code, I see that EdDSA does not include NULL. --Sean From Roger.Riggs at oracle.com Tue Aug 25 20:47:13 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 25 Aug 2020 16:47:13 -0400 Subject: RFR 8252055: Use java.util.Hex encoder and decoder in java.security In-Reply-To: <4df0e892-3be2-2700-f573-a7548231ae34@oracle.com> References: <6743da26-9bae-e868-d242-b359aeec3d21@oracle.com> <0b654cb9-0602-489c-ef41-15e11724c5b8@oracle.com> <4df0e892-3be2-2700-f573-a7548231ae34@oracle.com> Message-ID: Thanks for taking a look. Due to comments on the API itself, there are going to be some API changes mostly due to naming of classes and methods. I'll update the review when the API changes settle. Thanks, Roger On 8/25/20 4:28 PM, Xuelei Fan wrote: > Looks good to me. > > Thanks, > Xuelei > > On 8/20/2020 8:14 AM, Roger Riggs wrote: >> Please review using the java.util.Hex api in security related classes. >> (The review of the API is being done on the >> core-libs-dev at openjdk.java.net). >> >> Within the JDK and JDK tests there are multiple implementations to >> encode and decode >> hexadecimal strings to byte arrays. Hex encoders and decoders support >> upper or lower case hexadecimal characters, delimiters, prefix, and >> suffix. >> The API is modeled after the java.util.Base64 API providing static >> factories, >> immutable threadsafe instances with methods to encode to and decode from >> string and StringBuilder. >> >> Webrev for applying to java.security: >> http://cr.openjdk.java.net/~rriggs/webrev-hex-security-8252055 >> >> Issue for Use in java.security and tests: >> ??? https://bugs.openjdk.java.net/browse/JDK-8252055 >> >> Thanks, Roger >> >> p.s. >> >> JavaDoc for java.util.Hex: >> http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html >> >> >> Webrev for Hex encoder and decoder: >> http://cr.openjdk.java.net/~rriggs/webrev-hex-encoder-8251989 >> >> CSR: >> ??? https://bugs.openjdk.java.net/browse/JDK-8251991 >> >> Issue for API and a few uses: >> ??? https://bugs.openjdk.java.net/browse/JDK-8251989 >> >> >> From sean.mullan at oracle.com Wed Aug 26 11:53:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Aug 2020 07:53:57 -0400 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> Message-ID: On 8/21/20 2:01 PM, Xuelei Fan wrote: > Looks fine to me. > > Just a trivial format comment.? Some use link for "RFC 2253", some do > not. It's OK.? And it's good as well if you want to use a uniform style. Good point. Several methods in X509CertSelector and X509CRLSelector reference RFC 2253 several times. I have changed them to be consistent so that the first reference in each method is a link to 2253, while the rest of them are text. --Sean > > Xuelei > > On 8/21/2020 9:24 AM, Sean Mullan wrote: >> Ping ... >> >> On 8/7/20 10:01 AM, Sean Mullan wrote: >>> Please review this change to deprecate the following APIs: >>> >>> java.security.cert.X509Certificate.getIssuerDN() >>> java.security.cert.X509Certificate.getSubjectDN() >>> java.security.cert.X509CRL.getIssuerDN() >>> java.security.cert.X509CertSelector.setIssuer(String) >>> java.security.cert.X509CertSelector.setSubject(String) >>> java.security.cert.X509CertSelector.getIssuerAsString() >>> java.security.cert.X509CertSelector.getSubjectAsString() >>> java.security.cert.X509CRLSelector.addIssuerName(String) >>> >>> These APIs either take or return Distinguished Names as Principal or >>> String objects which can cause issues due to loss of encoding >>> information or differences when comparing names across different >>> Principal implementations. All of them have alternative APIs which >>> use X500Principal objects instead. They have long had warnings in the >>> javadoc and have been discouraged from being used. There are no plans >>> to remove the APIs at this time, as they have been in the platform >>> for a long time and removing them would be a much higher >>> compatibility risk. >>> >>> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 >>> bug: https://bugs.openjdk.java.net/browse/JDK-8241003 >>> >>> --Sean From sean.mullan at oracle.com Wed Aug 26 12:02:57 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Aug 2020 08:02:57 -0400 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: <8da00928-38d2-0c46-b710-7204f75ab261@oracle.com> References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> <8da00928-38d2-0c46-b710-7204f75ab261@oracle.com> Message-ID: <8b963d43-e36e-8051-b8c9-6b8dfc590eca@oracle.com> On 8/21/20 2:14 PM, Valerie Peng wrote: > Is it intentional to use toString() in > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java? > Normally, toString() is kind of loose, not as strict as getName(). In this case I think toString() is ok, since jarsigner is printing information about the certificate. Also, I wanted the format to be compatible with the previous code just in case some script or something out there is parsing the format and expecting it to be the same. In the JDK implementation, X500Principal.toString calls X500Name.toString(). --Sean > > Valerie > > On 8/21/2020 11:01 AM, Xuelei Fan wrote: >> Looks fine to me. >> >> Just a trivial format comment.? Some use link for "RFC 2253", some do >> not. It's OK.? And it's good as well if you want to use a uniform style. >> >> Xuelei >> >> On 8/21/2020 9:24 AM, Sean Mullan wrote: >>> Ping ... >>> >>> On 8/7/20 10:01 AM, Sean Mullan wrote: >>>> Please review this change to deprecate the following APIs: >>>> >>>> java.security.cert.X509Certificate.getIssuerDN() >>>> java.security.cert.X509Certificate.getSubjectDN() >>>> java.security.cert.X509CRL.getIssuerDN() >>>> java.security.cert.X509CertSelector.setIssuer(String) >>>> java.security.cert.X509CertSelector.setSubject(String) >>>> java.security.cert.X509CertSelector.getIssuerAsString() >>>> java.security.cert.X509CertSelector.getSubjectAsString() >>>> java.security.cert.X509CRLSelector.addIssuerName(String) >>>> >>>> These APIs either take or return Distinguished Names as Principal or >>>> String objects which can cause issues due to loss of encoding >>>> information or differences when comparing names across different >>>> Principal implementations. All of them have alternative APIs which >>>> use X500Principal objects instead. They have long had warnings in >>>> the javadoc and have been discouraged from being used. There are no >>>> plans to remove the APIs at this time, as they have been in the >>>> platform for a long time and removing them would be a much higher >>>> compatibility risk. >>>> >>>> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241003 >>>> >>>> --Sean From RAJAN.HALADE at ORACLE.COM Wed Aug 26 17:13:30 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Wed, 26 Aug 2020 10:13:30 -0700 Subject: RFR: 8238157: Remove intermittent key from AmazonCA.java Message-ID: Please review this update to remove key intermittent from AmazonCA test. This test no longer fails intermittently. @@ -24,7 +24,6 @@ /* * @test * @bug 8233223 - * @key intermittent * @summary Interoperability tests with Amazon's CA1, CA2, CA3, and CA4 * @build ValidatePathWithParams * @run main/othervm -Djava.security.debug=certpath AmazonCA OCSP Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Aug 26 17:20:25 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 26 Aug 2020 10:20:25 -0700 Subject: RFR: 8238157: Remove intermittent key from AmazonCA.java In-Reply-To: References: Message-ID: <2ea36f9c-4678-edb6-594a-29278e4756c8@oracle.com> It's good. Thanks! Xuelei On 8/26/2020 10:13 AM, Rajan Halade wrote: > Please review this update to remove key intermittent from AmazonCA test. > This test no longer fails intermittently. > > @@ -24,7 +24,6 @@ > ?/* > ? * @test > ? * @bug 8233223 > *- * @key intermittent* > ? * @summary Interoperability tests with Amazon's CA1, CA2, CA3, and CA4 > ? * @build ValidatePathWithParams > ? * @run main/othervm -Djava.security.debug=certpath AmazonCA OCSP > > Thanks, > Rajan > From hai-may.chao at oracle.com Wed Aug 26 18:19:32 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Wed, 26 Aug 2020 11:19:32 -0700 Subject: RFR: 8238157: Remove intermittent key from AmazonCA.java In-Reply-To: References: Message-ID: Looks good. Thanks, Hai-May > On Aug 26, 2020, at 10:13 AM, Rajan Halade wrote: > > Please review this update to remove key intermittent from AmazonCA test. This test no longer fails intermittently. > > @@ -24,7 +24,6 @@ > /* > * @test > * @bug 8233223 > - * @key intermittent > * @summary Interoperability tests with Amazon's CA1, CA2, CA3, and CA4 > * @build ValidatePathWithParams > * @run main/othervm -Djava.security.debug=certpath AmazonCA OCSP > > Thanks, > Rajan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Aug 26 18:26:22 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 26 Aug 2020 19:26:22 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files Message-ID: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. https://bugs.openjdk.java.net/browse/JDK-8250968 http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From WEIJUN.WANG at ORACLE.COM Wed Aug 26 22:15:27 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Wed, 26 Aug 2020 18:15:27 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> Message-ID: <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> Are you going to update the warning text or create a new one? Thanks, Max > On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: > > This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. > > I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. > > https://bugs.openjdk.java.net/browse/JDK-8250968 > http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html > > regards, > Sean. > From sean.coffey at oracle.com Thu Aug 27 06:42:43 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 27 Aug 2020 07:42:43 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> Message-ID: <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> Hi Max, I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit then ? +??????? {"posix.attributes.detected", "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >> replace with: +??????? {"extra.attributes.detected", "POSIX file permission/symlink attributes detected. These attributes are ignored when signing and are not protected by the signature."}, regards, Sean. On 26/08/2020 23:15, Weijun Wang wrote: > Are you going to update the warning text or create a new one? > > Thanks, > Max > >> On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: >> >> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. >> >> I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. >> >> https://bugs.openjdk.java.net/browse/JDK-8250968 >> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >> >> regards, >> Sean. >> From sean.coffey at oracle.com Thu Aug 27 07:26:49 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 27 Aug 2020 08:26:49 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> Message-ID: updated webrev: http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ regards, Sean. On 27/08/2020 07:42, Se?n Coffey wrote: > Hi Max, > > I looked at updating the warning string but figured that it might have > been of no interest to end users. How about this edit then ? > > +??????? {"posix.attributes.detected", "POSIX file permission > attributes detected. These attributes are ignored when signing and are > not protected by the signature."}, > > >> replace with: > +??????? {"extra.attributes.detected", "POSIX file permission/symlink > attributes detected. These attributes are ignored when signing and are > not protected by the signature."}, > > regards, > Sean. > > On 26/08/2020 23:15, Weijun Wang wrote: >> Are you going to update the warning text or create a new one? >> >> Thanks, >> Max >> >>> On Aug 26, 2020, at 2:26 PM, Se?n Coffey >>> wrote: >>> >>> This is a follow on from the recent 8218021 fix. The jarsigner tool >>> removes symlink attribute data from zipfiles when signing them. >>> jarsigner should preserve this data. The fix involves preserving the >>> 16 bits associated with the file attributes (instead of the current >>> 12). That's done in ZipFile. All other changes are just a refactor >>> of the variable name. >>> >>> I haven't been able to automate a test for this since zipfs doesn't >>> seem to support symlinks. Manual testing looks good. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8250968 >>> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >>> >>> >>> regards, >>> Sean. >>> From WEIJUN.WANG at ORACLE.COM Thu Aug 27 13:45:40 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Thu, 27 Aug 2020 09:45:40 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> Message-ID: <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> I?m OK with using one warning, but prefer it to a little more formal like "POSIX file permission and/or symlink attributes detected??. One nit in ZipFile.java: 1098 // only set posix perms value via ZipEntry constructor for now 1099 @Override 1100 public int getExtraAttributes(ZipEntry ze) { Maybe you can just remove the comment. Do you also want to rename the ?posixPermsDetected" field and loacl variable ?perms? in JarSigner.java? I?m not sure about the test but if zipfs is able to keep permissions inside a zip file then that POSIX byte (or whatever it?s named) is already there and we can modify it to include more bits. No other comment. Thanks, Max > On Aug 27, 2020, at 3:26 AM, Se?n Coffey wrote: > > updated webrev: > http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ > > regards, > Sean. > > On 27/08/2020 07:42, Se?n Coffey wrote: >> Hi Max, >> >> I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit then ? >> >> + {"posix.attributes.detected", "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >> >> >> replace with: >> + {"extra.attributes.detected", "POSIX file permission/symlink attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >> >> regards, >> Sean. >> >> On 26/08/2020 23:15, Weijun Wang wrote: >>> Are you going to update the warning text or create a new one? >>> >>> Thanks, >>> Max >>> >>>> On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: >>>> >>>> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. >>>> >>>> I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8250968 >>>> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >>>> >>>> regards, >>>> Sean. >>>> From sean.coffey at oracle.com Thu Aug 27 14:36:22 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 27 Aug 2020 15:36:22 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> Message-ID: <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> Thanks for the review Max. Comments inline.. On 27/08/2020 14:45, Weijun Wang wrote: > I?m OK with using one warning, but prefer it to a little more formal like "POSIX file permission and/or symlink attributes detected??. > > One nit in ZipFile.java: > > 1098 // only set posix perms value via ZipEntry constructor for now > 1099 @Override > 1100 public int getExtraAttributes(ZipEntry ze) { > > Maybe you can just remove the comment. > > Do you also want to rename the ?posixPermsDetected" field and loacl variable ?perms? in JarSigner.java? Good points. Edits made. http://cr.openjdk.java.net/~coffeys/webrev.8250968.v3/webrev/ > > I?m not sure about the test but if zipfs is able to keep permissions inside a zip file then that POSIX byte (or whatever it?s named) is already there and we can modify it to include more bits. Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. regards, Sean. > > No other comment. > > Thanks, > Max > > >> On Aug 27, 2020, at 3:26 AM, Se?n Coffey wrote: >> >> updated webrev: >> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ >> >> regards, >> Sean. >> >> On 27/08/2020 07:42, Se?n Coffey wrote: >>> Hi Max, >>> >>> I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit then ? >>> >>> + {"posix.attributes.detected", "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>> >>>>> replace with: >>> + {"extra.attributes.detected", "POSIX file permission/symlink attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>> >>> regards, >>> Sean. >>> >>> On 26/08/2020 23:15, Weijun Wang wrote: >>>> Are you going to update the warning text or create a new one? >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: >>>>> >>>>> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. >>>>> >>>>> I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8250968 >>>>> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >>>>> >>>>> regards, >>>>> Sean. >>>>> From WEIJUN.WANG at ORACLE.COM Thu Aug 27 14:58:24 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Thu, 27 Aug 2020 10:58:24 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> Message-ID: <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> > On Aug 27, 2020, at 10:36 AM, Se?n Coffey wrote: > > Thanks for the review Max. Comments inline.. > > On 27/08/2020 14:45, Weijun Wang wrote: >> I?m OK with using one warning, but prefer it to a little more formal like "POSIX file permission and/or symlink attributes detected??. >> >> One nit in ZipFile.java: >> >> 1098 // only set posix perms value via ZipEntry constructor for now >> 1099 @Override >> 1100 public int getExtraAttributes(ZipEntry ze) { >> >> Maybe you can just remove the comment. >> >> Do you also want to rename the ?posixPermsDetected" field and loacl variable ?perms? in JarSigner.java? > > Good points. Edits made. > > http://cr.openjdk.java.net/~coffeys/webrev.8250968.v3/webrev/ > >> >> I?m not sure about the test but if zipfs is able to keep permissions inside a zip file then that POSIX byte (or whatever it?s named) is already there and we can modify it to include more bits. > > Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* for symlink and see if jarsigner can keep it. ?Max > > regards, > Sean. > >> >> No other comment. >> >> Thanks, >> Max >> >> >>> On Aug 27, 2020, at 3:26 AM, Se?n Coffey wrote: >>> >>> updated webrev: >>> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 27/08/2020 07:42, Se?n Coffey wrote: >>>> Hi Max, >>>> >>>> I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit then ? >>>> >>>> + {"posix.attributes.detected", "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>>> >>>>>> replace with: >>>> + {"extra.attributes.detected", "POSIX file permission/symlink attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>>> >>>> regards, >>>> Sean. >>>> >>>> On 26/08/2020 23:15, Weijun Wang wrote: >>>>> Are you going to update the warning text or create a new one? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: >>>>>> >>>>>> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. >>>>>> >>>>>> I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8250968 >>>>>> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> From LANCE.ANDERSEN at ORACLE.COM Thu Aug 27 16:32:49 2020 From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen) Date: Thu, 27 Aug 2020 12:32:49 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> Message-ID: <15DE9185-D6DC-4E42-A7C5-B5B217248C6B@ORACLE.COM> Hi Sean, I think the changes are OK in the latest version. A couple of the files have a 2019 copyright still. > On Aug 27, 2020, at 10:58 AM, Weijun Wang wrote: > > > >> On Aug 27, 2020, at 10:36 AM, Se?n Coffey wrote: >> >> Thanks for the review Max. Comments inline.. >> >> On 27/08/2020 14:45, Weijun Wang wrote: >>> I?m OK with using one warning, but prefer it to a little more formal like "POSIX file permission and/or symlink attributes detected??. >>> >>> One nit in ZipFile.java: >>> >>> 1098 // only set posix perms value via ZipEntry constructor for now >>> 1099 @Override >>> 1100 public int getExtraAttributes(ZipEntry ze) { >>> >>> Maybe you can just remove the comment. >>> >>> Do you also want to rename the ?posixPermsDetected" field and loacl variable ?perms? in JarSigner.java? >> >> Good points. Edits made. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v3/webrev/ >> >>> >>> I?m not sure about the test but if zipfs is able to keep permissions inside a zip file then that POSIX byte (or whatever it?s named) is already there and we can modify it to include more bits. >> >> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. > > As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* for symlink and see if jarsigner can keep it. We can create an RFE for adding support for this with Zip FS. > > ?Max > >> >> regards, >> Sean. >> >>> >>> No other comment. >>> >>> Thanks, >>> Max >>> >>> >>>> On Aug 27, 2020, at 3:26 AM, Se?n Coffey wrote: >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> On 27/08/2020 07:42, Se?n Coffey wrote: >>>>> Hi Max, >>>>> >>>>> I looked at updating the warning string but figured that it might have been of no interest to end users. How about this edit then ? >>>>> >>>>> + {"posix.attributes.detected", "POSIX file permission attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>>>> >>>>>>> replace with: >>>>> + {"extra.attributes.detected", "POSIX file permission/symlink attributes detected. These attributes are ignored when signing and are not protected by the signature."}, >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 26/08/2020 23:15, Weijun Wang wrote: >>>>>> Are you going to update the warning text or create a new one? >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> On Aug 26, 2020, at 2:26 PM, Se?n Coffey wrote: >>>>>>> >>>>>>> This is a follow on from the recent 8218021 fix. The jarsigner tool removes symlink attribute data from zipfiles when signing them. jarsigner should preserve this data. The fix involves preserving the 16 bits associated with the file attributes (instead of the current 12). That's done in ZipFile. All other changes are just a refactor of the variable name. >>>>>>> >>>>>>> I haven't been able to automate a test for this since zipfs doesn't seem to support symlinks. Manual testing looks good. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8250968 >>>>>>> http://hmsjpse.uk.oracle.com/home/scoffey/ws/jdk-jdk/open/webrev.8250968/webrev/index.html >>>>>>> >>>>>>> regards, >>>>>>> Sean. Best Lance ------------------ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From valerie.peng at oracle.com Thu Aug 27 19:43:40 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 27 Aug 2020 12:43:40 -0700 Subject: RFR (16): 8241003: Deprecate "denigrated" java.security.cert APIs that represent DNs as Principal or String objects In-Reply-To: <8b963d43-e36e-8051-b8c9-6b8dfc590eca@oracle.com> References: <436f4db2-0a3b-986d-bd8e-d64c47974e65@oracle.com> <8da00928-38d2-0c46-b710-7204f75ab261@oracle.com> <8b963d43-e36e-8051-b8c9-6b8dfc590eca@oracle.com> Message-ID: <80fbc508-dd4b-9b45-689e-bd77b2dab866@oracle.com> Ok, thanks for the reply. Valerie On 8/26/2020 5:02 AM, Sean Mullan wrote: > On 8/21/20 2:14 PM, Valerie Peng wrote: >> Is it intentional to use toString() in >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java? >> Normally, toString() is kind of loose, not as strict as getName(). > > In this case I think toString() is ok, since jarsigner is printing > information about the certificate. > > Also, I wanted the format to be compatible with the previous code just > in case some script or something out there is parsing the format and > expecting it to be the same. In the JDK implementation, > X500Principal.toString calls X500Name.toString(). > > --Sean > >> >> Valerie >> >> On 8/21/2020 11:01 AM, Xuelei Fan wrote: >>> Looks fine to me. >>> >>> Just a trivial format comment.? Some use link for "RFC 2253", some >>> do not. It's OK.? And it's good as well if you want to use a uniform >>> style. >>> >>> Xuelei >>> >>> On 8/21/2020 9:24 AM, Sean Mullan wrote: >>>> Ping ... >>>> >>>> On 8/7/20 10:01 AM, Sean Mullan wrote: >>>>> Please review this change to deprecate the following APIs: >>>>> >>>>> java.security.cert.X509Certificate.getIssuerDN() >>>>> java.security.cert.X509Certificate.getSubjectDN() >>>>> java.security.cert.X509CRL.getIssuerDN() >>>>> java.security.cert.X509CertSelector.setIssuer(String) >>>>> java.security.cert.X509CertSelector.setSubject(String) >>>>> java.security.cert.X509CertSelector.getIssuerAsString() >>>>> java.security.cert.X509CertSelector.getSubjectAsString() >>>>> java.security.cert.X509CRLSelector.addIssuerName(String) >>>>> >>>>> These APIs either take or return Distinguished Names as Principal >>>>> or String objects which can cause issues due to loss of encoding >>>>> information or differences when comparing names across different >>>>> Principal implementations. All of them have alternative APIs which >>>>> use X500Principal objects instead. They have long had warnings in >>>>> the javadoc and have been discouraged from being used. There are >>>>> no plans to remove the APIs at this time, as they have been in the >>>>> platform for a long time and removing them would be a much higher >>>>> compatibility risk. >>>>> >>>>> webrev: >>>>> https://cr.openjdk.java.net/~mullan/webrevs/8241003/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8250970 >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8241003 >>>>> >>>>> --Sean From anders.rundgren.net at gmail.com Fri Aug 28 11:03:24 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 28 Aug 2020 13:03:24 +0200 Subject: RFC8410 (in)compatibility Message-ID: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> Hi Crypto Experts, Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: https://tools.ietf.org/html/rfc8410#section-10.2 It seems that the certificate is signed with a key intended for ECDH. Question: is Java's "Signature" object supposed to accept X25519 keys? Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. Regards, Anders Rundgren *] java.security.InvalidKeyException: cannot identify EdDSA private key From WEIJUN.WANG at ORACLE.COM Fri Aug 28 13:41:11 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Fri, 28 Aug 2020 09:41:11 -0400 Subject: RFC8410 (in)compatibility In-Reply-To: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> Message-ID: <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> What version of java are you using and what?s your command to generate the key pair? Thanks, Max > On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: > > Hi Crypto Experts, > > Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: > https://tools.ietf.org/html/rfc8410#section-10.2 > > It seems that the certificate is signed with a key intended for ECDH. > Question: is Java's "Signature" object supposed to accept X25519 keys? > > Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. > > Regards, > Anders Rundgren > > *] java.security.InvalidKeyException: cannot identify EdDSA private key From anders.rundgren.net at gmail.com Fri Aug 28 13:55:27 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 28 Aug 2020 15:55:27 +0200 Subject: RFC8410 (in)compatibility In-Reply-To: <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> Message-ID: On 2020-08-28 15:41, Weijun Wang wrote: > What version of java are you using and what?s your command to generate the key pair? Hi Max, While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. KeyPairGenerator kpg = KeyPairGenerator.getInstance("X25519") KeyPair kp = kpg.generateKeyPair(); A self-signed X25519 certificate would require that a X25519 key is useful as a signature key. Note: I'm not proposing such a feature, I'm just trying to understand :) Regards, Anders > > Thanks, > Max > >> On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: >> >> Hi Crypto Experts, >> >> Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: >> https://tools.ietf.org/html/rfc8410#section-10.2 >> >> It seems that the certificate is signed with a key intended for ECDH. >> Question: is Java's "Signature" object supposed to accept X25519 keys? >> >> Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. >> >> Regards, >> Anders Rundgren >> >> *] java.security.InvalidKeyException: cannot identify EdDSA private key > From WEIJUN.WANG at ORACLE.COM Fri Aug 28 13:58:32 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Fri, 28 Aug 2020 09:58:32 -0400 Subject: RFC8410 (in)compatibility In-Reply-To: References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> Message-ID: Is ?Ed25519? what you need? It?s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. ?Max > On Aug 28, 2020, at 9:55 AM, Anders Rundgren wrote: > > On 2020-08-28 15:41, Weijun Wang wrote: >> What version of java are you using and what?s your command to generate the key pair? > > Hi Max, > > While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. > > KeyPairGenerator kpg = KeyPairGenerator.getInstance("X25519") > KeyPair kp = kpg.generateKeyPair(); > > A self-signed X25519 certificate would require that a X25519 key is useful as a signature key. > > Note: I'm not proposing such a feature, I'm just trying to understand :) > > Regards, > Anders >> Thanks, >> Max >>> On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: >>> >>> Hi Crypto Experts, >>> >>> Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: >>> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!OMTnVBdbrt8MuV8YwHsti8iuWLk2QE3C6FGAQeBoMJj9pIBQiRO6cbcSLzY8F_90TQ$ >>> It seems that the certificate is signed with a key intended for ECDH. >>> Question: is Java's "Signature" object supposed to accept X25519 keys? >>> >>> Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. >>> >>> Regards, >>> Anders Rundgren >>> >>> *] java.security.InvalidKeyException: cannot identify EdDSA private key > From anders.rundgren.net at gmail.com Fri Aug 28 14:07:46 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 28 Aug 2020 16:07:46 +0200 Subject: RFC8410 (in)compatibility In-Reply-To: References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> Message-ID: On 2020-08-28 15:58, Weijun Wang wrote: > Is ?Ed25519? what you need? It?s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. I know, that's why I wrote that I currently use BC (BouncyCastle). My question is thus applicable to JDK 15. BC apparently rejects X25519 signature keys. Probably for a reason. Regards, Anders > > ?Max > >> On Aug 28, 2020, at 9:55 AM, Anders Rundgren wrote: >> >> On 2020-08-28 15:41, Weijun Wang wrote: >>> What version of java are you using and what?s your command to generate the key pair? >> >> Hi Max, >> >> While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. >> >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("X25519") >> KeyPair kp = kpg.generateKeyPair(); >> >> A self-signed X25519 certificate would require that a X25519 key is useful as a signature key. >> >> Note: I'm not proposing such a feature, I'm just trying to understand :) >> >> Regards, >> Anders >>> Thanks, >>> Max >>>> On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: >>>> >>>> Hi Crypto Experts, >>>> >>>> Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: >>>> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!OMTnVBdbrt8MuV8YwHsti8iuWLk2QE3C6FGAQeBoMJj9pIBQiRO6cbcSLzY8F_90TQ$ >>>> It seems that the certificate is signed with a key intended for ECDH. >>>> Question: is Java's "Signature" object supposed to accept X25519 keys? >>>> >>>> Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. >>>> >>>> Regards, >>>> Anders Rundgren >>>> >>>> *] java.security.InvalidKeyException: cannot identify EdDSA private key >> > From sean.coffey at oracle.com Fri Aug 28 14:17:11 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 28 Aug 2020 15:17:11 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> Message-ID: I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase added. http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ regards, Sean. On 27/08/2020 15:58, Weijun Wang wrote: >> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. > As long as that*byte* is there and it?s not difficult to locate, we can manually add the*bit* for symlink and see if jarsigner can keep it. > > ?Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From WEIJUN.WANG at ORACLE.COM Fri Aug 28 15:18:18 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Fri, 28 Aug 2020 11:18:18 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> Message-ID: <68E22623-B1E8-4F44-83B7-42B87EED89E9@ORACLE.COM> 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] declaration but how the original ZIP file is generated. 2. Does this require a CSR? The POSIX permission one had one. Thanks, Max > On Aug 28, 2020, at 10:17 AM, Se?n Coffey wrote: > > I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase added. > > http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ > > regards, > Sean. > > On 27/08/2020 15:58, Weijun Wang wrote: >>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >>> >> As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* >> for symlink and see if jarsigner can keep it. >> >> ?Max >> >> From sean.coffey at oracle.com Fri Aug 28 16:05:12 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 28 Aug 2020 17:05:12 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <68E22623-B1E8-4F44-83B7-42B87EED89E9@ORACLE.COM> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> <68E22623-B1E8-4F44-83B7-42B87EED89E9@ORACLE.COM> Message-ID: On 28/08/2020 16:18, Weijun Wang wrote: > 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] declaration but how the original ZIP file is generated. I'll add a comment block to the test: > ??? /* > ???? * Created using the createByteArray utility method. > ???? * The zipfile itself was created via this example: > ???? * $ ls -l z > ???? * lrwxrwxrwx 1 test test 4 Aug 27 18:33 z -> ../z > ???? * $ zip -ry test.zip z > ???? */ > > 2. Does this require a CSR? The POSIX permission one had one. Fair point. I've logged one, just to be safe. regards, Sean. > > Thanks, > Max > >> On Aug 28, 2020, at 10:17 AM, Se?n Coffey wrote: >> >> I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase added. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ >> >> regards, >> Sean. >> >> On 27/08/2020 15:58, Weijun Wang wrote: >>>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >>>> >>> As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* >>> for symlink and see if jarsigner can keep it. >>> >>> ?Max >>> >>> From WEIJUN.WANG at ORACLE.COM Fri Aug 28 16:15:41 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Fri, 28 Aug 2020 12:15:41 -0400 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> <68E22623-B1E8-4F44-83B7-42B87EED89E9@ORACLE.COM> Message-ID: <35266390-1DC1-4E69-A946-CD4989A3C238@ORACLE.COM> Everything looks fine to me. I?ve added myself as the CSR reviewer. In the Solution section, it probably should me ?The existing warning introduced in JDK-8218021 is expanded to include symlink?. It is not a new warning. Thanks, Max > On Aug 28, 2020, at 12:05 PM, Se?n Coffey wrote: > > > On 28/08/2020 16:18, Weijun Wang wrote: >> 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] declaration but how the original ZIP file is generated. > I'll add a comment block to the test: >> /* >> * Created using the createByteArray utility method. >> * The zipfile itself was created via this example: >> * $ ls -l z >> * lrwxrwxrwx 1 test test 4 Aug 27 18:33 z -> ../z >> * $ zip -ry test.zip z >> */ > >> >> 2. Does this require a CSR? The POSIX permission one had one. > > Fair point. I've logged one, just to be safe. > > regards, > Sean. > >> >> Thanks, >> Max >> >>> On Aug 28, 2020, at 10:17 AM, Se?n Coffey wrote: >>> >>> I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase added. >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 27/08/2020 15:58, Weijun Wang wrote: >>>>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >>>>> >>>> As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* >>>> for symlink and see if jarsigner can keep it. >>>> >>>> ?Max >>>> >>>> From hai-may.chao at oracle.com Fri Aug 28 20:08:58 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 28 Aug 2020 13:08:58 -0700 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> Message-ID: <8946D5E0-8438-43EC-A987-4FEBF5779343@oracle.com> JarSigner.java #953: The output debug message can be removed from the code. JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. ZipFile.java #661: Suggest to keep the comment and update it with the additional 4 bits for symlink. The rest of code changes and CSR look good. Thanks, Hai-May > On Aug 28, 2020, at 7:17 AM, Se?n Coffey wrote: > > I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase added. > > http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ > regards, > Sean. > > On 27/08/2020 15:58, Weijun Wang wrote: >>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >> As long as that *byte* is there and it?s not difficult to locate, we can manually add the *bit* for symlink and see if jarsigner can keep it. >> >> ?Max >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.rundgren.net at gmail.com Sat Aug 29 14:14:44 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sat, 29 Aug 2020 16:14:44 +0200 Subject: Correction: Re: RFC8410 (in)compatibility In-Reply-To: References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> Message-ID: <3865048a-da50-78bf-4fff-a1489cbb3ae7@gmail.com> The RFC8410 author claims that the public key featured in the "self-issued" certificate is NOT related to the signature key. The answer to my question is thus (?) that "Signature" should (as BC does) reject X25519 keys. All is good :-) Anders On 2020-08-28 16:07, Anders Rundgren wrote: > On 2020-08-28 15:58, Weijun Wang wrote: >> Is ?Ed25519? what you need? It?s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. > > I know, that's why I wrote that I currently use BC (BouncyCastle). > > My question is thus applicable to JDK 15. BC apparently rejects X25519 signature keys. Probably for a reason. > > Regards, > Anders > >> >> ?Max >> >>> On Aug 28, 2020, at 9:55 AM, Anders Rundgren wrote: >>> >>> On 2020-08-28 15:41, Weijun Wang wrote: >>>> What version of java are you using and what?s your command to generate the key pair? >>> >>> Hi Max, >>> >>> While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. >>> >>> KeyPairGenerator kpg = KeyPairGenerator.getInstance("X25519") >>> KeyPair kp = kpg.generateKeyPair(); >>> >>> A self-signed X25519 certificate would require that a X25519 key is useful as a signature key. >>> >>> Note: I'm not proposing such a feature, I'm just trying to understand :) >>> >>> Regards, >>> Anders >>>> Thanks, >>>> Max >>>>> On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: >>>>> >>>>> Hi Crypto Experts, >>>>> >>>>> Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: >>>>> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!OMTnVBdbrt8MuV8YwHsti8iuWLk2QE3C6FGAQeBoMJj9pIBQiRO6cbcSLzY8F_90TQ$ >>>>> It seems that the certificate is signed with a key intended for ECDH. >>>>> Question: is Java's "Signature" object supposed to accept X25519 keys? >>>>> >>>>> Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. >>>>> >>>>> Regards, >>>>> Anders Rundgren >>>>> >>>>> *] java.security.InvalidKeyException: cannot identify EdDSA private key >>> >> > From WEIJUN.WANG at ORACLE.COM Sat Aug 29 16:03:10 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Sat, 29 Aug 2020 12:03:10 -0400 Subject: Correction: Re: RFC8410 (in)compatibility In-Reply-To: <3865048a-da50-78bf-4fff-a1489cbb3ae7@gmail.com> References: <6b0c0d16-d421-f516-9b21-d94492d72075@gmail.com> <2F2DD93F-79B0-4896-B43A-51B6911DB9B2@ORACLE.COM> <3865048a-da50-78bf-4fff-a1489cbb3ae7@gmail.com> Message-ID: In JDK 15, a Signature.getInstance("Ed25519?) would also reject a key generated from KeyPairGenerator.getInstance("X25519?). It accepts a key from KeyPairGenerator.getInstance("Ed25519?). Thanks, Max > On Aug 29, 2020, at 10:14 AM, Anders Rundgren wrote: > > The RFC8410 author claims that the public key featured in the "self-issued" certificate is NOT related to the signature key. > The answer to my question is thus (?) that "Signature" should (as BC does) reject X25519 keys. > > All is good :-) > > Anders > > On 2020-08-28 16:07, Anders Rundgren wrote: >> On 2020-08-28 15:58, Weijun Wang wrote: >>> Is ?Ed25519? what you need? It?s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. >> I know, that's why I wrote that I currently use BC (BouncyCastle). >> My question is thus applicable to JDK 15. BC apparently rejects X25519 signature keys. Probably for a reason. >> Regards, >> Anders >>> >>> ?Max >>> >>>> On Aug 28, 2020, at 9:55 AM, Anders Rundgren wrote: >>>> >>>> On 2020-08-28 15:41, Weijun Wang wrote: >>>>> What version of java are you using and what?s your command to generate the key pair? >>>> >>>> Hi Max, >>>> >>>> While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. >>>> >>>> KeyPairGenerator kpg = KeyPairGenerator.getInstance("X25519") >>>> KeyPair kp = kpg.generateKeyPair(); >>>> >>>> A self-signed X25519 certificate would require that a X25519 key is useful as a signature key. >>>> >>>> Note: I'm not proposing such a feature, I'm just trying to understand :) >>>> >>>> Regards, >>>> Anders >>>>> Thanks, >>>>> Max >>>>>> On Aug 28, 2020, at 7:03 AM, Anders Rundgren wrote: >>>>>> >>>>>> Hi Crypto Experts, >>>>>> >>>>>> Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: >>>>>> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8410*section-10.2__;Iw!!GqivPVa7Brio!OMTnVBdbrt8MuV8YwHsti8iuWLk2QE3C6FGAQeBoMJj9pIBQiRO6cbcSLzY8F_90TQ$ >>>>>> It seems that the certificate is signed with a key intended for ECDH. >>>>>> Question: is Java's "Signature" object supposed to accept X25519 keys? >>>>>> >>>>>> Personally I don't see any use of a self-signed encryption certificate so maybe this is just a bad example...kind of edge case. >>>>>> >>>>>> Regards, >>>>>> Anders Rundgren >>>>>> >>>>>> *] java.security.InvalidKeyException: cannot identify EdDSA private key >>>> >>> > From RAJAN.HALADE at ORACLE.COM Sat Aug 29 17:56:41 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Sat, 29 Aug 2020 10:56:41 -0700 Subject: RFR: 8249176: Update GlobalSignR6CA test certificates Message-ID: Please review this change to update test artifacts used for GlobalSign R6 Root CA. Webrev: http://cr.openjdk.java.net/~rhalade/8249176/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sat Aug 29 20:44:31 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 29 Aug 2020 13:44:31 -0700 Subject: RFR: 8249176: Update GlobalSignR6CA test certificates In-Reply-To: References: Message-ID: Looks good to me. Thanks, Xuelei On 8/29/2020 10:56 AM, Rajan Halade wrote: > Please review this change to update test artifacts used for GlobalSign > R6 Root CA. > > Webrev: http://cr.openjdk.java.net/~rhalade/8249176/webrev.00/ > > Thanks, > Rajan > From anders.rundgren.net at gmail.com Sun Aug 30 16:51:42 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sun, 30 Aug 2020 18:51:42 +0200 Subject: getParams() for XECKey returns nonsense Message-ID: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> Hi, This applies to JDK 11. https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html what is the value of "AlgorithmParameterSpec"? In JDK 15 the new EdECKey has gotten a more logical solution: https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html thanx, Anders From anders.rundgren.net at gmail.com Mon Aug 31 15:16:09 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 31 Aug 2020 17:16:09 +0200 Subject: Missing documentation for EdDSA key serialization Message-ID: On https://tools.ietf.org/html/rfc8032#page-24 you can find test vectors that are also used by rfc8037 (JOSE). However, there seems to be no information on how to create an EdDSA public key from such a vector. Apparently you must be an expert on the inner workings of EdDSA in order to use this API. I have though managed(...) but 1) it looks strange 2) it may be incorrect. Steps 1. Convert the hex-code to a byte[] array. 2. Reverse (!) all the bytes in the byte[] array. 3. publicKey = kf.generatePublic( ??????????????????? new EdECPublicKeySpec(new NamedParameterSpec(alg), ????????????????????????????????????????? new EdECPoint(false, new BigInteger(1, theByteArray)))); Ideally, EdECPoint should have an constructor that does whatever it takes based on a byte[] array. It is equally fuzzy in the other direction.? A "getByteArray()" on EdECPoint had been great. Thanx, Anders From anthony.scarpino at oracle.com Mon Aug 31 18:00:30 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 31 Aug 2020 11:00:30 -0700 Subject: Missing documentation for EdDSA key serialization In-Reply-To: References: Message-ID: On 8/31/20 8:16 AM, Anders Rundgren wrote: > On > https://tools.ietf.org/html/rfc8032#page-24 > you can find test vectors that are also used by rfc8037 (JOSE). > > However, there seems to be no information on how to create an EdDSA > public key from such a vector. > Apparently you must be an expert on the inner workings of EdDSA in order > to use this API. > > I have though managed(...) but 1) it looks strange 2) it may be incorrect. > > Steps > 1. Convert the hex-code to a byte[] array. > 2. Reverse (!) all the bytes in the byte[] array. > 3. publicKey = kf.generatePublic( > ??????????????????? new EdECPublicKeySpec(new NamedParameterSpec(alg), > ????????????????????????????????????????? new EdECPoint(false, new > BigInteger(1, theByteArray)))); > > Ideally, EdECPoint should have an constructor that does whatever it > takes based on a byte[] array. > > It is equally fuzzy in the other direction.? A "getByteArray()" on > EdECPoint had been great. > > Thanx, > Anders Hi, It does seem like a constructor and/or helper methods would be a good addition. I filed a bug to track this: https://bugs.openjdk.java.net/browse/JDK-8252595 thanks Tony From mstjohns at comcast.net Mon Aug 31 18:38:34 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 31 Aug 2020 14:38:34 -0400 Subject: Missing documentation for EdDSA key serialization In-Reply-To: References: Message-ID: On 8/31/2020 2:00 PM, Anthony Scarpino wrote: > On 8/31/20 8:16 AM, Anders Rundgren wrote: >> On >> https://tools.ietf.org/html/rfc8032#page-24 >> you can find test vectors that are also used by rfc8037 (JOSE). >> >> However, there seems to be no information on how to create an EdDSA >> public key from such a vector. >> Apparently you must be an expert on the inner workings of EdDSA in >> order to use this API. >> >> I have though managed(...) but 1) it looks strange 2) it may be >> incorrect. >> >> Steps >> 1. Convert the hex-code to a byte[] array. >> 2. Reverse (!) all the bytes in the byte[] array. >> 3. publicKey = kf.generatePublic( >> ???????????????????? new EdECPublicKeySpec(new NamedParameterSpec(alg), >> ?????????????????????????????????????????? new EdECPoint(false, new >> BigInteger(1, theByteArray)))); >> >> Ideally, EdECPoint should have an constructor that does whatever it >> takes based on a byte[] array. >> >> It is equally fuzzy in the other direction.? A "getByteArray()" on >> EdECPoint had been great. >> >> Thanx, >> Anders > > Hi, > > It does seem like a constructor and/or helper methods would be a good > addition.? I filed a bug to track this: > > https://bugs.openjdk.java.net/browse/JDK-8252595 > > thanks > > Tony Generically, maybe this should be added not to the ED based stuff, but to BigInteger: public static BigInteger fromLittleEndianEncoding(int signum, byte[] magnitude); public? byte[] getMagnitude(boolean bigEndian, int sizeInBytes); // if size in bytes < actual magnitude size, returns the magnitude bytes, otherwise returns the magnitude bytes left or right padded to sizeInBytes depending on endianness. Almost all of the crypto stuff related to converting between the various encodings of signatures and keys would benefit from a standard version of the left/right padding stuff. Mike ps - there's a long thread maybe a year or two ago about internal vs external representations of the EDDSA and EDDH keys.? I'm actually kind of surprised that the internal representation turned out to be BigInteger.?? I'm glad it did, but its now kind of strange that we have 6 extra interface classes when we could probably have gotten away with folding them in under the EC* classes. pps - the alternate way of doing this (and probably the most correct way) would be to encode the bytes from the test vector into a SubjectPublicKeyInfo public key (see RFC8401)? and run that through the key factory.? That should do all the reversing and generating.? You can confirm that by doing a getEncoded() on your built public key and running it back through the key factory.