From bradford.wetmore at oracle.com Fri Mar 1 00:26:07 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 28 Feb 2019 16:26:07 -0800 Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl In-Reply-To: References: <898ee087-a589-de30-c842-770c606c49de@oracle.com> <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com> Message-ID: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com> AbstractDelegateHttpsURLConnection.java --------------------------------------- 74/88/etc. I haven't checked for sure, but IIRC we made setNewClient public from protected and other such changes in order for these classes to use the delegation model and allow calls to both sun/net/www/protocol and com/sun/net/ssl/internal/www/protocol... Should the delegation code be stripped out, and these methods be set back to protected? ProviderConfig.java ------------------- I think we're over-rotating on this one, I'd be very surprised if anyone is still using com.sun.net.ssl.internal.ssl.Provider. My personal preference is to kill it now, but if you really want to keep it, please file a bug and commit to a near release so we can finally kill this thing off. test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java -------------------------------------------------------------------- When we opensourced the JSSE code, we left some of the javax and com tests in the com/sun/net/ssl test directory. The test names are very similar, with the exception of the Com/Javax prefix. The tests were identical, with the exception of whether they called into the com or javax APIs. Here you are deleting the ComTrustManagerFactoryImpl test which is probably correct, but should you also be deleting the JavaxTrustManagerFactoryImpl test as well? Please check that we didn't get too carried away and are deleting still valid tests. Thanks, Brad On 2/26/2019 7:33 AM, Chris Hegarty wrote: > >> On 26 Feb 2019, at 03:53, Xuelei Fan wrote: >> >> >> >> It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as public. We may need to re-org the code later, but it is out of the scope of this update. >> >> Here is the new webrev (only AbstractDelegateHttpsURLConnection updated): >> http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/ > > I think that this is probably ok ( since the package is not exported ), > but it seems a little distasteful to not have the API move through > the terminal deprecation route before being removed. > > -Chris. > From sha.jiang at oracle.com Fri Mar 1 00:53:27 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 1 Mar 2019 08:53:27 +0800 Subject: RFR[13] JDK-8219723: javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases In-Reply-To: <6364ede7-ab43-6f03-af3d-40d8414120f8@oracle.com> References: <6364ede7-ab43-6f03-af3d-40d8414120f8@oracle.com> Message-ID: <51472664-3d41-d25d-e0d0-4c744ec5f502@oracle.com> Hi Jamil, Thanks for your suggestion. Best regards, John Jiang On 2019/3/1 01:54, Jamil Nimeh wrote: > This comment doesn't directly apply to this fix, but tests that depend > on the certs from Cert.java and have configurable PKIXParameters might > also just set setDate to something in the middle of this validity > period so you never have to worry about regenerating the certs due to > date issues.? That may not work for all your tests though, if? you're > not customizing the trust managers with PKIXParameter objects. > > Just something to consider as you're going forward, no changes to this > webrev. > > --Jamil > > On 2/27/2019 6:20 PM, sha.jiang at oracle.com wrote: >> Hi, >> Test javax/net/ssl/compatibility/Compatibility.java failed due to the >> associated certificates are expired. >> This fix just re-generates the certificates and set much longer >> validity period. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8219723 >> Webrev: http://cr.openjdk.java.net/~jjiang/8219723/webrev.00/ >> >> Best regards, >> John Jiang >> > > From xuelei.fan at oracle.com Fri Mar 1 16:27:47 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Mar 2019 08:27:47 -0800 Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl In-Reply-To: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com> References: <898ee087-a589-de30-c842-770c606c49de@oracle.com> <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com> <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com> Message-ID: <906d46a3-b26c-3cae-2e5a-827fbfff7435@oracle.com> On 2/28/2019 4:26 PM, Bradford Wetmore wrote: > AbstractDelegateHttpsURLConnection.java > --------------------------------------- > 74/88/etc.? I haven't checked for sure, but IIRC we made setNewClient > public from protected and other such changes in order for these classes > to use the delegation model and allow calls to both sun/net/www/protocol > and com/sun/net/ssl/internal/www/protocol...? Should the delegation code > be stripped out, and these methods be set back to protected? > It should be safe to use "protected", but it's less risky to keep it unchanged. I agree that the delegation code should be stripped out. The HttpsURLConnection implementation could be re-designed. I filed a new bug to track the enhancement (JDK-8219987). > ProviderConfig.java > ------------------- > I think we're over-rotating on this one, I'd be very surprised if anyone > is still using com.sun.net.ssl.internal.ssl.Provider.? My personal > preference is to kill it now, but if you really want to keep it, please > file a bug and commit to a near release so we can finally kill this > thing off. > I would like do it later as the old java.security use this string, and I'm not sure if someone really use it in their application. It is safer to fix in a separate bug. I filled a new bug to tack the update (JDK-8219989). > test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java > test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java > -------------------------------------------------------------------- > When we opensourced the JSSE code, we left some of the javax and com > tests in the com/sun/net/ssl test directory.? The test names are very > similar, with the exception of the Com/Javax prefix.? The tests were > identical, with the exception of whether they called into the com or > javax APIs. > > Here you are deleting the ComTrustManagerFactoryImpl test which is > probably correct, but should you also be deleting the > JavaxTrustManagerFactoryImpl test as well?? Please check that we didn't > get too carried away and are deleting still valid tests. > They are helper classes and used by ProviderTest, which is used to test the com.sun.net.ssl wrappers. Thanks, Xuelei > Thanks, > > Brad > > > On 2/26/2019 7:33 AM, Chris Hegarty wrote: >> >>> On 26 Feb 2019, at 03:53, Xuelei Fan wrote: >>> >>> >>> >>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection >>> methods as public.? We may need to re-org the code later, but it is >>> out of the scope of this update. >>> >>> Here is the new webrev (only AbstractDelegateHttpsURLConnection >>> updated): >>> ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/ >> >> I think that this is probably ok ( since the package is not exported ), >> but it seems a little distasteful to not have the API move through >> the terminal deprecation route before being removed. >> >> -Chris. >> From xuelei.fan at oracle.com Fri Mar 1 16:54:52 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Mar 2019 08:54:52 -0800 Subject: RFR [13] JDK-8219990, Backout JDK-8219658 Message-ID: Hi Daniel, Could I have a review of the following update: http://cr.openjdk.java.net/~xuelei/8219990/webrev.00/ The update in the previous fix: http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/ is causing other thread safe problems. I would look for a new solution for the deadlock issue. Thanks, Xuelei From daniel.fuchs at oracle.com Fri Mar 1 17:23:27 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Mar 2019 17:23:27 +0000 Subject: RFR [13] JDK-8219990, Backout JDK-8219658 In-Reply-To: References: Message-ID: <2bbfddc8-8d3c-4e03-214e-9991266354c8@oracle.com> Looks good to me Xuelei! Thanks for taking this on. best regards, -- daniel On 01/03/2019 16:54, Xuelei Fan wrote: > Hi Daniel, > > Could I have a review of the following update: > ?? http://cr.openjdk.java.net/~xuelei/8219990/webrev.00/ > > The update in the previous fix: > ?? http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/ > is causing other thread safe problems.? I would look for a new solution > for the deadlock issue. > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Mar 1 19:17:23 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 1 Mar 2019 11:17:23 -0800 Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with unexpected sun.security.ssl.SunJSSE Message-ID: Hi, Could I have the following update reviewed? http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/ In my previous update for JDK-8215430 (removing the internal com.sun.net.ssl package), I missed to update java/lang/SecurityManager/CheckSecurityProvider.java to use the revised provider name. Thanks, Xuelei From sean.mullan at oracle.com Fri Mar 1 19:45:59 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 Mar 2019 14:45:59 -0500 Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with unexpected sun.security.ssl.SunJSSE In-Reply-To: References: Message-ID: <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com> Looks good. --Sean On 3/1/19 2:17 PM, Xuelei Fan wrote: > Hi, > > Could I have the following update reviewed? > ? http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/ > > In my previous update for JDK-8215430 (removing the internal > com.sun.net.ssl package), I missed to update > java/lang/SecurityManager/CheckSecurityProvider.java to use the revised > provider name. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Fri Mar 1 20:19:12 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 1 Mar 2019 12:19:12 -0800 Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with unexpected sun.security.ssl.SunJSSE In-Reply-To: <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com> References: <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com> Message-ID: Ditto. Brad On 3/1/2019 11:45 AM, Sean Mullan wrote: > Looks good. > > --Sean > > On 3/1/19 2:17 PM, Xuelei Fan wrote: >> Hi, >> >> Could I have the following update reviewed? >> ?? http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/ >> >> In my previous update for JDK-8215430 (removing the internal >> com.sun.net.ssl package), I missed to update >> java/lang/SecurityManager/CheckSecurityProvider.java to use the >> revised provider name. >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Mon Mar 4 03:32:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 4 Mar 2019 11:32:02 +0800 Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11 In-Reply-To: References: Message-ID: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com> Two questions: 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"? 2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough? Thanks, Max > On Feb 26, 2019, at 4:46 AM, Sean Mullan wrote: > > In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]). > > After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8217878 > > New test cases have also been added for the regressions. > > Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset. > > --Sean > > [1] https://bugs.openjdk.java.net/browse/JDK-8177334 > [2] https://bugs.openjdk.java.net/browse/JDK-8218629 From sean.mullan at oracle.com Mon Mar 4 13:33:32 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 4 Mar 2019 08:33:32 -0500 Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11 In-Reply-To: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com> References: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com> Message-ID: <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com> On 3/3/19 10:32 PM, Weijun Wang wrote: > Two questions: > > 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"? Yes, I did. I will add it. > 2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough? Good catch, since that code is not using XMLUtils, it is not checking the linebreaks property to see if linebreaks should be inserted (com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix that to use XMLUtils and I'll follow up with another webrev. Thanks, Sean > > Thanks, > Max > >> On Feb 26, 2019, at 4:46 AM, Sean Mullan wrote: >> >> In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]). >> >> After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8217878 >> >> New test cases have also been added for the regressions. >> >> Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset. >> >> --Sean >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177334 >> [2] https://bugs.openjdk.java.net/browse/JDK-8218629 > From adam.petcher at oracle.com Mon Mar 4 19:40:34 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 4 Mar 2019 14:40:34 -0500 Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA signatures... Message-ID: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com> webrev: https://cr.openjdk.java.net/~apetcher/8147502/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8147502 Please review this fix to a bug that causes ECDSA signatures to be incorrect in some cases. The fix is simple, but testing this issue is difficult because the API doesn't give access to the raw signing operation so we can check it using known answer tests. I got around this difficulty in the regression test by using a modified SecureRandom that supplies specific bits in order to produce the correct nonce. The test is a bit complicated and brittle, so if anyone has any other suggestions on how to do this, please share. From sean.mullan at oracle.com Mon Mar 4 20:11:13 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 4 Mar 2019 15:11:13 -0500 Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11 In-Reply-To: <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com> References: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com> <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.01/ Changes: - Added DOMCryptoBinary.java - Changed Base64 calls to XMLUtils in DOMKeyValue, DOMPGPData, DOMReference, DOMSignedInfo, DOMX509Data, and DOMXMLSignature Thanks, Sean On 3/4/19 8:33 AM, Sean Mullan wrote: > On 3/3/19 10:32 PM, Weijun Wang wrote: >> Two questions: >> >> 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"? > > Yes, I did. I will add it. > >> 2. The Base64 class is called directly in several places. Aren't the >> helper methods in XMLUtils enough? > > Good catch, since that code is not using XMLUtils, it is not checking > the linebreaks property to see if linebreaks should be inserted > (com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix > that to use XMLUtils and I'll follow up with another webrev. > > Thanks, > Sean > >> >> Thanks, >> Max >> >>> On Feb 26, 2019, at 4:46 AM, Sean Mullan wrote: >>> >>> In JDK 11, we included an updated version of Apache Santuario (which >>> the JDK XML Signature implementation is based on) [1]. This contained >>> a newer XML marshalling implementation, which has caused a couple of >>> serious regressions (this one and JDK-8218629 [2]). >>> >>> After unsuccessfully trying to patch the current implementation, we >>> decided to back it out and restore the previous code, which had been >>> very stable for many years. The newer implementation is different in >>> subtle ways and doesn't really offer any advantages other than a bit >>> of reduction in lines of code. The Apache Santuario Project also has >>> backed out the implementation. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8217878 >>> >>> New test cases have also been added for the regressions. >>> >>> Note that this also fixes JDK-8218629 [2]. Since technically they are >>> different issues, I will probably include both bug-ids in this >>> changeset. >>> >>> --Sean >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8177334 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8218629 >> From norman.maurer at googlemail.com Mon Mar 4 20:15:08 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 4 Mar 2019 21:15:08 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: Message-ID: Any comments here ? Bye Norman > On 28. Feb 2019, at 09:24, Norman Maurer wrote: > > Hi all, > > I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho. > > I pushed a reproducer for this here: > > https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug > > When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions. > > Here is the Java version I used to reproduce: > > # java -version > openjdk version "12" 2019-03-19 > OpenJDK Runtime Environment (build 12+33) > OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) > > > It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version: > > #java -version > openjdk version "12-ea" 2019-03-19 > OpenJDK Runtime Environment (build 12-ea+27) > OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) > > I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/ > > Thanks > Norman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Mar 5 00:26:41 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 Mar 2019 08:26:41 +0800 Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain java tests In-Reply-To: <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com> References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com> <1550223285.2497.12.camel@paratix.ch> <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com> Message-ID: Webrev updated at https://cr.openjdk.java.net/~weijun/8180573/webrev.01 BTW, last time I mistakenly removed ExportPrivateKeyNoPwd.java which is used by ListKeychainStore.sh. It's now back. Thanks, Max > On Feb 15, 2019, at 9:31 PM, Weijun Wang wrote: > > Hi Philipp, > > In most cases, it's just about creating a non-empty file; in some case, the content is relevant. For the former, I will change it to something like "new byte[10]"; for the latter, I'll use getBytes(UTF_8). > > Thanks, > Max > > >> On Feb 15, 2019, at 5:34 PM, Philipp Kunz wrote: >> >> Hi Max, >> >> I don't know if it is important enough, certainly not a serious issue. >> In your patch, for example in DiffEnd.java and a few other tests, Strings are encoded to byte streams with String.getBytes() which uses the default platform character set to encode the strings. >> Manifests, however, always use UTF-8 as the character set to encode. In my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be appropriate to specify the encoding in a platform-independent way. >> Now the manifests used in the tests use so few different characters that this might not even make a real difference because the first around 100 characters or so of most character sets are the same in most encodings. >> I suspect that the encoding might also have been platform-dependent in at least some of the previous shell tests and therefore this aspect might as well be addressed separately and is not strictly necessary to just properly convert shell tests to java. >> >> Regards, >> Philipp >> >> >> On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote: >>> Please review the fix at >>> >>> >>> https://cr.openjdk.java.net/~weijun/8180573/webrev.00/ >>> >>> >>> Notes: >>> >>> - Most changes are just .sh -> .java >>> >>> - StorePasswordsByShell.sh combined into StorePasswords.java >>> >>> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also. >>> >>> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty. >>> >>> - Copyright year updated to 2019, @bug unchanged. >>> >>> Two files not converted yet: >>> >>> - ./keytool/console.sh >>> >>> This is a manual test calling old versions of JDK. >>> >>> - ./keytool/ListKeychainStore.sh >>> >>> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it. >>> >>> Thanks, >>> Max >>> >>> > From weijun.wang at oracle.com Tue Mar 5 03:06:03 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 Mar 2019 11:06:03 +0800 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream Message-ID: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8157404/webrev.00/ When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes. A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases. Note this could block but it should only happen when data is not enough, and it only reads one byte. The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data. And I'm running a mach5 test job now. Thanks, Max From weijun.wang at oracle.com Tue Mar 5 03:23:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 Mar 2019 11:23:22 +0800 Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11 In-Reply-To: References: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com> <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com> Message-ID: Everything is fine now. Thanks, Max > On Mar 5, 2019, at 4:11 AM, Sean Mullan wrote: > > Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.01/ > > Changes: > > - Added DOMCryptoBinary.java > - Changed Base64 calls to XMLUtils in DOMKeyValue, DOMPGPData, DOMReference, DOMSignedInfo, DOMX509Data, and DOMXMLSignature > > Thanks, > Sean > > On 3/4/19 8:33 AM, Sean Mullan wrote: >> On 3/3/19 10:32 PM, Weijun Wang wrote: >>> Two questions: >>> >>> 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"? >> Yes, I did. I will add it. >>> 2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough? >> Good catch, since that code is not using XMLUtils, it is not checking the linebreaks property to see if linebreaks should be inserted (com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix that to use XMLUtils and I'll follow up with another webrev. >> Thanks, >> Sean >>> >>> Thanks, >>> Max >>> >>>> On Feb 26, 2019, at 4:46 AM, Sean Mullan wrote: >>>> >>>> In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]). >>>> >>>> After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation. >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8217878 >>>> >>>> New test cases have also been added for the regressions. >>>> >>>> Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset. >>>> >>>> --Sean >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177334 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8218629 >>> From Nico.Williams at twosigma.com Tue Mar 5 18:57:43 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 5 Mar 2019 18:57:43 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> Message-ID: <20190305185743.GA9177@twosigma.com> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: > All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub clone: https://github.com/twosigma/OpenJDK/pull/1 Nico -- From sean.mullan at oracle.com Tue Mar 5 19:53:17 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Mar 2019 14:53:17 -0500 Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager Message-ID: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError. The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard). webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/ bugid: https://bugs.openjdk.java.net/browse/JDK-8218618 --Sean From Alan.Bateman at oracle.com Tue Mar 5 19:55:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Mar 2019 19:55:41 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190305185743.GA9177@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> Message-ID: <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> On 05/03/2019 18:57, Nico Williams wrote: > On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: >> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. > Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub > clone: > Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists. -Alan From weijun.wang at oracle.com Wed Mar 6 00:39:45 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Mar 2019 08:39:45 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> Message-ID: > On Mar 6, 2019, at 3:55 AM, Alan Bateman wrote: > > On 05/03/2019 18:57, Nico Williams wrote: >> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: >>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. >> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub >> clone: >> > Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists. Yes, this is the rule. Also, I'm not sure what Peter is reviewing here as the title is not clear to me. Is it about all patches you are contributing? Or is it about the OpenJDK bugs we have already filed (which is only the first few steps of the big contribution)?. You are OK to discuss any change you are preparing to contribute anywhere, but once you decide to contribute a piece of code into OpenJDK, please follow these steps: 1. File a bug or RFE (If you cannot do that, ask me). 2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n for code review, or the patch is short, include it in the mail. 3. Anyone can reply the mail. You might heard there is a effort [1] going on about switching to another SCM or hosting service, but not now yet. Thanks, Max [1] https://openjdk.java.net/projects/skara/ > > -Alan From weijun.wang at oracle.com Wed Mar 6 00:50:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Mar 2019 08:50:36 +0800 Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> Message-ID: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> The fix looks fine to me. However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy? I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer. Thanks, Max > On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote: > > Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError. > > The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard). > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/ > bugid: https://bugs.openjdk.java.net/browse/JDK-8218618 > > --Sean From Nico.Williams at twosigma.com Wed Mar 6 02:09:46 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 6 Mar 2019 02:09:46 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> Message-ID: <20190306020946.GC9177@twosigma.com> On Wed, Mar 06, 2019 at 08:39:45AM +0800, Weijun Wang wrote: > > On 05/03/2019 18:57, Nico Williams wrote: > >> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: > >>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. > >> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub > >> clone: > >> > > Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists. > > Yes, this is the rule. That's fair. > Also, I'm not sure what Peter is reviewing here as the title is not clear to > me. Is it about all patches you are contributing? Or is it about the OpenJDK Yes. > bugs we have already filed (which is only the first few steps of the big > contribution)?. You are OK to discuss any change you are preparing to > contribute anywhere, but once you decide to contribute a piece of code into > OpenJDK, please follow these steps: We did decide to make a contribution. I thought your making a webrev for it, and my being approved to be a contributor, kickstarted the process. > 1. File a bug or RFE (If you cannot do that, ask me). How? > 2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n > for code review, or the patch is short, include it in the mail. You did the first part. I did the second. > 3. Anyone can reply the mail. So Peter, for example, doesn't need to be a contributor? > You might heard there is a effort [1] going on about switching to > another SCM or hosting service, but not now yet. Right, GitHub is sure a lot more convenient than webrevs. Nico -- From weijun.wang at oracle.com Wed Mar 6 02:24:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Mar 2019 10:24:50 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190306020946.GC9177@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> Message-ID: > On Mar 6, 2019, at 10:09 AM, Nico Williams wrote: > > On Wed, Mar 06, 2019 at 08:39:45AM +0800, Weijun Wang wrote: >>> On 05/03/2019 18:57, Nico Williams wrote: >>>> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: >>>>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. >>>> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub >>>> clone: >>>> >>> Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists. >> >> Yes, this is the rule. > > That's fair. > >> Also, I'm not sure what Peter is reviewing here as the title is not clear to >> me. Is it about all patches you are contributing? Or is it about the OpenJDK > > Yes. > >> bugs we have already filed (which is only the first few steps of the big >> contribution)?. You are OK to discuss any change you are preparing to >> contribute anywhere, but once you decide to contribute a piece of code into >> OpenJDK, please follow these steps: > > We did decide to make a contribution. I thought your making a webrev > for it, and my being approved to be a contributor, kickstarted the > process. > >> 1. File a bug or RFE (If you cannot do that, ask me). > > How? Tell me the title and description of the bug/RFE, and I'll create one like https://bugs.openjdk.java.net/browse/JDK-8212217. > >> 2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n >> for code review, or the patch is short, include it in the mail. > > You did the first part. I did the second. You're an author now, right? You can post one yourself, webrev is at https://hg.openjdk.java.net/code-tools/webrev. If see see any problem, you can always send me a patch and I can post a webrev. Anyway we need to do this one by one. > >> 3. Anyone can reply the mail. > > So Peter, for example, doesn't need to be a contributor? Anyone can reply, but to push the change, a formal openjdk reviewer is needed. If Peter rewrite the patch in total then he might need to sign the OCA. > >> You might heard there is a effort [1] going on about switching to >> another SCM or hosting service, but not now yet. > > Right, GitHub is sure a lot more convenient than webrevs. Hope so, but I do switch between the udiff, sdiff, frames and new views of webrev a lot. It's not very friendly to comment of course. --Max > > Nico > -- From sgehwolf at redhat.com Wed Mar 6 09:55:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 06 Mar 2019 10:55:04 +0100 Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o shutdown In-Reply-To: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> References: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> Message-ID: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com> On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote: > It looks like this is JDK-8214418 - which has been fixed > in 12.0.1 b03 and 13-ea b04. Is there any reason why JDK-8214418 is not public? "You can't view this issue" Thanks, Severin From sean.mullan at oracle.com Wed Mar 6 18:32:19 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Mar 2019 13:32:19 -0500 Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy In-Reply-To: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com> References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com> Message-ID: Hi Xuelei, In the Specification section, I think it would be useful to note which cipher suites are forward secret and which are not. Otherwise, it is difficult to see what has changed, since there are so many supported suites. Perhaps in parentheses, ex: TLS_AES_128_GCM_SHA256 (forward secret) ... I also think you should summarize what has changed or what is roughly the new order, for example: - The TLS_RSA suites have moved down ... - The TLS_ECDH suites have moved - The SSL_RSA suites have moved down ... etc... --Sean On 2/21/19 4:45 PM, Xuelei Fan wrote: > Hi, > > Could I get the CSR reviewed? > ??? https://bugs.openjdk.java.net/browse/JDK-8219545 > > It is proposed to increase the priority of forward secrecy cipher > suites, and decrease the priority of RSA key exchange based cipher > suites for the default enabled cipher suites in the SunJSSE provider. > > Thanks, > Xuelei From sean.mullan at oracle.com Wed Mar 6 20:50:15 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 6 Mar 2019 15:50:15 -0500 Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o shutdown In-Reply-To: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com> References: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com> Message-ID: <4b61df3f-a85f-908e-9a77-062381b4fdac@oracle.com> On 3/6/19 4:55 AM, Severin Gehwolf wrote: > On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote: >> It looks like this is JDK-8214418 - which has been fixed >> in 12.0.1 b03 and 13-ea b04. > > Is there any reason why JDK-8214418 is not public? > > "You can't view this issue" There are internal hostnames and ip addresses and other potentially sensitive content in the bug description (it was a dump of a test log). I think we would have to remove that sensitive information and copy it into a new bug otherwise it would still be in the bug history if we made it public. Doesn't seem worth it at this point since it is already fixed. --Sean From anthony.scarpino at oracle.com Wed Mar 6 23:04:25 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 6 Mar 2019 15:04:25 -0800 Subject: RFR [13] 8220165: Encryption using GCM results in RuntimeException- input length out of bound Message-ID: Hi Can I get a review of a simple fix to the previous GCM change that got the lengths wrong on large data sizes. I thought I covered this in my original testing, but I guess not. So with this I created a test to check larger data sizes and different byte lengths http://cr.openjdk.java.net/~ascarpino/8220165/ Tony From ecki at zusammenkunft.net Wed Mar 6 23:41:42 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 6 Mar 2019 23:41:42 +0000 Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy In-Reply-To: References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>, Message-ID: I am not clear on what would ?preferred in current default context? mean. Does that mean it preferred the PFS ciphers anyway.. for suggested order in client handshake? as server? And what would be the non-Default context. Is this ?TLS? context? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Sean Mullan Gesendet: Mittwoch, M?rz 6, 2019 9:12 PM An: security-dev at openjdk.java.net Betreff: Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy Hi Xuelei, In the Specification section, I think it would be useful to note which cipher suites are forward secret and which are not. Otherwise, it is difficult to see what has changed, since there are so many supported suites. Perhaps in parentheses, ex: TLS_AES_128_GCM_SHA256 (forward secret) ... I also think you should summarize what has changed or what is roughly the new order, for example: - The TLS_RSA suites have moved down ... - The TLS_ECDH suites have moved - The SSL_RSA suites have moved down ... etc... --Sean On 2/21/19 4:45 PM, Xuelei Fan wrote: > Hi, > > Could I get the CSR reviewed? > https://bugs.openjdk.java.net/browse/JDK-8219545 > > It is proposed to increase the priority of forward secrecy cipher > suites, and decrease the priority of RSA key exchange based cipher > suites for the default enabled cipher suites in the SunJSSE provider. > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Mar 7 02:52:05 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 Mar 2019 18:52:05 -0800 Subject: RFR [13] 8220165: Encryption using GCM results in RuntimeException- input length out of bound In-Reply-To: References: Message-ID: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com> Hi Tony, Source change looks fine. For the regression test GCMLargeDataKAT.java 1) typo on line 42, "has" -> "hash". 2) Line 128, we should also check result.length to be the expected value, i.e. data.length - GCM_TAG_LENGTH. 3) Currently, the test continues even if enc check failed (line149-155). If the enc result is incorrect, why proceed with decryption? Perhaps, testing against the next key (i.e. data length) after line 155? 4) Remove line 184-189 as they are not used? 5) line 195, no need for this being public? 6) Are 65536, 65537 and 67584 input sizes add additional coverage? For data sizes 102400 to 102416, they can easily be tested with two byte[]s, sizes 102400 and 16. Thanks, Valerie On 3/6/2019 3:04 PM, Anthony Scarpino wrote: > Hi > > Can I get a review of a simple fix to the previous GCM change that got > the lengths wrong on large data sizes.? I thought I covered this in my > original testing, but I guess not.? So with this I created a test to > check larger data sizes and different byte lengths > > http://cr.openjdk.java.net/~ascarpino/8220165/ > > Tony > From andimullaraj at gmail.com Thu Mar 7 07:46:23 2019 From: andimullaraj at gmail.com (Andi Mullaraj) Date: Wed, 6 Mar 2019 23:46:23 -0800 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: Hi again, > That implies multiple threads using 1 selector ... It definitely looks like we are talking about different things. You seem to be talking about *how to use a Selector and encrypt/decrypt ssl and do it in an efficient way in order to build some server or so*. I am talking about *providing an SSLSelector (which agreed, would be wrapping a Selector and handle the encrypt/decrypt) of the same exact API/Semantics/Functionality as a Selector*. I agree the implementation is super complex, that's why I keep swerving away from implementation details. I agree with you that there is no point in using one Selector (either flavor) from a multitude of threads, but (since I am on the provider side) in order to claim the SSLSelector is a true reflection of a Selector I have to provide a way to make it work even when callers perform concurrent select() operations from various threads (which normally results in the locks being acquired in the order defined in the documentation). So yes,the implementation is even more complex than you actually describe it, but doable and very performant as well. So, trying to swerve back to the API discussion, I will re ask my last question in a different way: If you have developed an application which communicates in TCP using java.nio.channels package classes (one Selector, multiple SocketChannel, one or more threads, doesn't matter), and you wanted to enhance your application to be able to communicate over SSL, what would stop you from using an SSLSelector with SSLSocketChannels (just import them, pass the SSLContext during the SSLSocketChannelCreation, recompile and done)? *Restating that the implementation is in pure Java, with no extra threads for selection, with minimal cpu and memory impact (only for SSL channels) over the current implementation. What would prevent someone from using it?* Thanks again, --Andi On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller wrote: > I am beginning to think we might be on different pages here. Someone from >> outside the selector calls selector.select(), and all selector's >> functionality is handled within the context of the calling thread. So where >> is the need for the extra thread here? More specifically, in the >> SSLSelector case, a call to its select, ends up usually to a call to its >> inner selector.select(), always in the context of the calling thread ... so >> same thing again. Why do you think another thread is necessary here (within >> the selector itself)? >> > > That implies multiple threads using 1 selector. That can be very > dangerous and prone to bugs. Even with SSL, I would shy away from making > something like that unless putting it behind some library/abstraction like > netty, webpieces channelmanager or something. > > In fact, the performance of 1 thread that runs the selector who dishes the > work to a threadpool immediately (N sockets to X threads) has been > amazing!!! *It was even better than multiple threads on a selector we > found.* This was because that caused lots of contention with > locks(slowing it down). The contention depended on the application as some > apps had more contention than others. I would highly advise just sticking > 1 thread on the selector dishing out to a thread pool which removed all > contention to streamline the whole process for speed. > > THEN, if you do have a threadpool and an simple implementation that runs > the data serially per socket in the threadpool(this is quite easy to do), > you can do the decryption in the threadpool as well. webpieces impl does > this as well. > > just my 2 cents, > later, > > Dean > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Mar 7 10:59:36 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 Mar 2019 10:59:36 +0000 Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o shutdown In-Reply-To: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com> References: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com> <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com> Message-ID: Hi Severin, Yes - sorry about that - as Sean explained we had to keep that bug report private. However you should be able to find all the information about the issue in the public review thread in the security-dev archive: http://mail.openjdk.java.net/pipermail/security-dev/2018-December/019100.html http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019142.html Hope this help, -- daniel On 06/03/2019 09:55, Severin Gehwolf wrote: > On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote: >> It looks like this is JDK-8214418 - which has been fixed >> in 12.0.1 b03 and 13-ea b04. > > Is there any reason why JDK-8214418 is not public? > > "You can't view this issue" > > Thanks, > Severin > From sean.mullan at oracle.com Thu Mar 7 15:02:39 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 7 Mar 2019 10:02:39 -0500 Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager In-Reply-To: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com> <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com> Message-ID: On 3/5/19 7:50 PM, Weijun Wang wrote: > The fix looks fine to me. > > However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy? If you specify the UNC policy file as just a file pathname (and not a "file:" URL), ex: -Djava.security.policy=\\host\Users\duke\java.policy In this case, the Policy implementation converts the canonical form of the path into an encoded "file:" URL (see sun.net.www.ParseUtil.fileToEncodedURL) and the URL works when passed to PolicyUtil.getInputStream (which decodes it into a path and opens it with FileInputStream). However, if you specify the UNC policy file as a "file:" URL, it depends on the user getting the proper URL encoding (escaped characters, etc) right. For example: -Djava.security.policy=file:\\host\Users\duke\java.policy will not work because it ignores the hostname and tries to load \Users\duke\java.policy. However: -Djava.security.policy=file:\\\\host\Users\duke\java.policy does work. I'm not entirely sure, but I think it has something to do with escaping the leading backslashes so that it is not considered a host part of the URL. There's possibly some unnecessary overhead encoding the path into a URL and decoding back again, but I don't want to tinker with it unless there is a known issue. --Sean > > I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer. > > Thanks, > Max > >> On Mar 6, 2019, at 3:53 AM, Sean Mullan wrote: >> >> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError. >> >> The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard). >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/ >> bugid: https://bugs.openjdk.java.net/browse/JDK-8218618 >> >> --Sean > From anthony.scarpino at oracle.com Thu Mar 7 18:25:46 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 7 Mar 2019 10:25:46 -0800 Subject: RFR [13] 8220165: Encryption using GCM results in RuntimeException- input length out of bound In-Reply-To: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com> References: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com> Message-ID: On 3/6/19 6:52 PM, Valerie Peng wrote: > Hi Tony, > > Source change looks fine. > > For the regression test GCMLargeDataKAT.java > 1) typo on line 42, "has" -> "hash". > 2) Line 128, we should also check result.length to be the expected > value, i.e. data.length - GCM_TAG_LENGTH. I had intentionally left a length check out figuring that a nulled plaintext would have to be the proper length, but I guess it worth to check the array was returned property > 3) Currently, the test continues even if enc check failed (line149-155). > If the enc result is incorrect, why proceed with decryption? Perhaps, > testing against the next key (i.e. data length) after line 155? Yeah, that's true. > 4) Remove line 184-189 as they are not used? It's used to create new data lengths if passed a length argument. As I was able to do with your point #6. In jtreg operation it is not used. > 5) line 195, no need for this being public? yep > 6) Are 65536, 65537 and 67584 input sizes add additional coverage? For > data sizes 102400 to 102416, they can easily be tested with two byte[]s, > sizes 102400 and 16. I chose them when I was debugging the problem and left them there. I added a few more lengths around the AES block size. 64k is when the intrinsic warmup code starts, so anything above 65535 is equally relevant to test. I used 102400 through 102416 just to cover every byte. I also changed the plaintext to use one byte array instead of encrypt(new byte[inLen]) new webrev: http://cr.openjdk.java.net/~ascarpino/8220165/webrev.01/ > Thanks, > Valerie > On 3/6/2019 3:04 PM, Anthony Scarpino wrote: >> Hi >> >> Can I get a review of a simple fix to the previous GCM change that got >> the lengths wrong on large data sizes.? I thought I covered this in my >> original testing, but I guess not.? So with this I created a test to >> check larger data sizes and different byte lengths >> >> http://cr.openjdk.java.net/~ascarpino/8220165/ >> >> Tony >> From philipp.kunz at paratix.ch Thu Mar 7 15:27:30 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 07 Mar 2019 16:27:30 +0100 Subject: Jarsigner compatibility issue invalidating existing signatures In-Reply-To: References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> Message-ID: <1551972450.2495.29.camel@paratix.ch> Hi, Following up [1], [2] and to some extent [3] find a new patch attached. Apart from ManifestDigester having problems parsing manifests with \r for the line break, manifests without a trailing blank line are not processed correctly in all cases. As an example, look at the existing diffend.sh test which produces a jar diffend.new.jar file with an invalid signature on lines 88..93.?Jarsigner fails to detect this and so does the test. The resulting manifest is missing a blank line after the main attributes section and looks like this: Manifest-Version: 1.0 Created-By: 1.7.0-internal (Sun Microsystems Inc.) Today: Monday Name: 1 SHA1-Digest: 5fpE8rMcH7VTtgIec2DQfV2R/14= Another speciality is that endOfSection contains a blank line if and only if that blank line is at the very end of the manifest file (or stream or byte array). This makes digestWorkaround useless in that case because digestWorkaround is then the same as digest without workaround. Initially I thought, the missing lines after the last section could be compensated by digestWorkaround which essentially produces a digest without the trailing blank line but digestWorkaround is not applied to main attributes and if successful would set SignatureFileVerifier.workaround flag that would remain set for subsequent digests which are processed in the order of the entries of the signature file which is hard to predict and certainly does not support to assume that the last manifest entry would be verified last. As a starting point for further discussions, I'd like to suggest that jarsigner keeps main attributes without a trailing blank line if there are no files contained in the jar to sign. I wonder if this is worth it but at least I believe that this is the most backwards-compatible option possible. A trailing line is then added only when necessary and the resulting jarfile would be invalid without as in the example above with diffend.sh. Any feedback and opinions welcome. Regards, Philipp [1] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0 19200.html [2] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0 19213.html [3] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February /058774.html [4] https://bugs.openjdk.java.net/browse/JDK-8217375 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8217375.patch Type: text/x-patch Size: 315333 bytes Desc: not available URL: From dhiller at twitter.com Thu Mar 7 15:50:38 2019 From: dhiller at twitter.com (Dean Hiller) Date: Thu, 7 Mar 2019 08:50:38 -0700 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: I think nothing would prevent it but they chose to separate the SSL from the nio such that it was more re-usable and opted to not spend the money/time on creating an SSLSelector knowing people could program it on top. (ie. the history). Most stuff should be done outside the jdk anyways. ie. look at logback and how good it is and how the jdk logging which tried to copy log4j(and failed) kinda sucks. The federation model in my opinion is better with libraries on top of nio out in the wild. Coming back to why not do it? There are so many things on their plate already and the problem of ssl over nio is solved so why spend money to make it more perfect with so many other issues and things to work on that are most likely more important. Dean On Thu, Mar 7, 2019 at 12:46 AM Andi Mullaraj wrote: > Hi again, > > > That implies multiple threads using 1 selector ... > > It definitely looks like we are talking about different things. You seem > to be talking about *how to use a Selector and encrypt/decrypt ssl and do > it in an efficient way in order to build some server or so*. I am talking > about *providing an SSLSelector (which agreed, would be wrapping a Selector > and handle the encrypt/decrypt) of the same exact > API/Semantics/Functionality as a Selector*. > > I agree the implementation is super complex, that's why I keep swerving > away from implementation details. I agree with you that there is no point > in using one Selector (either flavor) from a multitude of threads, but > (since I am on the provider side) in order to claim the SSLSelector is a > true reflection of a Selector I have to provide a way to make it work even > when callers perform concurrent select() operations from various threads > (which normally results in the locks being acquired in the order defined in > the documentation). So yes,the implementation is even more complex than you > actually describe it, but doable and very performant as well. > > So, trying to swerve back to the API discussion, I will re ask my last > question in a different way: If you have developed an application which > communicates in TCP using java.nio.channels package classes (one Selector, > multiple SocketChannel, one or more threads, doesn't matter), and you > wanted to enhance your application to be able to communicate over SSL, what > would stop you from using an SSLSelector with SSLSocketChannels (just > import them, pass the SSLContext during the SSLSocketChannelCreation, > recompile and done)? *Restating that the implementation is in pure Java, > with no extra threads for selection, with minimal cpu and memory impact > (only for SSL channels) over the current implementation. What would prevent > someone from using it?* > > Thanks again, > --Andi > > > > On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller wrote: > >> I am beginning to think we might be on different pages here. Someone from >>> outside the selector calls selector.select(), and all selector's >>> functionality is handled within the context of the calling thread. So where >>> is the need for the extra thread here? More specifically, in the >>> SSLSelector case, a call to its select, ends up usually to a call to its >>> inner selector.select(), always in the context of the calling thread ... so >>> same thing again. Why do you think another thread is necessary here (within >>> the selector itself)? >>> >> >> That implies multiple threads using 1 selector. That can be very >> dangerous and prone to bugs. Even with SSL, I would shy away from making >> something like that unless putting it behind some library/abstraction like >> netty, webpieces channelmanager or something. >> >> In fact, the performance of 1 thread that runs the selector who dishes >> the work to a threadpool immediately (N sockets to X threads) has been >> amazing!!! *It was even better than multiple threads on a selector we >> found.* This was because that caused lots of contention with >> locks(slowing it down). The contention depended on the application as some >> apps had more contention than others. I would highly advise just sticking >> 1 thread on the selector dishing out to a thread pool which removed all >> contention to streamline the whole process for speed. >> >> THEN, if you do have a threadpool and an simple implementation that runs >> the data serially per socket in the threadpool(this is quite easy to do), >> you can do the decryption in the threadpool as well. webpieces impl does >> this as well. >> >> just my 2 cents, >> later, >> >> Dean >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Mar 8 00:56:22 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Mar 2019 16:56:22 -0800 Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the SunJSSE provider" Message-ID: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> Hi Brad, Do you have time to help review the changes for JDK-8220016? Current changes are to register the same list of RSA-related services as these prior to the fix for JDK-7092821. I am not sure what are the old RSA impls for pre-JDK1.4 implementations. Otherwise, I can remove them as well. Please let me know. Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Fri Mar 8 00:58:17 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Mar 2019 16:58:17 -0800 Subject: [13] RFR JDK-8213008 "Cipher with UNWRAP_MODE should support the generation of an AES key type" Message-ID: <5c71b918-e320-676f-b318-065900911b38@oracle.com> Anyone has time to help review this fix? According to the bug report, some vendors require the keytype attribute to match the encryption algorithm. So, the change is to match the key type based on the algorithm specified. There is no regression test as this issue is not reproducible against Solaris or NSS PKCS11 libraries. Bug: https://bugs.openjdk.java.net/browse/JDK-8213008 Webrev: http://cr.openjdk.java.net/~valeriep/8213008/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Fri Mar 8 01:23:01 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 7 Mar 2019 17:23:01 -0800 Subject: [13] RFR JDK-8213008 "Cipher with UNWRAP_MODE should support the generation of an AES key type" In-Reply-To: <5c71b918-e320-676f-b318-065900911b38@oracle.com> References: <5c71b918-e320-676f-b318-065900911b38@oracle.com> Message-ID: <706980d0-70fe-52c7-3a3f-b23953637583@oracle.com> This change looks fine. Tony On 3/7/19 4:58 PM, Valerie Peng wrote: > > Anyone has time to help review this fix? According to the bug report, > some vendors require the keytype attribute to match the encryption > algorithm. So, the change is to match the key type based on the > algorithm specified. There is no regression test as this issue is not > reproducible against Solaris or NSS PKCS11 libraries. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213008 > > Webrev: http://cr.openjdk.java.net/~valeriep/8213008/webrev.00/ > > Thanks, > > Valerie > From valerie.peng at oracle.com Fri Mar 8 01:36:10 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Mar 2019 17:36:10 -0800 Subject: RFR [13] 8220165: Encryption using GCM results in RuntimeException- input length out of bound In-Reply-To: References: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com> Message-ID: <78c87261-f63e-f664-bf7e-2473352fbe7f@oracle.com> Updated webrev looks good. Thanks, Valerie On 3/7/2019 10:25 AM, Anthony Scarpino wrote: > On 3/6/19 6:52 PM, Valerie Peng wrote: >> Hi Tony, >> >> Source change looks fine. >> >> For the regression test GCMLargeDataKAT.java >> 1) typo on line 42, "has" -> "hash". >> 2) Line 128, we should also check result.length to be the expected >> value, i.e. data.length - GCM_TAG_LENGTH. > > I had intentionally left a length check out figuring that a nulled > plaintext would have to be the proper length, but I guess it worth to > check the array was returned property > >> 3) Currently, the test continues even if enc check failed >> (line149-155). If the enc result is incorrect, why proceed with >> decryption? Perhaps, testing against the next key (i.e. data length) >> after line 155? > > Yeah, that's true. > >> 4) Remove line 184-189 as they are not used? > > It's used to create new data lengths if passed a length argument. As I > was able to do with your point #6.? In jtreg operation it is not used. > >> 5) line 195, no need for this being public? > > yep > >> 6) Are 65536, 65537 and 67584 input sizes add additional coverage? >> For data sizes 102400 to 102416, they can easily be tested with two >> byte[]s, sizes 102400 and 16. > > I chose them when I was debugging the problem and left them there.? I > added a few more lengths around the AES block size.? 64k is when the > intrinsic warmup code starts, so anything above 65535 is equally > relevant to test.? I used 102400 through 102416 just to cover every byte. > > I also changed the plaintext to use one byte array instead of > encrypt(new byte[inLen]) > > new webrev: > http://cr.openjdk.java.net/~ascarpino/8220165/webrev.01/ > > >> Thanks, >> Valerie >> On 3/6/2019 3:04 PM, Anthony Scarpino wrote: >>> Hi >>> >>> Can I get a review of a simple fix to the previous GCM change that >>> got the lengths wrong on large data sizes.? I thought I covered this >>> in my original testing, but I guess not.? So with this I created a >>> test to check larger data sizes and different byte lengths >>> >>> http://cr.openjdk.java.net/~ascarpino/8220165/ >>> >>> Tony >>> From xuelei.fan at oracle.com Fri Mar 8 01:45:56 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Mar 2019 17:45:56 -0800 Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the SunJSSE provider" In-Reply-To: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> Message-ID: Hi Valerie, As you are already there, I may suggest to remove the old RSA crypto algorithms in the SunJSSE providers as well. As may simplify the code a little bit, though a CSR is needed for the SunJSSE behavior change. Thanks, Xuelei On 3/7/2019 4:56 PM, Valerie Peng wrote: > Hi Brad, > > Do you have time to help review the changes for JDK-8220016? Current > changes are to register the same list of RSA-related services as these > prior to the fix for JDK-7092821. I am not sure what are the old RSA > impls for pre-JDK1.4 implementations. Otherwise, I can remove them as > well. Please let me know. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 > > Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Fri Mar 8 02:15:10 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 Mar 2019 18:15:10 -0800 Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the SunJSSE provider" In-Reply-To: References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> Message-ID: Do you mean removing the part about SunRsaSignEntries completely? Or only remove the MD2/MD5withRSA signature algorithms? Do you know the history of including them in the first place? Since SunRsaSign provider has been in early JDK releases, I wonder why SunJSSE provider duplicated these RSA algorithms in the first place? I can file a CSR, knowing the history/reason would help. Thanks, Valerie On 3/7/2019 5:45 PM, Xuelei Fan wrote: > Hi Valerie, > > As you are already there, I may suggest to remove the old RSA crypto > algorithms in the SunJSSE providers as well.? As may simplify the code > a little bit, though a CSR is needed for the SunJSSE behavior change. > > Thanks, > Xuelei > > On 3/7/2019 4:56 PM, Valerie Peng wrote: >> Hi Brad, >> >> Do you have time to help review the changes for JDK-8220016? Current >> changes are to register the same list of RSA-related services as >> these prior to the fix for JDK-7092821. I am not sure what are the >> old RSA impls for pre-JDK1.4 implementations. Otherwise, I can remove >> them as well. Please let me know. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >> >> Thanks, >> Valerie From xuelei.fan at oracle.com Fri Mar 8 03:30:58 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Mar 2019 19:30:58 -0800 Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the SunJSSE provider" In-Reply-To: References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> Message-ID: <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> On 3/7/2019 6:15 PM, Valerie Peng wrote: > Do you mean removing the part about SunRsaSignEntries completely? Or > only remove the MD2/MD5withRSA signature algorithms? > I meant to remove the SunRsaSignEntries completely from the SunJSSE provider. > Do you know the history of including them in the first place? Since > SunRsaSign provider has been in early JDK releases, I wonder why SunJSSE > provider duplicated these RSA algorithms in the first place? The JSSE provider was originally provided as an standalone library, and using the com.sun.net.ssl packet. I think it was in JDK 1.4, the package became part of JDK, and start to using the javax.net.ssl package and the standard JCE providers. However, for compatibility, the old supported signature algorithms are still linked in the SunJSSE provider. In the JDK 9, a noted was added in the SunJSSE provider documentation: The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for Signature. The compatibility is mainly about coding with explicitly SunJSSE provider name. For example, Signature.getInstance("SHA1withRSA", "com.sun.net.ssl.internal.ssl.Provider"); The use may not be common in practice. And the JDK JCE providers support these algorithms, I was wondering the risk of removing them from the SunJSSE provider may be low now. Thanks, Xuelei > I can file a CSR, knowing the history/reason would help. > > Thanks, > > Valerie > > > On 3/7/2019 5:45 PM, Xuelei Fan wrote: >> Hi Valerie, >> >> As you are already there, I may suggest to remove the old RSA crypto >> algorithms in the SunJSSE providers as well.? As may simplify the code >> a little bit, though a CSR is needed for the SunJSSE behavior change. >> >> Thanks, >> Xuelei >> >> On 3/7/2019 4:56 PM, Valerie Peng wrote: >>> Hi Brad, >>> >>> Do you have time to help review the changes for JDK-8220016? Current >>> changes are to register the same list of RSA-related services as >>> these prior to the fix for JDK-7092821. I am not sure what are the >>> old RSA impls for pre-JDK1.4 implementations. Otherwise, I can remove >>> them as well. Please let me know. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >>> >>> Thanks, >>> Valerie From andimullaraj at gmail.com Fri Mar 8 22:17:28 2019 From: andimullaraj at gmail.com (Andi Mullaraj) Date: Fri, 8 Mar 2019 14:17:28 -0800 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: Inline my comments but putting this upfront so that it doesn't go unnoticed for the occasional reader: I was directed to this forum for discussing the merits and technicals details of a possible SSLSelector/SSLSocketChannels. The level of engagement seems to be very minimal though (I appreciate the effort of the two members pitching their feedback). The best I have heard was "[..] make SSL with Selectors easier, because right now it is very painful. But this approach is unlikely to succeed, at least in the JDK.", but without saying why. Every Java developer I pitch this idea to, says the same thing "Are you sure that SSLSelector/SSLSocketChannels are not in JDK? It cannot be ...". I proposed a concrete API but never got any feedback on that. I would really appreciate if someone could tell me if this is the right path/forum for discussing this. Best, --Andi Mullaraj > I think nothing would prevent it Great. > but they chose to separate the SSL from the nio such that it was more re-usable and opted to not spend the money/time on creating an SSLSelector knowing people could program it on top. (ie. the history). That decision must have been made 15 years ago. > Most stuff should be done outside the jdk anyways. ie. look at logback and how good it is and how the jdk logging which tried to copy log4j(and failed) kinda sucks. The reason I tackled this problem 2 years ago is that I could find no third-party implementation of SSLSocketChannels with Selectors. I checked how other applications dealt with that and felt the pain they must have felt to get huge dependencies in, just to get a functionality as primordial as this. > The federation model in my opinion is better with libraries on top of nio out in the wild. The base java.nio.channels follows a federation model (SPI) and so could this. Nothing would prevent a third party to plug in their desired implementation (if there existed others, beyond the default) > Coming back to why not do it? There are so many things on their plate already I assume you are referring to the main/Oracle contributors being busy. I certainly looks like that. > and the problem of ssl over nio is solved so why spend money to make it more perfect with so many other issues and things to work on that are most likely more important. This must be related to the pain threshold. I believe (and David also mentioned) that working with SSLEngine is very painful. I mean, in order to achieve a robust application with no edge cases especially when security comes into play. This is not about making it perfect, it is about offering something decent that, IMO, should have been there in first place. Thanks, --Andi On Thu, Mar 7, 2019 at 7:50 AM Dean Hiller wrote: > I think nothing would prevent it but they chose to separate the SSL from > the nio such that it was more re-usable and opted to not spend the > money/time on creating an SSLSelector knowing people could program it on > top. (ie. the history). > > Most stuff should be done outside the jdk anyways. ie. look at logback > and how good it is and how the jdk logging which tried to copy log4j(and > failed) kinda sucks. > > The federation model in my opinion is better with libraries on top of nio > out in the wild. > > Coming back to why not do it? There are so many things on their plate > already and the problem of ssl over nio is solved so why spend money to > make it more perfect with so many other issues and things to work on that > are most likely more important. > > Dean > > > On Thu, Mar 7, 2019 at 12:46 AM Andi Mullaraj > wrote: > >> Hi again, >> >> > That implies multiple threads using 1 selector ... >> >> It definitely looks like we are talking about different things. You seem >> to be talking about *how to use a Selector and encrypt/decrypt ssl and do >> it in an efficient way in order to build some server or so*. I am talking >> about *providing an SSLSelector (which agreed, would be wrapping a Selector >> and handle the encrypt/decrypt) of the same exact >> API/Semantics/Functionality as a Selector*. >> >> I agree the implementation is super complex, that's why I keep swerving >> away from implementation details. I agree with you that there is no point >> in using one Selector (either flavor) from a multitude of threads, but >> (since I am on the provider side) in order to claim the SSLSelector is a >> true reflection of a Selector I have to provide a way to make it work even >> when callers perform concurrent select() operations from various threads >> (which normally results in the locks being acquired in the order defined in >> the documentation). So yes,the implementation is even more complex than you >> actually describe it, but doable and very performant as well. >> >> So, trying to swerve back to the API discussion, I will re ask my last >> question in a different way: If you have developed an application which >> communicates in TCP using java.nio.channels package classes (one Selector, >> multiple SocketChannel, one or more threads, doesn't matter), and you >> wanted to enhance your application to be able to communicate over SSL, what >> would stop you from using an SSLSelector with SSLSocketChannels (just >> import them, pass the SSLContext during the SSLSocketChannelCreation, >> recompile and done)? *Restating that the implementation is in pure Java, >> with no extra threads for selection, with minimal cpu and memory impact >> (only for SSL channels) over the current implementation. What would prevent >> someone from using it?* >> >> Thanks again, >> --Andi >> >> >> >> On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller wrote: >> >>> I am beginning to think we might be on different pages here. Someone >>>> from outside the selector calls selector.select(), and all selector's >>>> functionality is handled within the context of the calling thread. So where >>>> is the need for the extra thread here? More specifically, in the >>>> SSLSelector case, a call to its select, ends up usually to a call to its >>>> inner selector.select(), always in the context of the calling thread ... so >>>> same thing again. Why do you think another thread is necessary here (within >>>> the selector itself)? >>>> >>> >>> That implies multiple threads using 1 selector. That can be very >>> dangerous and prone to bugs. Even with SSL, I would shy away from making >>> something like that unless putting it behind some library/abstraction like >>> netty, webpieces channelmanager or something. >>> >>> In fact, the performance of 1 thread that runs the selector who dishes >>> the work to a threadpool immediately (N sockets to X threads) has been >>> amazing!!! *It was even better than multiple threads on a selector we >>> found.* This was because that caused lots of contention with >>> locks(slowing it down). The contention depended on the application as some >>> apps had more contention than others. I would highly advise just sticking >>> 1 thread on the selector dishing out to a thread pool which removed all >>> contention to streamline the whole process for speed. >>> >>> THEN, if you do have a threadpool and an simple implementation that runs >>> the data serially per socket in the threadpool(this is quite easy to do), >>> you can do the decryption in the threadpool as well. webpieces impl does >>> this as well. >>> >>> just my 2 cents, >>> later, >>> >>> Dean >>> I assume >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Sat Mar 9 02:20:50 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 8 Mar 2019 20:20:50 -0600 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj wrote: > > Inline my comments but putting this upfront so that it doesn't go unnoticed for the occasional reader: > > I was directed to this forum for discussing the merits and technicals details of a possible SSLSelector/SSLSocketChannels. The level of engagement seems to be very minimal though (I appreciate the effort of the two members pitching their feedback). The best I have heard was "[..] make SSL with Selectors easier, because right now it is very painful. But this approach is unlikely to succeed, at least in the JDK.", but without saying why. The answer is that selectors are for implementing event loops. SSL is a thing that applies to sockets. Combining them doesn't make sense from any rational engineering perspective. Having a special Selector type for SSL channels is weird, period. It's ugly, it smells. It doesn't solve the problem in a clean way. It's certainly not the *best* solution. And what other things will we then need special Selector types for? If the answer is "nothing", then why do we need a special Selector subclass for SSL to begin with, instead of just using Selector? > Every Java developer I pitch this idea to, says the same thing "Are you sure that SSLSelector/SSLSocketChannels are not in JDK?" All this says is that the Java developers you have talked to have (a) never implemented non-blocking SSL (as evidenced by the fact that they do not have any familiarity with the APIs) and (b) therefore do not understand the complexities therein, or to put it more bluntly, they have no idea what they're talking about. I mean saying that Joe Developer thinks some complex thing they've never looked at or bothered to understand ought to be simple isn't really a great argument for a lot of otherwise very busy people to drop everything to review something that they know, based on their own expertise, isn't really a workable solution to the problem. > > but they chose to separate the SSL from the nio such that it was more re-usable and opted to not spend the money/time on creating an SSLSelector knowing people could program it on top. (ie. the history). > That decision must have been made 15 years ago. This, for the record, has nothing to do with anything. Some things designed long ago are good; some are not good. Age doesn't make ideas go rotten. These decisions were made for good reasons; the result may not be perfect but it's not significantly worse now than in the 1.4 days. The OS-level APIs that underpin Selector have not changed that much either. > > Most stuff should be done outside the jdk anyways. ie. look at logback and how good it is and how the jdk logging which tried to copy log4j(and failed) kinda sucks. > The reason I tackled this problem 2 years ago is that I could find no third-party implementation of SSLSocketChannels with Selectors. I checked how other applications dealt with that and felt the pain they must have felt to get huge dependencies in, just to get a functionality as primordial as this. The correct abstraction you're looking for is not a Selector, it's an "event loop". It is possible to have an API based on Channels that is ready-callback driven instead of Selector-driven, and such an API can support SSL cleanly. This is the basis of my XNIO project. It is only slightly higher level than Selector; the Channels are otherwise largely similar. Selector is just too low-level to abstract the concept neatly (see: countless discussions about the difficulty of implementing the lowest-level event loop in every network daemon software written in the past 30 years). > This must be related to the pain threshold. I believe (and David also mentioned) that working with SSLEngine is very painful. I mean, in order to achieve a robust application with no edge cases especially when security comes into play. This is not about making it perfect, it is about offering something decent that, IMO, should have been there in first place. What you're looking for is a better non-blocking approach to SSL, and I too would love to see it. If it ever comes to the JDK though, it would have to come in the form of a JDK-level event loop abstraction, with callback-driven channels that extend NIO. I don't see that happening unless it would be part of a long term plan to deprecate NIO: the JDK folks hate needless duplication. This seems unlikely. But hey, maybe it's time for that idea to get its day. -- - DML From andimullaraj at gmail.com Sat Mar 9 09:35:19 2019 From: andimullaraj at gmail.com (Andi Mullaraj) Date: Sat, 9 Mar 2019 01:35:19 -0800 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: Thanks for following up David, You just made my day. Really. I have finally something concrete in front of me that I can address. In interest of keeping this discussion in focus, I will bypass the rest and address a couple of key points from your response: > Having a special Selector type for SSL channels is weird, period. It's ugly, it smells. It doesn't solve the problem in a clean way. Cut & pasting from a previous message of mine in this same thread, here is the way a java.nio.channels loop works as of today (no SSL): Selector selector = Selector.open(); SocketChannel socketChannel = SocketChannel.open(); socketChannel.register(selector, SelectionKey.OP_READ); while(true) { selector.select(); for (SocketChannel sc : selector.selectedKeys() { sc.read(...) } } and here it is how it works with my implementation (which I am considering offering it to JDK): Selector selector = SSLSelector.open(); // notice the SSL SocketChannel socketChannel = SSLSocketChannel.open(); // notice the SSL socketChannel.register(selector, SelectionKey.OP_READ); while(true) { selector.select(); for (SocketChannel sc : selector.selectedKeys() { sc.read(...) } } Adding the following block to show the same (and some) if it ever made it to JDK -- is quite evident, but adding it here to avoid any possible misunderstanding: Selector selector = Selector.open(); // notice no SSL, but internally the SelectorProvider pics the SSLSelector SocketChannel socketChannel1 = SocketChannel.open(); // notice Plain SocketChannel socketChannel2 = SSLSocketChannel.open(); // notice SSL socketChannel1.register(selector, SelectionKey.OP_READ); // notice mixture of channels socketChannel2.register(selector, SelectionKey.OP_WRITE); // notice mixture of channels while(true) { selector.select(); for (SocketChannel sc : selector.selectedKeys() { if (sc.isReadable()) sc.read(...) if (sc.isWritable()) sc.write(...) } } So: 1. There is no special Selector (that the user sees), just the good old Selector. 2. The user creates SSLSocketChannels (and possibly SocketChannels, SSLServerSocketChannels, ServerSocketChannels) and registers them altogether with the Selector. What is ugly and smelly here? How much cleaner can we bridge today's world and tomorrow's? At the end of the day, a developer wants to use the same model, to achieve performant SSL communication the same way it used to with non-SSL communication. Just like in the blocking world, an InputStream can be obtained from a Socket or an SSLSocket, then it can be read upon in indistinguishable manner. > If it ever comes to the JDK though, it would have to come in the form of a JDK-level event loop abstraction, with callback-driven channels that extend NIO. I don't see that happening unless it would be part of a long term plan to deprecate NIO: the JDK folks hate needless duplication. This seems unlikely. But hey, maybe it's time for that idea to get its day. In light of the previous point, I couldn't disagree more. As it is painfully clear, the proposed approach stays within the confines of nio, and no duplication is needed (I also hate duplication). I am commenting on the rest, but I believe this is nearly not as important as the points above. Feel free to discard: > This, for the record, has nothing to do with anything. Some things designed long ago are good; some are not good. Age doesn't make ideas go rotten. Agreed. My answer has to be taken in the context of "... opted to not spend the money/time on creating an SSLSelector knowing people could program it on top" > The correct abstraction you're looking for is not a Selector, it's an "event loop". The "event loop" or whatever pattern that can be chosen today will be possible tomorrow with the proposed API. XNIO should be able to ingest this right in, same way (I assume) it does with Selector/SocketChannel, and without need to use SSLEngine to encrypt/decrypt SSL. > Selector is just too low-level to abstract the concept neatly (see: countless discussions about the difficulty of implementing the lowest-level event loop in every network daemon software written in the past 30 years). Not to say I don't follow discussions, but why should I when I can develop something myself, see it work perfectly, test it to work with hundreds of thousands of SSL connections on a single host, handling 23GBPS of SSL traffic on a 25GBPS network (75% usage over 48 CPUs)? Thanks again, --Andi On Fri, Mar 8, 2019 at 6:21 PM David Lloyd wrote: > On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj > wrote: > > > > Inline my comments but putting this upfront so that it doesn't go > unnoticed for the occasional reader: > > > > I was directed to this forum for discussing the merits and technicals > details of a possible SSLSelector/SSLSocketChannels. The level of > engagement seems to be very minimal though (I appreciate the effort of the > two members pitching their feedback). The best I have heard was "[..] make > SSL with Selectors easier, because right now it is very painful. But this > approach is unlikely to succeed, at least in the JDK.", but without saying > why. > > The answer is that selectors are for implementing event loops. SSL is > a thing that applies to sockets. Combining them doesn't make sense > from any rational engineering perspective. Having a special Selector > type for SSL channels is weird, period. It's ugly, it smells. It > doesn't solve the problem in a clean way. It's certainly not the > *best* solution. And what other things will we then need special > Selector types for? If the answer is "nothing", then why do we need a > special Selector subclass for SSL to begin with, instead of just using > Selector? > > > Every Java developer I pitch this idea to, says the same thing "Are you > sure that SSLSelector/SSLSocketChannels are not in JDK?" > > All this says is that the Java developers you have talked to have (a) > never implemented non-blocking SSL (as evidenced by the fact that they > do not have any familiarity with the APIs) and (b) therefore do not > understand the complexities therein, or to put it more bluntly, they > have no idea what they're talking about. I mean saying that Joe > Developer thinks some complex thing they've never looked at or > bothered to understand ought to be simple isn't really a great > argument for a lot of otherwise very busy people to drop everything to > review something that they know, based on their own expertise, isn't > really a workable solution to the problem. > > > > but they chose to separate the SSL from the nio such that it was more > re-usable and opted to not spend the money/time on creating an SSLSelector > knowing people could program it on top. (ie. the history). > > That decision must have been made 15 years ago. > > This, for the record, has nothing to do with anything. Some things > designed long ago are good; some are not good. Age doesn't make ideas > go rotten. These decisions were made for good reasons; the result may > not be perfect but it's not significantly worse now than in the 1.4 > days. The OS-level APIs that underpin Selector have not changed that > much either. > > > > Most stuff should be done outside the jdk anyways. ie. look at > logback and how good it is and how the jdk logging which tried to copy > log4j(and failed) kinda sucks. > > The reason I tackled this problem 2 years ago is that I could find no > third-party implementation of SSLSocketChannels with Selectors. I checked > how other applications dealt with that and felt the pain they must have > felt to get huge dependencies in, just to get a functionality as primordial > as this. > > The correct abstraction you're looking for is not a Selector, it's an > "event loop". It is possible to have an API based on Channels that is > ready-callback driven instead of Selector-driven, and such an API can > support SSL cleanly. This is the basis of my XNIO project. It is > only slightly higher level than Selector; the Channels are otherwise > largely similar. > > Selector is just too low-level to abstract the concept neatly (see: > countless discussions about the difficulty of implementing the > lowest-level event loop in every network daemon software written in > the past 30 years). > > > This must be related to the pain threshold. I believe (and David also > mentioned) that working with SSLEngine is very painful. I mean, in order to > achieve a robust application with no edge cases especially when security > comes into play. This is not about making it perfect, it is about offering > something decent that, IMO, should have been there in first place. > > What you're looking for is a better non-blocking approach to SSL, and > I too would love to see it. If it ever comes to the JDK though, it > would have to come in the form of a JDK-level event loop abstraction, > with callback-driven channels that extend NIO. I don't see that > happening unless it would be part of a long term plan to deprecate > NIO: the JDK folks hate needless duplication. This seems unlikely. > But hey, maybe it's time for that idea to get its day. > > -- > - DML > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 11 07:58:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2019 07:58:37 +0000 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: On 09/03/2019 09:35, Andi Mullaraj wrote: > > In light of the previous point, I couldn't disagree more. As it is > painfully clear, the proposed approach stays within the confines of > nio, and no duplication is needed (I also hate duplication). > This is a topic that was explored, and ruled out, in JSR-51 but lead to SSLEngine. Yes, SSLEngine has pain points and performance issues and I think it would be better to focus on those issues and see how SSLEngine could be improved. This would be more beneficial for the eco system today as most developers don't use SocketChannels or Selectors directly (those APIs tend to be hidden by libraries and frameworks so most developers don't see them). Also as a reminder is that we are exploring, in Project Loom, ways to make it easy to develop simple blocking code that scales as well as code forced to asynchronous frameworks today. If we get that right then it should eliminate many of the reasons to create further asynchronous or non-blocking APIs. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 11 10:31:01 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 Mar 2019 18:31:01 +0800 Subject: RFR 8220256: fix headings in java.security.sasl Message-ID: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com> Hi Jon, Please take a look at the patch below. diff --git a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java --- a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java +++ b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java @@ -30,7 +30,7 @@ * It is used by developers to add authentication support for * connection-based protocols that use SASL. * - *

SASL Overview

+ *

SASL Overview

* * Simple Authentication and Security Layer (SASL) specifies a * challenge-response protocol in which data is exchanged between the @@ -74,7 +74,7 @@ * allow negotiation of the security layer. For External, the * security layer is determined by the external protocol. * - *

Usage

+ *

Usage

* * Users of this API are typically developers who produce * client library implementations for connection-based protocols, In case you want to look at the whole file, its current content is at https://hg.openjdk.java.net/jdk/jdk/file/9a1dd1203a4f/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java . Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Mar 11 12:23:54 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 11 Mar 2019 08:23:54 -0400 Subject: Disable TLS 1.3 backward compatibility mode? In-Reply-To: References: Message-ID: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com> -bcc net-dev Copying security-dev as TLS 1.3 topics are more appropriate for that mailing list. --Sean On 3/10/19 3:24 PM, raell at web.de wrote: > Dear, > the Java TLS 1.3 implementation supports middlebox compatibility (e.g. > sends a non-empty session id and a ChangeCipherSpec message). Out of > interest: Is it possible to disable this compatibility mode? > Regards, Ralph From xuelei.fan at oracle.com Mon Mar 11 18:15:49 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 11 Mar 2019 11:15:49 -0700 Subject: Disable TLS 1.3 backward compatibility mode? In-Reply-To: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com> References: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com> Message-ID: Hi Ralph, Currently, TLS 1.3 is implemented in JDK in compatibility mode. Please feel free to submit a request if this feature matters to you. Regards, Xuelei On 3/11/2019 5:23 AM, Sean Mullan wrote: > -bcc net-dev > > Copying security-dev as TLS 1.3 topics are more appropriate for that > mailing list. > > --Sean > > On 3/10/19 3:24 PM, raell at web.de wrote: >> Dear, >> the Java TLS 1.3 implementation supports middlebox compatibility (e.g. >> sends a non-empty session id and a ChangeCipherSpec message). Out of >> interest: Is it possible to disable this compatibility mode? >> Regards, Ralph From valerie.peng at oracle.com Mon Mar 11 22:59:44 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 Mar 2019 15:59:44 -0700 Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the SunJSSE provider" In-Reply-To: <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> Message-ID: Thanks for the info, I'd prefer to completely remove the SunRsaSign entries from SunJSSE provider as well. I will update the webrev and file a CSR then. Thanks, Valerie On 3/7/2019 7:30 PM, Xuelei Fan wrote: > On 3/7/2019 6:15 PM, Valerie Peng wrote: >> Do you mean removing the part about SunRsaSignEntries completely? Or >> only remove the MD2/MD5withRSA signature algorithms? >> > I meant to remove the SunRsaSignEntries completely from the SunJSSE > provider. > >> Do you know the history of including them in the first place? Since >> SunRsaSign provider has been in early JDK releases, I wonder why >> SunJSSE provider duplicated these RSA algorithms in the first place? > The JSSE provider was originally provided as an standalone library, > and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the > package became part of JDK, and start to using the javax.net.ssl > package and the standard JCE providers.? However, for compatibility, > the old supported signature algorithms are still linked in the SunJSSE > provider. > > In the JDK 9, a noted was added in the SunJSSE provider documentation: > ?? The SunJSSE provider is for backwards compatibility with > ?? older releases, and should no longer be used for Signature. > > The compatibility is mainly about coding with explicitly SunJSSE > provider name.? For example, > ??? Signature.getInstance("SHA1withRSA", > ??????? "com.sun.net.ssl.internal.ssl.Provider"); > > The use may not be common in practice.? And the JDK JCE providers > support these algorithms, I was wondering the risk of removing them > from the SunJSSE provider may be low now. > > Thanks, > Xuelei > >> I can file a CSR, knowing the history/reason would help. >> >> Thanks, >> >> Valerie >> >> >> On 3/7/2019 5:45 PM, Xuelei Fan wrote: >>> Hi Valerie, >>> >>> As you are already there, I may suggest to remove the old RSA crypto >>> algorithms in the SunJSSE providers as well.? As may simplify the >>> code a little bit, though a CSR is needed for the SunJSSE behavior >>> change. >>> >>> Thanks, >>> Xuelei >>> >>> On 3/7/2019 4:56 PM, Valerie Peng wrote: >>>> Hi Brad, >>>> >>>> Do you have time to help review the changes for JDK-8220016? >>>> Current changes are to register the same list of RSA-related >>>> services as these prior to the fix for JDK-7092821. I am not sure >>>> what are the old RSA impls for pre-JDK1.4 implementations. >>>> Otherwise, I can remove them as well. Please let me know. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From valerie.peng at oracle.com Mon Mar 11 23:45:55 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 Mar 2019 16:45:55 -0700 Subject: [13] RFR JDK-8220258 "fix headings in java.smartcardio" Message-ID: Can someone help reviewing this? Just a javadoc one-line fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8220258 Webrev: http://cr.openjdk.java.net/~valeriep/8220258/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Mon Mar 11 23:56:24 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 11 Mar 2019 16:56:24 -0700 Subject: [13] RFR JDK-8220258 "fix headings in java.smartcardio" In-Reply-To: References: Message-ID: <18B01115-984B-4C42-ACA9-39E4E88B5D40@oracle.com> Looks good > On Mar 11, 2019, at 4:45 PM, Valerie Peng wrote: > > Can someone help reviewing this? Just a javadoc one-line fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220258 > > Webrev: http://cr.openjdk.java.net/~valeriep/8220258/webrev.00/ > > Thanks, > > Valerie > From sgehwolf at redhat.com Tue Mar 12 10:54:41 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Mar 2019 11:54:41 +0100 Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy In-Reply-To: References: Message-ID: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com> Adding security-dev as reviews should happen on the corresponding area lists. Even for 8. On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8175120 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/ This looks OK to me. It removes the same tests as was done for JDK 9. I've verified that KdcPolicy.java passes after your changes. Not a Reviewer, though. Thanks, Severin > Original review: > https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html > > This is not a clean backport because the tests in 8u differ slightly > from those in OpenJDK 10: > > 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly". > That same change (adding a property to the @run line) also needs to be > applied to the new KdcPolicy.java test for it to succeed. > > 2. 10u contains "JDK-8006690: sun/security/krb5/auto/BadKdc* tests fails > intermittently" which I assume is obsoleted by the more reliable > KdcPolicy.java test > > Strangely enough, this & JDK-8164656 were already approved last July, > but never pushed [0]. I can't see how this was a straightforward > backport then though either. > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007667.html From sean.mullan at oracle.com Tue Mar 12 13:05:12 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Mar 2019 09:05:12 -0400 Subject: CSR Review Request JDK-816826, Use server cipher suites preference by default In-Reply-To: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com> References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com> Message-ID: <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com> Looks good, but a couple of comments: In the Solution section, it says: "Applications can change the behavior with the existing SSLParameters.setUseCipherSuitesOrder?() method." I think you should be more clear that this means applications can change the order of the server's preferred cipher suites. There will be no way to go back to the previous behavior where the client's order is respected. Same comment in the proposed Release Note, although I don't think this section needs to be in the CSR, does it? --Sean On 2/25/19 12:36 PM, Xuelei Fan wrote: > Hi, > > Could I have the following CSR reviewed? > ?? https://bugs.openjdk.java.net/browse/JDK-8219657 > > It is proposing to use server cipher suite preference by default for TLS > connections in JDK. In the current implementation, the server honors the > client cipher suite preference by default. It is easier to maintain if > using the server cipher suite preference, and then the server can have > more control over the security parameters of TLS connections. > > I think the compatibility impact should be minimal.? If there is a known > risk for you, please let me know by the end of March 4, 2019. > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue Mar 12 17:12:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Mar 2019 10:12:37 -0700 Subject: CSR Review Request JDK-816826, Use server cipher suites preference by default In-Reply-To: <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com> References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com> <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com> Message-ID: On 3/12/2019 6:05 AM, Sean Mullan wrote: > Looks good, but a couple of comments: > > In the Solution section, it says: "Applications can change the behavior > with the existing SSLParameters.setUseCipherSuitesOrder?() method." > > I think you should be more clear that this means applications can change > the order of the server's preferred cipher suites. There will be no way > to go back to the previous behavior where the client's order is respected. > If a server call SSLParameters.setUseCipherSuitesOrder?(false), the client's order is respected. > Same comment in the proposed Release Note, although I don't think this > section needs to be in the CSR, does it? > It's not a required part of the CSR. I use this section to have the release note reviewed as well. I will remove this section as it is a kind of duplication of the release-note entry. Thanks, Xuelei > --Sean > > On 2/25/19 12:36 PM, Xuelei Fan wrote: >> Hi, >> >> Could I have the following CSR reviewed? >> ??? https://bugs.openjdk.java.net/browse/JDK-8219657 >> >> It is proposing to use server cipher suite preference by default for >> TLS connections in JDK. In the current implementation, the server >> honors the client cipher suite preference by default. It is easier to >> maintain if using the server cipher suite preference, and then the >> server can have more control over the security parameters of TLS >> connections. >> >> I think the compatibility impact should be minimal.? If there is a >> known risk for you, please let me know by the end of March 4, 2019. >> >> Thanks, >> Xuelei From sean.mullan at oracle.com Tue Mar 12 17:27:25 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Mar 2019 13:27:25 -0400 Subject: CSR Review Request JDK-816826, Use server cipher suites preference by default In-Reply-To: References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com> <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com> Message-ID: <1da7072b-71fd-1b21-d143-9b338593b4e1@oracle.com> On 3/12/19 1:12 PM, Xuelei Fan wrote: > On 3/12/2019 6:05 AM, Sean Mullan wrote: >> Looks good, but a couple of comments: >> >> In the Solution section, it says: "Applications can change the >> behavior with the existing SSLParameters.setUseCipherSuitesOrder?() >> method." >> >> I think you should be more clear that this means applications can >> change the order of the server's preferred cipher suites. There will >> be no way to go back to the previous behavior where the client's order >> is respected. >> > If a server call SSLParameters.setUseCipherSuitesOrder?(false),? the > client's order is respected. Oh, ok, I retract my comment then. When I read this, I had misinterpreted this to be the method that you use to set the enabled suites. --Sean > >> Same comment in the proposed Release Note, although I don't think this >> section needs to be in the CSR, does it? >> > It's not a required part of the CSR.? I use this section to have the > release note reviewed as well.? I will remove this section as it is a > kind of duplication of the release-note entry. > > Thanks, > Xuelei > >> --Sean >> >> On 2/25/19 12:36 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I have the following CSR reviewed? >>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657 >>> >>> It is proposing to use server cipher suite preference by default for >>> TLS connections in JDK. In the current implementation, the server >>> honors the client cipher suite preference by default. It is easier to >>> maintain if using the server cipher suite preference, and then the >>> server can have more control over the security parameters of TLS >>> connections. >>> >>> I think the compatibility impact should be minimal.? If there is a >>> known risk for you, please let me know by the end of March 4, 2019. >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Tue Mar 12 18:14:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Mar 2019 11:14:37 -0700 Subject: RFR [13] JDK-8160247 : Mark deprecated javax.security.cert APIs with forRemoval=true Message-ID: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/ The javax.security.cert API has been deprecated. The classes in this package should no longer be used. In the changeset, the "forRemoval=true" was added to the Deprecated annotation of the javax.security.cert classes. For more details, please refer to CSR: https://bugs.openjdk.java.net/browse/JDK-8219472 Thanks, Xuelei From sean.mullan at oracle.com Tue Mar 12 18:22:50 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Mar 2019 14:22:50 -0400 Subject: RFR 8220256: fix headings in java.security.sasl In-Reply-To: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com> References: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com> Message-ID: <710de6fa-7696-8639-1695-3f3f6b240d72@oracle.com> Looks fine to me. --Sean On 3/11/19 6:31 AM, Weijun Wang wrote: > Hi Jon, > > Please take a look at the patch below. > > *diff --git > a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java > b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java* > *--- > a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java* > *+++ > b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java* > @@ -30,7 +30,7 @@ > ? * It is used by developers to add authentication support for > ? * connection-based protocols that use SASL. > ? * > - *

SASL Overview

> + *

SASL Overview

> ? * > ? * Simple Authentication and Security Layer (SASL) specifies a > ? * challenge-response protocol in which data is exchanged between the > @@ -74,7 +74,7 @@ > ? * allow negotiation of the security layer.? For External, the > ? * security layer is determined by the external protocol. > ? * > - *

Usage

> + *

Usage

> ? * > ? * Users of this API are typically developers who produce > ? * client library implementations for connection-based protocols, > > In case you want to look at the whole file, its current content is at > https://hg.openjdk.java.net/jdk/jdk/file/9a1dd1203a4f/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java. > > Thanks, > Max > From jamil.j.nimeh at oracle.com Tue Mar 12 18:33:14 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 12 Mar 2019 11:33:14 -0700 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. Message-ID: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> Hello all, Please review the CSR for the behavioral change to SunJCE's PBKDF2 implementaion.? This change will make the underlying Mac also come from SunJCE.? This change only affects the SunJCE implementation of PBKDF2, not any other implementation from any different provider. https://bugs.openjdk.java.net/browse/JDK-8220531 Thanks, --Jamil From mbalao at redhat.com Tue Mar 12 19:56:36 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 12 Mar 2019 16:56:36 -0300 Subject: SunJSSE and SunPKCS11 (NSS + FIPS) Message-ID: Hi, There is an issue that I'd like to bring here for discussion. I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between a client and server using SunPKCS11 crypto provider -with NSS software token configured in FIPS mode-, after JDK-8217835 change [1]. My 1st preference crypto provider is SunPKCS11 and my 2nd is SUN. All my keys for this communication will then be non-extractable P11Key keys. This means that we cannot convert them to work with any other service from any other provider. Otherwise, FIPS constraints would be violated. SignatureScheme considers multiple signing algorithms as available when there is at least one crypto provider that supports them. As an example, "RSASSA-PSS" is listed as available because I have "SUN" crypto provider enabled. SunPKCS11 does not currently support "RSASSA-PSS" algorithm. Even though it would be pretty easy to support it (CKM_RSA_PKCS_PSS mechanism), we may still be in a case in which the underlying SunPKCS11 library does not implement it or where there is not a mechanism in the PKCS#11 latest standard. Now, SignatureScheme.getSignature gets called with a P11Key [2]. Inside this method, Signature.getInstance(algorithm) will return a SUN service provider that cannot work with these P11Key keys. Disabling SUN provider is not an option because we need support for X.509 certificates. My understanding is that the previous experimental FIPS mode in SunJSSE provided consistency through a unique underlying crypto provider, used across the engine. I believe we still need to support the SunPKCS11 - FIPS case, as it's pretty common in enterprises. In addition, I'm working towards re-introducing TestTLS12 to JDK. This test does not only reproduce this scenario, but has helped to find bugs such as JDK-8220513 [3]. Thoughts? Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8217835 [2] - http://hg.openjdk.java.net/jdk/jdk/file/daec95ed6795/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l469 [3] - https://bugs.openjdk.java.net/browse/JDK-8220513 From mbalao at redhat.com Tue Mar 12 22:34:24 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 12 Mar 2019 19:34:24 -0300 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider Message-ID: Hi, I'd like to propose a fix for JDK-8220513 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.00/ Testing: * No regressions found in sun/security/pkcs11 * This bug was exposed by TestTLS12 test, in jdk11u [2]. I'm working in re-introducing this test to JDK (after JDK-8217835 deleted it). An issue [4] has to be worked out first though. I'll followup on this. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8220513 [2] - http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d17a1764a0f3/test/jdk/sun/security/pkcs11/fips/TestTLS12.java [3] - https://bugs.openjdk.java.net/browse/JDK-8217835 [4] - https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html From valerie.peng at oracle.com Wed Mar 13 02:57:50 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 12 Mar 2019 19:57:50 -0700 Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the SunJSSE provider" In-Reply-To: References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> Message-ID: Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549 Webrev updated in place for this new approach: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ I changed the synopsis to clarify that we are now removing these duplicated RSA support. Thanks, Valerie On 3/11/2019 3:59 PM, Valerie Peng wrote: > Thanks for the info, I'd prefer to completely remove the SunRsaSign > entries from SunJSSE provider as well. > > I will update the webrev and file a CSR then. > > Thanks, > > Valerie > > > On 3/7/2019 7:30 PM, Xuelei Fan wrote: >> On 3/7/2019 6:15 PM, Valerie Peng wrote: >>> Do you mean removing the part about SunRsaSignEntries completely? Or >>> only remove the MD2/MD5withRSA signature algorithms? >>> >> I meant to remove the SunRsaSignEntries completely from the SunJSSE >> provider. >> >>> Do you know the history of including them in the first place? Since >>> SunRsaSign provider has been in early JDK releases, I wonder why >>> SunJSSE provider duplicated these RSA algorithms in the first place? >> The JSSE provider was originally provided as an standalone library, >> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the >> package became part of JDK, and start to using the javax.net.ssl >> package and the standard JCE providers. However, for compatibility, >> the old supported signature algorithms are still linked in the >> SunJSSE provider. >> >> In the JDK 9, a noted was added in the SunJSSE provider documentation: >> ?? The SunJSSE provider is for backwards compatibility with >> ?? older releases, and should no longer be used for Signature. >> >> The compatibility is mainly about coding with explicitly SunJSSE >> provider name.? For example, >> ??? Signature.getInstance("SHA1withRSA", >> ??????? "com.sun.net.ssl.internal.ssl.Provider"); >> >> The use may not be common in practice.? And the JDK JCE providers >> support these algorithms, I was wondering the risk of removing them >> from the SunJSSE provider may be low now. >> >> Thanks, >> Xuelei >> >>> I can file a CSR, knowing the history/reason would help. >>> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 3/7/2019 5:45 PM, Xuelei Fan wrote: >>>> Hi Valerie, >>>> >>>> As you are already there, I may suggest to remove the old RSA >>>> crypto algorithms in the SunJSSE providers as well.? As may >>>> simplify the code a little bit, though a CSR is needed for the >>>> SunJSSE behavior change. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 3/7/2019 4:56 PM, Valerie Peng wrote: >>>>> Hi Brad, >>>>> >>>>> Do you have time to help review the changes for JDK-8220016? >>>>> Current changes are to register the same list of RSA-related >>>>> services as these prior to the fix for JDK-7092821. I am not sure >>>>> what are the old RSA impls for pre-JDK1.4 implementations. >>>>> Otherwise, I can remove them as well. Please let me know. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From weijun.wang at oracle.com Wed Mar 13 03:02:01 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 13 Mar 2019 11:02:01 +0800 Subject: RFR [13] JDK-8160247 : Mark deprecated javax.security.cert APIs with forRemoval=true In-Reply-To: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com> References: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com> Message-ID: The change looks fine. --Max > On Mar 13, 2019, at 2:14 AM, Xuelei Fan wrote: > > Hi, > > Could I get the following update reviewed? > http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/ > > The javax.security.cert API has been deprecated. The classes in this package should no longer be used. In the changeset, the "forRemoval=true" was added to the Deprecated annotation of the javax.security.cert classes. > > For more details, please refer to CSR: > https://bugs.openjdk.java.net/browse/JDK-8219472 > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Mar 13 03:18:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Mar 2019 20:18:11 -0700 Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the SunJSSE provider" In-Reply-To: References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> Message-ID: <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com> On 3/12/2019 7:57 PM, Valerie Peng wrote: > Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549 > I added myself as reviewer. > Webrev updated in place for this new approach: > http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ > It looks fine to me. Xuelei > I changed the synopsis to clarify that we are now removing these > duplicated RSA support. > > Thanks, > > Valerie > > > On 3/11/2019 3:59 PM, Valerie Peng wrote: >> Thanks for the info, I'd prefer to completely remove the SunRsaSign >> entries from SunJSSE provider as well. >> >> I will update the webrev and file a CSR then. >> >> Thanks, >> >> Valerie >> >> >> On 3/7/2019 7:30 PM, Xuelei Fan wrote: >>> On 3/7/2019 6:15 PM, Valerie Peng wrote: >>>> Do you mean removing the part about SunRsaSignEntries completely? Or >>>> only remove the MD2/MD5withRSA signature algorithms? >>>> >>> I meant to remove the SunRsaSignEntries completely from the SunJSSE >>> provider. >>> >>>> Do you know the history of including them in the first place? Since >>>> SunRsaSign provider has been in early JDK releases, I wonder why >>>> SunJSSE provider duplicated these RSA algorithms in the first place? >>> The JSSE provider was originally provided as an standalone library, >>> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the >>> package became part of JDK, and start to using the javax.net.ssl >>> package and the standard JCE providers. However, for compatibility, >>> the old supported signature algorithms are still linked in the >>> SunJSSE provider. >>> >>> In the JDK 9, a noted was added in the SunJSSE provider documentation: >>> ?? The SunJSSE provider is for backwards compatibility with >>> ?? older releases, and should no longer be used for Signature. >>> >>> The compatibility is mainly about coding with explicitly SunJSSE >>> provider name.? For example, >>> ??? Signature.getInstance("SHA1withRSA", >>> ??????? "com.sun.net.ssl.internal.ssl.Provider"); >>> >>> The use may not be common in practice.? And the JDK JCE providers >>> support these algorithms, I was wondering the risk of removing them >>> from the SunJSSE provider may be low now. >>> >>> Thanks, >>> Xuelei >>> >>>> I can file a CSR, knowing the history/reason would help. >>>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> >>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote: >>>>> Hi Valerie, >>>>> >>>>> As you are already there, I may suggest to remove the old RSA >>>>> crypto algorithms in the SunJSSE providers as well.? As may >>>>> simplify the code a little bit, though a CSR is needed for the >>>>> SunJSSE behavior change. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote: >>>>>> Hi Brad, >>>>>> >>>>>> Do you have time to help review the changes for JDK-8220016? >>>>>> Current changes are to register the same list of RSA-related >>>>>> services as these prior to the fix for JDK-7092821. I am not sure >>>>>> what are the old RSA impls for pre-JDK1.4 implementations. >>>>>> Otherwise, I can remove them as well. Please let me know. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie From norman.maurer at googlemail.com Wed Mar 13 06:31:06 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 13 Mar 2019 07:31:06 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: Message-ID: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Is there anything else I can do to have anyone look into this? I just want to make sure this does not fall through before the final JDK 12 release is done. Bye Norman > On 4. Mar 2019, at 21:15, Norman Maurer wrote: > > Any comments here ? > > Bye > Norman > > >> On 28. Feb 2019, at 09:24, Norman Maurer > wrote: >> >> Hi all, >> >> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho. >> >> I pushed a reproducer for this here: >> >> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug >> >> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions. >> >> Here is the Java version I used to reproduce: >> >> # java -version >> openjdk version "12" 2019-03-19 >> OpenJDK Runtime Environment (build 12+33) >> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) >> >> >> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version: >> >> #java -version >> openjdk version "12-ea" 2019-03-19 >> OpenJDK Runtime Environment (build 12-ea+27) >> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) >> >> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/ >> >> Thanks >> Norman >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Mar 13 07:48:00 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Mar 2019 07:48:00 +0000 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Message-ID: On 13/03/2019 06:31, Norman Maurer wrote: > Is there anything else I can do to have anyone look into this? > > I just want to make sure this does not fall through before the final > JDK 12 release is done. > Can you attach or inline the test that demonstrates the issue you are seeing? (we can't use reproducers that are hosted on github). -Alan. From norman.maurer at googlemail.com Wed Mar 13 07:51:56 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 13 Mar 2019 08:51:56 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Message-ID: As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces? Bye Norman > On 13. Mar 2019, at 08:48, Alan Bateman wrote: > > On 13/03/2019 06:31, Norman Maurer wrote: >> Is there anything else I can do to have anyone look into this? >> >> I just want to make sure this does not fall through before the final JDK 12 release is done. >> > Can you attach or inline the test that demonstrates the issue you are seeing? (we can't use reproducers that are hosted on github). > > -Alan. From sha.jiang at oracle.com Wed Mar 13 08:58:25 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 13 Mar 2019 16:58:25 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output Message-ID: Hi, This fix just makes sure that specified timezone is not null, and the jar verifying and date formatting use the same different timezone. Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 Best regards, John Jiang From sha.jiang at oracle.com Wed Mar 13 09:01:46 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 13 Mar 2019 17:01:46 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: References: Message-ID: <0c6a78e2-e1a7-fc57-4a29-104a683cae30@oracle.com> On 2019/3/13 16:58, sha.jiang at oracle.com wrote: > Hi, > This fix just makes sure that specified timezone is not null, and the > jar verifying and date formatting use the same different timezone. ... use the same (not different) timezone. John > > Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 > > Best regards, > John Jiang > From Alan.Bateman at oracle.com Wed Mar 13 09:04:18 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Mar 2019 09:04:18 +0000 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Message-ID: <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com> On 13/03/2019 07:51, Norman Maurer wrote: > As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces? If it's needed to demonstrate the issue then include but if it's just setup then it would be better to provide the instructions. I don't know file types are stripped by the mail servers but if you cc me then I can create an issue in JBS. -Alan From sean.mullan at oracle.com Wed Mar 13 12:31:36 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Mar 2019 08:31:36 -0400 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Message-ID: My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418 is the cause. Xuelei, would you have time to look at this? Thanks, Sean On 3/13/19 2:31 AM, Norman Maurer wrote: > Is there anything else I can do to have anyone look into this? > > I just want to make sure this does not fall through before the final JDK > 12 release is done. > > Bye > Norman > > >> On 4. Mar 2019, at 21:15, Norman Maurer > > wrote: >> >> Any comments here ? >> >> Bye >> Norman >> >> >>> On 28. Feb 2019, at 09:24, Norman Maurer >>> > >>> wrote: >>> >>> Hi all, >>> >>> I think I found a possible regression / bug in the latest JDK12 >>> release when trying to upgrade the Netty CI server to test with the >>> latest JDK12 release. The problem is that SSLEngine.wrap(?) returns >>> NOT_HANDSHAKING even when there are bytes left that should be >>> consumed (the alert itself). My understanding is that it should only >>> return ?NOT_HANDSHAKING? once we also consumed the alert. Please >>> correct me if I wrong tho. >>> >>> I pushed a reproducer for this here: >>> >>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug >>> >>> When running this on the latest JDK12 release (and later JDK >>> versions) it will fail with an AssertionError, while everything works >>> as expected when using earlier Java versions. >>> >>> Here is the Java version I used to reproduce: >>> >>> # java -version >>> openjdk version "12" 2019-03-19 >>> OpenJDK Runtime Environment (build 12+33) >>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) >>> >>> >>> It seems like this was not always the case for Java12 tho, as I can >>> not reproduce it with this version: >>> >>> #java -version >>> openjdk version "12-ea" 2019-03-19 >>> OpenJDK Runtime Environment (build 12-ea+27) >>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) >>> >>> I don't have all the ?in between? releases on my machine atm so I can >>> not tell exactly on which release this ?broke? :/ >>> >>> Thanks >>> Norman >>> >>> >>> >> > From norman.maurer at googlemail.com Wed Mar 13 12:54:20 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 13 Mar 2019 13:54:20 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> Message-ID: <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com> Wasn?t it possible at some point to browse the bugs without a login ? When I try to look at the issue it asks me for a login :/ Bye Norman > On 13. Mar 2019, at 13:31, Sean Mullan wrote: > > My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418 is the cause. > > Xuelei, would you have time to look at this? > > Thanks, > Sean > > On 3/13/19 2:31 AM, Norman Maurer wrote: >> Is there anything else I can do to have anyone look into this? >> I just want to make sure this does not fall through before the final JDK 12 release is done. >> Bye >> Norman >>> On 4. Mar 2019, at 21:15, Norman Maurer > wrote: >>> >>> Any comments here ? >>> >>> Bye >>> Norman >>> >>> >>>> On 28. Feb 2019, at 09:24, Norman Maurer > wrote: >>>> >>>> Hi all, >>>> >>>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho. >>>> >>>> I pushed a reproducer for this here: >>>> >>>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug >>>> >>>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions. >>>> >>>> Here is the Java version I used to reproduce: >>>> >>>> # java -version >>>> openjdk version "12" 2019-03-19 >>>> OpenJDK Runtime Environment (build 12+33) >>>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) >>>> >>>> >>>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version: >>>> >>>> #java -version >>>> openjdk version "12-ea" 2019-03-19 >>>> OpenJDK Runtime Environment (build 12-ea+27) >>>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) >>>> >>>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/ >>>> >>>> Thanks >>>> Norman >>>> >>>> >>>> >>> From norman.maurer at googlemail.com Wed Mar 13 12:56:50 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 13 Mar 2019 13:56:50 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com> References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com> Message-ID: Here is the reproducer (just replace ?test.p12? with some valid file that contains the keymaterial), which does not throw on JDK11 but throws on JDK12: import javax.net.ssl.KeyManagerFactory; import javax.net.ssl.SSLContext; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.TrustManager; import javax.net.ssl.X509TrustManager; import java.nio.ByteBuffer; import java.security.KeyStore; import java.security.cert.X509Certificate; public class JDKSSLUnwrapReproducer { public static void main(String[] args) throws Exception { KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType()); keyStore.load(JDKSSLUnwrapReproducer.class.getResourceAsStream("test.p12"), "test".toCharArray()); KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); kmf.init(keyStore, "test".toCharArray()); SSLContext serverCtx = SSLContext.getInstance("TLS"); serverCtx.init(kmf.getKeyManagers(), null, null); SSLEngine server = serverCtx.createSSLEngine(); server.setUseClientMode(false); server.setEnabledProtocols(new String[] { "TLSv1.2" }); SSLContext clientCtx = SSLContext.getInstance("TLS"); clientCtx.init(null, new TrustManager[] { new X509TrustManager() { @Override public void checkClientTrusted(X509Certificate[] x509Certificates, String s) { // NOOP } @Override public void checkServerTrusted(X509Certificate[] x509Certificates, String s) { // NOOP } @Override public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; } } }, null); SSLEngine client = clientCtx.createSSLEngine(); client.setUseClientMode(true); client.setEnabledProtocols(new String[] { "TLSv1.2" }); ByteBuffer plainClientOut = ByteBuffer.allocate(client.getSession().getApplicationBufferSize()); ByteBuffer plainServerOut = ByteBuffer.allocate(server.getSession().getApplicationBufferSize()); ByteBuffer encryptedClientToServer = ByteBuffer.allocate(client.getSession().getPacketBufferSize()); ByteBuffer encryptedServerToClient = ByteBuffer.allocate(server.getSession().getPacketBufferSize()); ByteBuffer empty = ByteBuffer.allocate(0); handshake(client, server); // This will produce a close_notify client.closeOutbound(); // Something still pending in the outbound buffer. assertFalse(client.isOutboundDone()); assertFalse(client.isInboundDone()); // Now wrap and so drain the outbound buffer. SSLEngineResult result = client.wrap(empty, encryptedClientToServer); encryptedClientToServer.flip(); assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus()); // Need an UNWRAP to read the response of the close_notify // // This is NOT_HANDSHAKING for JDK 12+ !!!! assertEquals(SSLEngineResult.HandshakeStatus.NEED_UNWRAP, result.getHandshakeStatus()); int produced = result.bytesProduced(); int consumed = result.bytesConsumed(); int closeNotifyLen = produced; assertTrue(produced > 0); assertEquals(0, consumed); assertEquals(produced, encryptedClientToServer.remaining()); // Outbound buffer should be drained now. assertTrue(client.isOutboundDone()); assertFalse(client.isInboundDone()); assertFalse(server.isOutboundDone()); assertFalse(server.isInboundDone()); result = server.unwrap(encryptedClientToServer, plainServerOut); plainServerOut.flip(); assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus()); // Need a WRAP to respond to the close_notify assertEquals(SSLEngineResult.HandshakeStatus.NEED_WRAP, result.getHandshakeStatus()); produced = result.bytesProduced(); consumed = result.bytesConsumed(); assertEquals(closeNotifyLen, consumed); assertEquals(0, produced); // Should have consumed the complete close_notify assertEquals(0, encryptedClientToServer.remaining()); assertEquals(0, plainServerOut.remaining()); assertFalse(server.isOutboundDone()); assertTrue(server.isInboundDone()); result = server.wrap(empty, encryptedServerToClient); encryptedServerToClient.flip(); assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus()); // UNWRAP/WRAP are not expected after this point assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus()); produced = result.bytesProduced(); consumed = result.bytesConsumed(); assertEquals(closeNotifyLen, produced); assertEquals(0, consumed); assertEquals(produced, encryptedServerToClient.remaining()); assertTrue(server.isOutboundDone()); assertTrue(server.isInboundDone()); result = client.unwrap(encryptedServerToClient, plainClientOut); plainClientOut.flip(); assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus()); // UNWRAP/WRAP are not expected after this point assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus()); produced = result.bytesProduced(); consumed = result.bytesConsumed(); assertEquals(closeNotifyLen, consumed); assertEquals(0, produced); assertEquals(0, encryptedServerToClient.remaining()); assertTrue(client.isOutboundDone()); assertTrue(client.isInboundDone()); // Ensure that calling wrap or unwrap again will not produce a SSLException encryptedServerToClient.clear(); plainServerOut.clear(); result = server.wrap(plainServerOut, encryptedServerToClient); assertEngineRemainsClosed(result); encryptedClientToServer.clear(); plainServerOut.clear(); result = server.unwrap(encryptedClientToServer, plainServerOut); assertEngineRemainsClosed(result); encryptedClientToServer.clear(); plainClientOut.clear(); result = client.wrap(plainClientOut, encryptedClientToServer); assertEngineRemainsClosed(result); encryptedServerToClient.clear(); plainClientOut.clear(); result = client.unwrap(encryptedServerToClient, plainClientOut); assertEngineRemainsClosed(result); } private static void assertEngineRemainsClosed(SSLEngineResult result) { assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus()); assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus()); assertEquals(0, result.bytesConsumed()); assertEquals(0, result.bytesProduced()); } private static void handshake(SSLEngine clientEngine, SSLEngine serverEngine) throws SSLException { ByteBuffer cTOs = ByteBuffer.allocate(clientEngine.getSession().getPacketBufferSize()); ByteBuffer sTOc = ByteBuffer.allocate(serverEngine.getSession().getPacketBufferSize()); ByteBuffer serverAppReadBuffer = ByteBuffer.allocate( serverEngine.getSession().getApplicationBufferSize()); ByteBuffer clientAppReadBuffer = ByteBuffer.allocate( clientEngine.getSession().getApplicationBufferSize()); clientEngine.beginHandshake(); serverEngine.beginHandshake(); ByteBuffer empty = ByteBuffer.allocate(0); SSLEngineResult clientResult; SSLEngineResult serverResult; boolean clientHandshakeFinished = false; boolean serverHandshakeFinished = false; do { if (!clientHandshakeFinished) { clientResult = clientEngine.wrap(empty, cTOs); runDelegatedTasks(clientResult, clientEngine); if (isHandshakeFinished(clientResult)) { clientHandshakeFinished = true; } } if (!serverHandshakeFinished) { serverResult = serverEngine.wrap(empty, sTOc); runDelegatedTasks(serverResult, serverEngine); if (isHandshakeFinished(serverResult)) { serverHandshakeFinished = true; } } cTOs.flip(); sTOc.flip(); if (!clientHandshakeFinished) { clientResult = clientEngine.unwrap(sTOc, clientAppReadBuffer); runDelegatedTasks(clientResult, clientEngine); if (isHandshakeFinished(clientResult)) { clientHandshakeFinished = true; } } if (!serverHandshakeFinished) { serverResult = serverEngine.unwrap(cTOs, serverAppReadBuffer); runDelegatedTasks(serverResult, serverEngine); if (isHandshakeFinished(serverResult)) { serverHandshakeFinished = true; } } sTOc.compact(); cTOs.compact(); } while (!clientHandshakeFinished || !serverHandshakeFinished); } private static boolean isHandshakeFinished(SSLEngineResult result) { return result.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.FINISHED; } private static void runDelegatedTasks(SSLEngineResult result, SSLEngine engine) { if (result.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.NEED_TASK) { for (;;) { Runnable task = engine.getDelegatedTask(); if (task == null) { break; } task.run(); } } } private static void assertTrue(boolean result) { if (!result) { throw new AssertionError(); } } private static void assertFalse(boolean result) { if (result) { throw new AssertionError(); } } private static void assertEquals(Object o1, Object o2) { if (!o1.equals(o2)) { throw new AssertionError(o1 + " != " + o2); } } } > On 13. Mar 2019, at 10:04, Alan Bateman wrote: > > On 13/03/2019 07:51, Norman Maurer wrote: >> As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces? > If it's needed to demonstrate the issue then include but if it's just setup then it would be better to provide the instructions. I don't know file types are stripped by the mail servers but if you cc me then I can create an issue in JBS. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Mar 13 13:05:12 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 13:05:12 +0000 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com> References: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com> <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com> Message-ID: <4771bd5c-b1af-6658-dadf-9ed1a4b4ef12@oracle.com> Hi Norman, On 13/03/2019 12:54, Norman Maurer wrote: > Wasn?t it possible at some point to browse the bugs without a login ? When I try to look at the issue it asks me for a login :/ Sorry about that. You should be able to find all the information about the issue in the public review thread in the security-dev archive: http://mail.openjdk.java.net/pipermail/security-dev/2018-December/019100.html http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019142.html Hope this help, -- daniel From adam.petcher at oracle.com Wed Mar 13 13:44:05 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 13 Mar 2019 09:44:05 -0400 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> Message-ID: On 3/12/2019 2:33 PM, Jamil Nimeh wrote: > Hello all, > > Please review the CSR for the behavioral change to SunJCE's PBKDF2 > implementaion.? This change will make the underlying Mac also come > from SunJCE.? This change only affects the SunJCE implementation of > PBKDF2, not any other implementation from any different provider. > > https://bugs.openjdk.java.net/browse/JDK-8220531 Looks pretty straightforward. I just have a couple of questions related to compatibility: 1) Is it possible that the requested Mac would not be available in SunJCE, but it would be available in some other provider? If so, then PBKDF2 would fail after this change. Should we fall back to the current behavior if we get a NoSuchAlgorithmException from SunJCE? 2) Do you (or anyone else on the mailing list) have any reason to be concerned that the Mac in SunJCE won't work as well in some cases where it could also come from another (higher-priority) provider? If so, then we should think about adding a system property or other toggle for this behavior. This is a question---not a suggestion. I don't think we should include this toggle unless we have some motivation to do so. Also, if there is no change to any spec, then I think that means the scope is "Implementation" rather than "SE". From xuelei.fan at oracle.com Wed Mar 13 14:05:51 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Mar 2019 07:05:51 -0700 Subject: SunJSSE and SunPKCS11 (NSS + FIPS) In-Reply-To: References: Message-ID: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com> To use FIPS mode JCE provider, an application could: 1. implement the required algorithm in the FIPS mode JCE provider. 2. don't those algorithms that outside the scope of the FIPS mode JCE provider (restrict them). Xuelei On 3/12/2019 12:56 PM, Martin Balao wrote: > Hi, > > There is an issue that I'd like to bring here for discussion. > > I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between > a client and server using SunPKCS11 crypto provider -with NSS software > token configured in FIPS mode-, after JDK-8217835 change [1]. > > My 1st preference crypto provider is SunPKCS11 and my 2nd is SUN. > > All my keys for this communication will then be non-extractable P11Key > keys. This means that we cannot convert them to work with any other > service from any other provider. Otherwise, FIPS constraints would be > violated. > > SignatureScheme considers multiple signing algorithms as available when > there is at least one crypto provider that supports them. As an example, > "RSASSA-PSS" is listed as available because I have "SUN" crypto provider > enabled. SunPKCS11 does not currently support "RSASSA-PSS" algorithm. > Even though it would be pretty easy to support it (CKM_RSA_PKCS_PSS > mechanism), we may still be in a case in which the underlying SunPKCS11 > library does not implement it or where there is not a mechanism in the > PKCS#11 latest standard. > > Now, SignatureScheme.getSignature gets called with a P11Key [2]. Inside > this method, Signature.getInstance(algorithm) will return a SUN service > provider that cannot work with these P11Key keys. > > Disabling SUN provider is not an option because we need support for > X.509 certificates. > > My understanding is that the previous experimental FIPS mode in SunJSSE > provided consistency through a unique underlying crypto provider, used > across the engine. I believe we still need to support the SunPKCS11 - > FIPS case, as it's pretty common in enterprises. > > In addition, I'm working towards re-introducing TestTLS12 to JDK. This > test does not only reproduce this scenario, but has helped to find bugs > such as JDK-8220513 [3]. > > Thoughts? > > Kind regards, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8217835 > [2] - > http://hg.openjdk.java.net/jdk/jdk/file/daec95ed6795/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l469 > [3] - https://bugs.openjdk.java.net/browse/JDK-8220513 > From xuelei.fan at oracle.com Wed Mar 13 14:11:29 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Mar 2019 07:11:29 -0700 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: Message-ID: Hi Norman, What's the problem in the application? It is possible that status is NOT_HANDSHAKING even there are bytes left that should be consumed, for example alert or application data. NOT_HANDSHAKING means that the handshaking is not in progress. Thanks, Xuelei On 2/28/2019 12:24 AM, Norman Maurer wrote: > Hi all, > > I think I found a possible regression / bug in the latest JDK12 release > when trying to upgrade the Netty CI server to test with the latest JDK12 > release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING > even when there are bytes left that should be consumed (the alert > itself). My understanding is that it should only return > ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if > I wrong tho. > > I pushed a reproducer for this here: > > https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug > > When running this on the latest JDK12 release (and later JDK versions) > it will fail with an AssertionError, while everything works as expected > when using earlier Java versions. > > Here is the Java version I used to reproduce: > > # java -version > openjdk version "12" 2019-03-19 > OpenJDK Runtime Environment (build 12+33) > OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) > > > It seems like this was not always the case for Java12 tho, as I can not > reproduce it with this version: > > #java -version > openjdk version "12-ea" 2019-03-19 > OpenJDK Runtime Environment (build 12-ea+27) > OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) > > I don't have all the ?in between? releases on my machine atm so I can > not tell exactly on which release this ?broke? :/ > > Thanks > Norman > > > From norman.maurer at googlemail.com Wed Mar 13 14:17:03 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 13 Mar 2019 15:17:03 +0100 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: References: Message-ID: <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com> I assumed that it should return NEED_UNWRAP if there is something left that needs to be consumed (that?s also what happened in JDK11 and before). How should we know then that there is an alert to consume ? Bye Norman > Am 13.03.2019 um 15:11 schrieb Xuelei Fan : > > Hi Norman, > > What's the problem in the application? It is possible that status is NOT_HANDSHAKING even there are bytes left that should be consumed, for example alert or application data. NOT_HANDSHAKING means that the handshaking is not in progress. > > Thanks, > Xuelei > >> On 2/28/2019 12:24 AM, Norman Maurer wrote: >> Hi all, >> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho. >> I pushed a reproducer for this here: >> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug >> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions. >> Here is the Java version I used to reproduce: >> # java -version >> openjdk version "12" 2019-03-19 >> OpenJDK Runtime Environment (build 12+33) >> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) >> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version: >> #java -version >> openjdk version "12-ea" 2019-03-19 >> OpenJDK Runtime Environment (build 12-ea+27) >> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) >> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/ >> Thanks >> Norman From xuelei.fan at oracle.com Wed Mar 13 14:39:15 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Mar 2019 07:39:15 -0700 Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression). In-Reply-To: <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com> References: <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com> Message-ID: <718db506-e75c-6454-1630-bd15a6dd6d2c@oracle.com> Once TLS handshaking completed, the status would be NOT_HANDSHAKING. It is unlikely to know the content type of the unconsumed data. When the data get consumed, the status may be adjusted accordingly. Xuelei On 3/13/2019 7:17 AM, Norman Maurer wrote: > I assumed that it should return NEED_UNWRAP if there is something left that needs to be consumed (that?s also what happened in JDK11 and before). > > How should we know then that there is an alert to consume ? > > Bye > Norman > >> Am 13.03.2019 um 15:11 schrieb Xuelei Fan : >> >> Hi Norman, >> >> What's the problem in the application? It is possible that status is NOT_HANDSHAKING even there are bytes left that should be consumed, for example alert or application data. NOT_HANDSHAKING means that the handshaking is not in progress. >> >> Thanks, >> Xuelei >> >>> On 2/28/2019 12:24 AM, Norman Maurer wrote: >>> Hi all, >>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho. >>> I pushed a reproducer for this here: >>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug >>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions. >>> Here is the Java version I used to reproduce: >>> # java -version >>> openjdk version "12" 2019-03-19 >>> OpenJDK Runtime Environment (build 12+33) >>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing) >>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version: >>> #java -version >>> openjdk version "12-ea" 2019-03-19 >>> OpenJDK Runtime Environment (build 12-ea+27) >>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing) >>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/ >>> Thanks >>> Norman From sean.mullan at oracle.com Wed Mar 13 15:00:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Mar 2019 11:00:47 -0400 Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the SunJSSE provider" In-Reply-To: <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com> References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com> <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com> <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com> Message-ID: There should also be a release note issue filed for this change. --Sean On 3/12/19 11:18 PM, Xuelei Fan wrote: > On 3/12/2019 7:57 PM, Valerie Peng wrote: >> Please review the CSR at: >> https://bugs.openjdk.java.net/browse/JDK-8220549 >> > I added myself as reviewer. > >> Webrev updated in place for this new approach: >> http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >> > It looks fine to me. > > Xuelei > >> I changed the synopsis to clarify that we are now removing these >> duplicated RSA support. >> >> Thanks, >> >> Valerie >> >> >> On 3/11/2019 3:59 PM, Valerie Peng wrote: >>> Thanks for the info, I'd prefer to completely remove the SunRsaSign >>> entries from SunJSSE provider as well. >>> >>> I will update the webrev and file a CSR then. >>> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 3/7/2019 7:30 PM, Xuelei Fan wrote: >>>> On 3/7/2019 6:15 PM, Valerie Peng wrote: >>>>> Do you mean removing the part about SunRsaSignEntries completely? >>>>> Or only remove the MD2/MD5withRSA signature algorithms? >>>>> >>>> I meant to remove the SunRsaSignEntries completely from the SunJSSE >>>> provider. >>>> >>>>> Do you know the history of including them in the first place? Since >>>>> SunRsaSign provider has been in early JDK releases, I wonder why >>>>> SunJSSE provider duplicated these RSA algorithms in the first place? >>>> The JSSE provider was originally provided as an standalone library, >>>> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, >>>> the package became part of JDK, and start to using the javax.net.ssl >>>> package and the standard JCE providers. However, for compatibility, >>>> the old supported signature algorithms are still linked in the >>>> SunJSSE provider. >>>> >>>> In the JDK 9, a noted was added in the SunJSSE provider documentation: >>>> ?? The SunJSSE provider is for backwards compatibility with >>>> ?? older releases, and should no longer be used for Signature. >>>> >>>> The compatibility is mainly about coding with explicitly SunJSSE >>>> provider name.? For example, >>>> ??? Signature.getInstance("SHA1withRSA", >>>> ??????? "com.sun.net.ssl.internal.ssl.Provider"); >>>> >>>> The use may not be common in practice.? And the JDK JCE providers >>>> support these algorithms, I was wondering the risk of removing them >>>> from the SunJSSE provider may be low now. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> I can file a CSR, knowing the history/reason would help. >>>>> >>>>> Thanks, >>>>> >>>>> Valerie >>>>> >>>>> >>>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote: >>>>>> Hi Valerie, >>>>>> >>>>>> As you are already there, I may suggest to remove the old RSA >>>>>> crypto algorithms in the SunJSSE providers as well.? As may >>>>>> simplify the code a little bit, though a CSR is needed for the >>>>>> SunJSSE behavior change. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote: >>>>>>> Hi Brad, >>>>>>> >>>>>>> Do you have time to help review the changes for JDK-8220016? >>>>>>> Current changes are to register the same list of RSA-related >>>>>>> services as these prior to the fix for JDK-7092821. I am not sure >>>>>>> what are the old RSA impls for pre-JDK1.4 implementations. >>>>>>> Otherwise, I can remove them as well. Please let me know. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie From jamil.j.nimeh at oracle.com Wed Mar 13 15:48:13 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 13 Mar 2019 08:48:13 -0700 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> Message-ID: <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com> Hi Adam, thanks for the feedback.? I have some comments below: On 3/13/2019 6:44 AM, Adam Petcher wrote: > On 3/12/2019 2:33 PM, Jamil Nimeh wrote: > >> Hello all, >> >> Please review the CSR for the behavioral change to SunJCE's PBKDF2 >> implementaion.? This change will make the underlying Mac also come >> from SunJCE.? This change only affects the SunJCE implementation of >> PBKDF2, not any other implementation from any different provider. >> >> https://bugs.openjdk.java.net/browse/JDK-8220531 > > Looks pretty straightforward. I just have a couple of questions > related to compatibility: > > 1) Is it possible that the requested Mac would not be available in > SunJCE, but it would be available in some other provider? If so, then > PBKDF2 would fail after this change. Should we fall back to the > current behavior if we get a NoSuchAlgorithmException from SunJCE? JN: It seems unlikely that we would make a SunJCE implementation of a given PBKDF2With if we also don't support the PRF portion.? At least up to now we have always supported the PRFs (Hmacs mainly) on SunJCE as well.? It would concern me if we were trying to make a SecretKeyFactory PBKDF2With because, short of a 3rd party provider that has it, it would never work. > > 2) Do you (or anyone else on the mailing list) have any reason to be > concerned that the Mac in SunJCE won't work as well in some cases > where it could also come from another (higher-priority) provider? If > so, then we should think about adding a system property or other > toggle for this behavior. This is a question---not a suggestion. I > don't think we should include this toggle unless we have some > motivation to do so. JN: I'd really prefer to not add yet another property to control something like this if we don't have to.? If you're selecting SunJCE to do PBKDF2 it seems (to me at least) that you're already willing to accept that the crypto operations happen in SunJCE software and the PRF is really the core of that operation.? Given that a higher priority 3rd party provider can hamstring (in admittedly rare cases) SunJCE's implementation, I'd much rather see SunJCE always work regardless of 3rd party provider configuration than see the underlying PRF move to another provider. > > Also, if there is no change to any spec, then I think that means the > scope is "Implementation" rather than "SE". JN: I'll make that change. > > From mbalao at redhat.com Wed Mar 13 16:03:45 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 13 Mar 2019 13:03:45 -0300 Subject: SunJSSE and SunPKCS11 (NSS + FIPS) In-Reply-To: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com> References: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com> Message-ID: Hi Xuelei, On 3/13/19 11:05 AM, Xuelei Fan wrote: > To use FIPS mode JCE provider, an application could: > 1. implement the required algorithm in the FIPS mode JCE provider. > 2. don't those algorithms that outside the scope of the FIPS mode JCE > provider (restrict them). > Yes, there could be a 3rd party JCE provider that implements all the required algorithms and does not even need any other OpenJDK provider to be enabled. When it comes to OpenJDK-only providers, the current way to operate in FIPS is through SunPKCS11. SunPKCS11 alone is not enough for a TLS engine because X.509 (CertificateFactory) is not supported. We need SUN provider to be enabled too. In regards to #2, yes: we can do that. My point, though, is that this is not an easy and reliable user interface to provide FIPS mode in OpenJDK, but a workaround. The list of algorithms wouldn't even be fixed. Despite its drawbacks, the experimental SunJSSE FIPS mode provided a straight path to this use-case. I'm not advocating for re-introducing the whole SunJSSE FIPS feature but wish we could discuss something for providing better support for this use-case. Kind regards, Martin.- From adam.petcher at oracle.com Wed Mar 13 16:56:03 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 13 Mar 2019 12:56:03 -0400 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com> References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com> Message-ID: <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com> Looks good. I added myself as a reviewer. On the subject of PBKDF2With: your response makes sense. I was concerned about a situation in which we parse the algorithm name (similar to Cipher transforms), but it looks like that doesn't happen here. On 3/13/2019 11:48 AM, Jamil Nimeh wrote: > Hi Adam, thanks for the feedback.? I have some comments below: > > On 3/13/2019 6:44 AM, Adam Petcher wrote: >> On 3/12/2019 2:33 PM, Jamil Nimeh wrote: >> >>> Hello all, >>> >>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 >>> implementaion.? This change will make the underlying Mac also come >>> from SunJCE.? This change only affects the SunJCE implementation of >>> PBKDF2, not any other implementation from any different provider. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8220531 >> >> Looks pretty straightforward. I just have a couple of questions >> related to compatibility: >> >> 1) Is it possible that the requested Mac would not be available in >> SunJCE, but it would be available in some other provider? If so, then >> PBKDF2 would fail after this change. Should we fall back to the >> current behavior if we get a NoSuchAlgorithmException from SunJCE? > JN: It seems unlikely that we would make a SunJCE implementation of a > given PBKDF2With if we also don't support the PRF portion.? At > least up to now we have always supported the PRFs (Hmacs mainly) on > SunJCE as well.? It would concern me if we were trying to make a > SecretKeyFactory PBKDF2With because, short of a 3rd > party provider that has it, it would never work. >> >> 2) Do you (or anyone else on the mailing list) have any reason to be >> concerned that the Mac in SunJCE won't work as well in some cases >> where it could also come from another (higher-priority) provider? If >> so, then we should think about adding a system property or other >> toggle for this behavior. This is a question---not a suggestion. I >> don't think we should include this toggle unless we have some >> motivation to do so. > JN: I'd really prefer to not add yet another property to control > something like this if we don't have to.? If you're selecting SunJCE > to do PBKDF2 it seems (to me at least) that you're already willing to > accept that the crypto operations happen in SunJCE software and the > PRF is really the core of that operation.? Given that a higher > priority 3rd party provider can hamstring (in admittedly rare cases) > SunJCE's implementation, I'd much rather see SunJCE always work > regardless of 3rd party provider configuration than see the underlying > PRF move to another provider. >> >> Also, if there is no change to any spec, then I think that means the >> scope is "Implementation" rather than "SE". > JN: I'll make that change. >> >> From chris.hegarty at oracle.com Wed Mar 13 17:04:57 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Mar 2019 17:04:57 +0000 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base Message-ID: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Trivially, there should be a comma after the year. Just add it. $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, 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 diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java --- a/src/java.base/share/classes/sun/security/util/IOUtils.java +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2017, 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 -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Mar 13 17:09:55 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Mar 2019 17:09:55 +0000 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Message-ID: Looks good to me Chris! cheers, -- daniel On 13/03/2019 17:04, Chris Hegarty wrote: > Trivially, there should be a comma after the year. Just add it. From lance.andersen at oracle.com Wed Mar 13 17:10:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 13 Mar 2019 13:10:57 -0400 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> Message-ID: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> +1 > On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote: > > Trivially, there should be a comma after the year. Just add it. > > > $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun > diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2018, 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 > diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java > --- a/src/java.base/share/classes/sun/security/util/IOUtils.java > +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2009, 2017, 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 > > -Chris. 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 bruce.robb at j42.com Tue Mar 12 13:54:58 2019 From: bruce.robb at j42.com (Bruce Robb) Date: Tue, 12 Mar 2019 14:54:58 +0100 Subject: sspi_bridge We have implemented this code, here are the changes we had to make Message-ID: Hi Folks, In November last year, one of our J42 for Application Access customers suddenly announced that they would start using Credential Guard. Back in 2009 we worked with them to build an SSO solution using SPNEGO and JGSS for their 10,000 Windows users. Credential Guard breaks their existing SSO solution so we urgently needed a way to get JGSS to use SSPI. Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/ provided the answer. We have implemented the solution for both Java 8 and Java 11. We did however find a number of issues during development and testing so we would like to feed these back to you. We have written these up in a pdf: https://portal.j42.com/sso/sspi_bridge_updates.pdf Let us know if you have any questions or need more information. We would be happy to use our Active Directory test environment to test your Open JDK implementation, Regards, Bruce Robb **************************************************************************** ** J&B Computing Services bv Celebrating over 30 years of innovative software products and solutions for satisfied customers Telephone: +31 343 596 070 Fax: +31 343 596 079 email support at j42.com Web Sites: http://www.j42.com https://portal.j42.com Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450 **************************************************************************** ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Wed Mar 13 16:28:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Mar 2019 17:28:38 +0100 Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy In-Reply-To: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com> References: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com> Message-ID: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com> On 3/12/19 11:54 AM, Severin Gehwolf wrote: > On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/ This looks good, except the change in KdcPolicy.java. See below: >> Original review: >> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html >> >> This is not a clean backport because the tests in 8u differ slightly >> from those in OpenJDK 10: >> >> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly". >> That same change (adding a property to the @run line) also needs to be >> applied to the new KdcPolicy.java test for it to succeed. It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix? Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From xuelei.fan at oracle.com Wed Mar 13 19:00:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Mar 2019 12:00:19 -0700 Subject: SunJSSE and SunPKCS11 (NSS + FIPS) In-Reply-To: References: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com> Message-ID: <989f889a-577d-c076-cdb0-cea3635066c7@oracle.com> I see your points. Enabling both Sun and a FIPS mode JCE provider could be challenging. I might be a solution to separate the X.509 services from the Sun provider. Xuelei On 3/13/2019 9:03 AM, Martin Balao wrote: > Hi Xuelei, > > On 3/13/19 11:05 AM, Xuelei Fan wrote: >> To use FIPS mode JCE provider, an application could: >> 1. implement the required algorithm in the FIPS mode JCE provider. >> 2. don't those algorithms that outside the scope of the FIPS mode JCE >> provider (restrict them). >> > > Yes, there could be a 3rd party JCE provider that implements all the > required algorithms and does not even need any other OpenJDK provider to > be enabled. When it comes to OpenJDK-only providers, the current way to > operate in FIPS is through SunPKCS11. SunPKCS11 alone is not enough for > a TLS engine because X.509 (CertificateFactory) is not supported. We > need SUN provider to be enabled too. > > In regards to #2, yes: we can do that. My point, though, is that this is > not an easy and reliable user interface to provide FIPS mode in OpenJDK, > but a workaround. The list of algorithms wouldn't even be fixed. Despite > its drawbacks, the experimental SunJSSE FIPS mode provided a straight > path to this use-case. > > I'm not advocating for re-introducing the whole SunJSSE FIPS feature but > wish we could discuss something for providing better support for this > use-case. > > Kind regards, > Martin.- > From sean.mullan at oracle.com Wed Mar 13 20:03:58 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 Mar 2019 16:03:58 -0400 Subject: sspi_bridge We have implemented this code, here are the changes we had to make In-Reply-To: References: Message-ID: <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com> Hi Bruce, First, thank you for your interest in JGSS and providing feedback. Unfortunately, we can't review or accept patches or bug fixes in this form from an external site. I would suggest starting a discussion or summary of each of the issues on this alias (without a proposed patch). We can then file a bug (or bugs) for the issues that we agree on and when it comes time to submit a patch, you will need to first file an OCA (if you have not yet) in order for it to be considered for inclusion into the OpenJDK. See https://openjdk.java.net/contribute/ for more information on the OCA and the process for contributing to OpenJDK in general. Although this may seem a bit onerous, it is a process that we all abide by. Thanks, Sean On 3/12/19 9:54 AM, Bruce Robb wrote: > Hi Folks, > > In November last year, one of our J42 for Application Access > customers suddenly announced > that they would start using Credential Guard. > > Back in 2009 we worked with them to build an SSO solution using SPNEGO > and JGSS for their 10,000 Windows users. > > Credential Guard breaks their existing SSO solution so we urgently > needed a way to get JGSS to use SSPI. > > Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/ > ?provided the answer. > > We have implemented the solution for both Java 8 and Java 11. > > We did however find a number of issues during development and testing so > we would like to feed these back to you. > > We have written these up in a pdf: > https://portal.j42.com/sso/sspi_bridge_updates.pdf > > Let us know if you have any questions or need more information. > > We would be happy to use our Active Directory test environment to test > your Open JDK implementation, > > Regards, > > Bruce Robb > > ****************************************************************************** > > J&B Computing Services bv > > Celebrating over 30 years of innovative software products and solutions > for satisfied customers > > Telephone: +31 343 596 070 > > Fax: +31 343 596 079 > > email support at j42.com > > Web Sites: http://www.j42.com https://portal.j42.com > > Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450 > > ****************************************************************************** > From weijun.wang at oracle.com Thu Mar 14 01:14:55 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Mar 2019 09:14:55 +0800 Subject: RFR 8220598: Malformed copyright year range in a few files in java.base In-Reply-To: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com> <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com> Message-ID: +1 (on the security class). Thanks, Max > On Mar 14, 2019, at 1:10 AM, Lance Andersen wrote: > > +1 >> On Mar 13, 2019, at 1:04 PM, Chris Hegarty wrote: >> >> Trivially, there should be a comma after the year. Just add it. >> >> >> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun >> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2015, 2017, 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 >> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2003, 2018, 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 >> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java >> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java >> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2009, 2017, 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 >> >> -Chris. > > > > 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 > > > From weijun.wang at oracle.com Thu Mar 14 01:52:55 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Mar 2019 09:52:55 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: References: Message-ID: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> > On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote: > > Hi, > This fix just makes sure that specified timezone is not null, Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop). BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z. --Max > and the jar verifying and date formatting use the same different timezone. > > Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 > > Best regards, > John Jiang > From gnu.andrew at redhat.com Thu Mar 14 02:31:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 14 Mar 2019 02:31:15 +0000 Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy In-Reply-To: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com> References: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com> <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com> Message-ID: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com> On 13/03/2019 16:28, Aleksey Shipilev wrote: > On 3/12/19 11:54 AM, Severin Gehwolf wrote: >> On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120 >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/ > > This looks good, except the change in KdcPolicy.java. See below: >>> Original review: >>> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html >>> >>> This is not a clean backport because the tests in 8u differ slightly >>> from those in OpenJDK 10: >>> >>> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly". >>> That same change (adding a property to the @run line) also needs to be >>> applied to the new KdcPolicy.java test for it to succeed. > > It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be > confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix? > I guess. I didn't know about 8190690 until it came up as a diff between the versions of the test in the backported patch and those in 8u. As KdcPolicy.java was failing without it, it seemed logical to move it from the files being removed to this new test so the replacement test was no longer broken. But it does affect the clarity of the backport, you're right. I've filed https://bugs.openjdk.java.net/browse/JDK-8220641 for that issue and generated a new webrev for 8175120: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/ > Thanks, > -Aleksey > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From weijun.wang at oracle.com Thu Mar 14 04:42:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 Mar 2019 12:42:02 +0800 Subject: sspi_bridge We have implemented this code, here are the changes we had to make In-Reply-To: <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com> References: <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com> Message-ID: Hi, owner of 6722928 here, I'm glad my patch is useful for you and many thanks for improving it. As Sean says, please sign the OCA if your improvement is non trivial. Then you can always send the patch file as an attachment and I can convert it to webrev and post it to cr.openjdk.java.net. For other discussions, we can just start in this mail thread. And can you see if https://cr.openjdk.java.net/~weijun/6722928/webrev.04/ is any more helpful? I've mainly made changes around the SPNEGO (Negotiate) mechanism in the last rounds of changes. Thanks, Weijun > On Mar 14, 2019, at 4:03 AM, Sean Mullan wrote: > > Hi Bruce, > > First, thank you for your interest in JGSS and providing feedback. Unfortunately, we can't review or accept patches or bug fixes in this form from an external site. > > I would suggest starting a discussion or summary of each of the issues on this alias (without a proposed patch). We can then file a bug (or bugs) for the issues that we agree on and when it comes time to submit a patch, you will need to first file an OCA (if you have not yet) in order for it to be considered for inclusion into the OpenJDK. See https://openjdk.java.net/contribute/ for more information on the OCA and the process for contributing to OpenJDK in general. > > Although this may seem a bit onerous, it is a process that we all abide by. > > Thanks, > Sean > > > On 3/12/19 9:54 AM, Bruce Robb wrote: >> Hi Folks, >> In November last year, one of our J42 for Application Access customers suddenly announced that they would start using Credential Guard. >> Back in 2009 we worked with them to build an SSO solution using SPNEGO and JGSS for their 10,000 Windows users. >> Credential Guard breaks their existing SSO solution so we urgently needed a way to get JGSS to use SSPI. >> Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/ provided the answer. >> We have implemented the solution for both Java 8 and Java 11. >> We did however find a number of issues during development and testing so we would like to feed these back to you. >> We have written these up in a pdf: https://portal.j42.com/sso/sspi_bridge_updates.pdf >> Let us know if you have any questions or need more information. >> We would be happy to use our Active Directory test environment to test your Open JDK implementation, >> Regards, >> Bruce Robb >> ****************************************************************************** >> J&B Computing Services bv >> Celebrating over 30 years of innovative software products and solutions for satisfied customers >> Telephone: +31 343 596 070 >> Fax: +31 343 596 079 >> email support at j42.com >> Web Sites: http://www.j42.com https://portal.j42.com >> Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450 >> ****************************************************************************** From sean.mullan at oracle.com Thu Mar 14 12:46:16 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 Mar 2019 08:46:16 -0400 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com> References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com> <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com> Message-ID: <78bcf584-b923-b024-d803-0704d1b00168@oracle.com> Jamil, I think it might make sense to change the bug synopsis since it isn't really ignoring the provider argument. Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation". Thanks, Sean On 3/13/19 12:56 PM, Adam Petcher wrote: > Looks good. I added myself as a reviewer. > > On the subject of PBKDF2With: your response makes > sense. I was concerned about a situation in which we parse the algorithm > name (similar to Cipher transforms), but it looks like that doesn't > happen here. > > On 3/13/2019 11:48 AM, Jamil Nimeh wrote: >> Hi Adam, thanks for the feedback.? I have some comments below: >> >> On 3/13/2019 6:44 AM, Adam Petcher wrote: >>> On 3/12/2019 2:33 PM, Jamil Nimeh wrote: >>> >>>> Hello all, >>>> >>>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 >>>> implementaion.? This change will make the underlying Mac also come >>>> from SunJCE.? This change only affects the SunJCE implementation of >>>> PBKDF2, not any other implementation from any different provider. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8220531 >>> >>> Looks pretty straightforward. I just have a couple of questions >>> related to compatibility: >>> >>> 1) Is it possible that the requested Mac would not be available in >>> SunJCE, but it would be available in some other provider? If so, then >>> PBKDF2 would fail after this change. Should we fall back to the >>> current behavior if we get a NoSuchAlgorithmException from SunJCE? >> JN: It seems unlikely that we would make a SunJCE implementation of a >> given PBKDF2With if we also don't support the PRF portion.? At >> least up to now we have always supported the PRFs (Hmacs mainly) on >> SunJCE as well.? It would concern me if we were trying to make a >> SecretKeyFactory PBKDF2With because, short of a 3rd >> party provider that has it, it would never work. >>> >>> 2) Do you (or anyone else on the mailing list) have any reason to be >>> concerned that the Mac in SunJCE won't work as well in some cases >>> where it could also come from another (higher-priority) provider? If >>> so, then we should think about adding a system property or other >>> toggle for this behavior. This is a question---not a suggestion. I >>> don't think we should include this toggle unless we have some >>> motivation to do so. >> JN: I'd really prefer to not add yet another property to control >> something like this if we don't have to.? If you're selecting SunJCE >> to do PBKDF2 it seems (to me at least) that you're already willing to >> accept that the crypto operations happen in SunJCE software and the >> PRF is really the core of that operation.? Given that a higher >> priority 3rd party provider can hamstring (in admittedly rare cases) >> SunJCE's implementation, I'd much rather see SunJCE always work >> regardless of 3rd party provider configuration than see the underlying >> PRF move to another provider. >>> >>> Also, if there is no change to any spec, then I think that means the >>> scope is "Implementation" rather than "SE". >> JN: I'll make that change. >>> >>> From jamil.j.nimeh at oracle.com Thu Mar 14 13:34:54 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 14 Mar 2019 06:34:54 -0700 Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <78bcf584-b923-b024-d803-0704d1b00168@oracle.com> References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com> <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com> <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com> <78bcf584-b923-b024-d803-0704d1b00168@oracle.com> Message-ID: <35af2b82-64d6-1eda-b85b-18d2a753eb19@oracle.com> Yes, I was thinking that might be a good idea too.? I'll make that change shortly. Thanks, --Jamil On 3/14/19 5:46 AM, Sean Mullan wrote: > Jamil, > > I think it might make sense to change the bug synopsis since it isn't > really ignoring the provider argument. > > Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation". > > Thanks, > Sean > > On 3/13/19 12:56 PM, Adam Petcher wrote: >> Looks good. I added myself as a reviewer. >> >> On the subject of PBKDF2With: your response makes >> sense. I was concerned about a situation in which we parse the >> algorithm name (similar to Cipher transforms), but it looks like that >> doesn't happen here. >> >> On 3/13/2019 11:48 AM, Jamil Nimeh wrote: >>> Hi Adam, thanks for the feedback.? I have some comments below: >>> >>> On 3/13/2019 6:44 AM, Adam Petcher wrote: >>>> On 3/12/2019 2:33 PM, Jamil Nimeh wrote: >>>> >>>>> Hello all, >>>>> >>>>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 >>>>> implementaion.? This change will make the underlying Mac also come >>>>> from SunJCE.? This change only affects the SunJCE implementation >>>>> of PBKDF2, not any other implementation from any different provider. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8220531 >>>> >>>> Looks pretty straightforward. I just have a couple of questions >>>> related to compatibility: >>>> >>>> 1) Is it possible that the requested Mac would not be available in >>>> SunJCE, but it would be available in some other provider? If so, >>>> then PBKDF2 would fail after this change. Should we fall back to >>>> the current behavior if we get a NoSuchAlgorithmException from SunJCE? >>> JN: It seems unlikely that we would make a SunJCE implementation of >>> a given PBKDF2With if we also don't support the PRF portion.? >>> At least up to now we have always supported the PRFs (Hmacs mainly) >>> on SunJCE as well. It would concern me if we were trying to make a >>> SecretKeyFactory PBKDF2With because, short of a >>> 3rd party provider that has it, it would never work. >>>> >>>> 2) Do you (or anyone else on the mailing list) have any reason to >>>> be concerned that the Mac in SunJCE won't work as well in some >>>> cases where it could also come from another (higher-priority) >>>> provider? If so, then we should think about adding a system >>>> property or other toggle for this behavior. This is a >>>> question---not a suggestion. I don't think we should include this >>>> toggle unless we have some motivation to do so. >>> JN: I'd really prefer to not add yet another property to control >>> something like this if we don't have to.? If you're selecting SunJCE >>> to do PBKDF2 it seems (to me at least) that you're already willing >>> to accept that the crypto operations happen in SunJCE software and >>> the PRF is really the core of that operation.? Given that a higher >>> priority 3rd party provider can hamstring (in admittedly rare cases) >>> SunJCE's implementation, I'd much rather see SunJCE always work >>> regardless of 3rd party provider configuration than see the >>> underlying PRF move to another provider. >>>> >>>> Also, if there is no change to any spec, then I think that means >>>> the scope is "Implementation" rather than "SE". >>> JN: I'll make that change. >>>> >>>> From jamil.j.nimeh at oracle.com Thu Mar 14 13:34:05 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 14 Mar 2019 06:34:05 -0700 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. Message-ID: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> Hello all, This review will change the SunJCE implementation of PBKDF2 so that it always uses the SunJCE version of the PRF algorithm internally. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 From shade at redhat.com Thu Mar 14 08:56:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Mar 2019 09:56:37 +0100 Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy In-Reply-To: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com> References: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com> <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com> <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com> Message-ID: <9e717b95-1b62-390c-9c25-ea63783668d0@redhat.com> On 3/14/19 3:31 AM, Andrew John Hughes wrote: > I've filed > https://bugs.openjdk.java.net/browse/JDK-8220641 Yes, let's RFR and push that too. > for that issue and generated a new webrev for 8175120: > > https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/ Looks good! -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From adam.petcher at oracle.com Thu Mar 14 14:53:05 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 14 Mar 2019 10:53:05 -0400 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> Message-ID: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> The change to PBKDF2KeyImpl.java looks fine. About the test: *) Is it necessary to put the provider in a separate jar? It seems unnecessary because you are adding it with Security.insertProviderAt. *) Line 54 of the test compares the result of a constructor to null. Unless I'm missing something, this reference will always be non-null. *) At the end of the test, there are some methods that do conversion between hex strings and bytes. Can you use the methods in Convert (in the test list) instead? I think Convert.hexStringToByteArray is the same thing as hex2bin. You may also want to move dumpHexBytes to Convert, but it's fine either way. *) It looks the evilprovider source files have the wrong copyright header. *) There is a commented out line of code on line 16 of EvilProvider.java On 3/14/2019 9:34 AM, Jamil Nimeh wrote: > Hello all, > > This review will change the SunJCE implementation of PBKDF2 so that it > always uses the SunJCE version of the PRF algorithm internally. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 > From jamil.j.nimeh at oracle.com Thu Mar 14 15:18:12 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 14 Mar 2019 08:18:12 -0700 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> Message-ID: Hi Adam, thanks for taking a look at this.? Comments are in-line: On 3/14/19 7:53 AM, Adam Petcher wrote: > The change to PBKDF2KeyImpl.java looks fine. About the test: > > *) Is it necessary to put the provider in a separate jar? It seems > unnecessary because you are adding it with Security.insertProviderAt. JN: I'm honestly not sure.? I thought if I wanted this test to run on both Open and Oracle JDK I thought I'd need the provider to be signed (which the jar file is).? I can try bringing the provider code into the test body itself.? If it runs fine on Oracle JDK then it would be way better to do that and get rid of the makefile and all the attendant source for rebuilding the provider jar. > > *) Line 54 of the test compares the result of a constructor to null. > Unless I'm missing something, this reference will always be non-null. JN: That was left over from an early rev of the test where I was doing Security.getProvider(String) where it can return null.? I'll take that out. > > *) At the end of the test, there are some methods that do conversion > between hex strings and bytes. Can you use the methods in Convert (in > the test list) instead? I think Convert.hexStringToByteArray is the > same thing as hex2bin. You may also want to move dumpHexBytes to > Convert, but it's fine either way. JN: I had meant to fix that before I sent it to review, I'm in the process of making that change now. > > *) It looks the evilprovider source files have the wrong copyright > header. JN: Easily fixed. > > *) There is a commented out line of code on line 16 of EvilProvider.java JN: Good as gone. > > On 3/14/2019 9:34 AM, Jamil Nimeh wrote: >> Hello all, >> >> This review will change the SunJCE implementation of PBKDF2 so that >> it always uses the SunJCE version of the PRF algorithm internally. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 >> From ecki at zusammenkunft.net Thu Mar 14 15:58:00 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 Mar 2019 16:58:00 +0100 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument. In-Reply-To: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> Message-ID: <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval? (I think the change is good in General but that case Needs to be decided). Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature. Gruss Bernd * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 16:36 An: OpenJDK Dev list Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument. Hello all, This review will change the SunJCE implementation of PBKDF2 so that it always uses the SunJCE version of the PRF algorithm internally. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Thu Mar 14 16:16:09 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 14 Mar 2019 09:16:09 -0700 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument. In-Reply-To: <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> Message-ID: <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com> Hi Bernd, thanks for the feedback, comments below: On 3/14/19 8:58 AM, Bernd Eckenfels wrote: > > Looking at the patch it seems obvious that this functionality was > intentional at least for having a PKCS11 MAC. Do we really want to > removbe that Option and if yes des it require some form of aproval? > > (I think the change is good in General but that case Needs to be decided). > JN: Yes, there is definitely an approval process which is in progress.? The CSR link in the original email is the approval process for a behavioral change like this.? The fix itself, even if it is good, won't go back until the CSR is approved. As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.? And for a long time this worked.? But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF algorithm isn't found, it fails on init.? If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure. There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence. There's no easy way get the best of both worlds.? By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).? So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case). Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.? The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE. > Since this is relaed, using a whitebox prf would also allow to do > precomputing of the first hmac block outside of the Iteration, thats > an algorithmic speedup* which attackers implementations surely feature. > > Gruss > > Bernd > > * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf > > -- > http://bernd.eckenfels.net > > *Von: *Jamil Nimeh > *Gesendet: *Donnerstag, 14. M?rz 2019 16:36 > *An: *OpenJDK Dev list > *Betreff: *RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ > ) ignoresthe provider argument. > > Hello all, > > This review will change the SunJCE implementation of PBKDF2 so that it > > always uses the SunJCE version of the PRF algorithm internally. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Mar 14 16:30:52 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 Mar 2019 17:30:52 +0100 Subject: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument. In-Reply-To: <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com> Message-ID: <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com> Hello, is there no case where the passed-in key cannot be used by the SunJCE provider? Isnt that a main reason to use an alternative Provider and PKCS11 especially? I think similiar could be said for MSCAPI (but I think they have no keyhandles for secret keys) or other FIPS Keystores which do not allow to Export key material. One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable) I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway. I thin I havent seen what the case for the init falure in BC MAC was, is this also key related? Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 17:18 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument. Hi Bernd, thanks for the feedback, comments below: On 3/14/19 8:58 AM, Bernd Eckenfels wrote: Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval? ? (I think the change is good in General but that case Needs to be decided). JN: Yes, there is definitely an approval process which is in progress.? The CSR link in the original email is the approval process for a behavioral change like this.? The fix itself, even if it is good, won't go back until the CSR is approved. As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.? And for a long time this worked.? But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF algorithm isn't found, it fails on init.? If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure.? There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence. There's no easy way get the best of both worlds.? By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).? So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case). Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.? The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE. ? Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature. ? Gruss Bernd ? * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf -- http://bernd.eckenfels.net ? Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 16:36 An: OpenJDK Dev list Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument. ? Hello all, ? This review will change the SunJCE implementation of PBKDF2 so that it always uses the SunJCE version of the PRF algorithm internally. ? Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ ? JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 ? CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Thu Mar 14 17:12:48 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 14 Mar 2019 10:12:48 -0700 Subject: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument. In-Reply-To: <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com> <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com> Message-ID: <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com> Hello Bernd, once again I appreciate your comments and have some of my own in-line, On 3/14/2019 9:30 AM, Bernd Eckenfels wrote: > > Hello, > > is there no case where the passed-in key cannot be used by the SunJCE > provider? Isnt that a main reason to use an alternative Provider and > PKCS11 especially? I think similiar could be said for MSCAPI (but I > think they have no keyhandles for secret keys) or other FIPS Keystores > which do not allow to Export key material. > JN: Is there no case?? None that I'm aware of, none that have caused any bugs that I know of - the SecretKey object is made within SunJCE's PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the password bytes).? It seems like it should work for pretty much any password handed in AFAICT. If you were going to have a FIPS keystore come into play, why would you not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its entirety?? That way the resulting SecretKey from a generation operation would hopefully live on the FIPS keystore serviced by that provider.? For SunJCE I think you'd end up having a SecretKey that lived in SunJCE since you're only going to a 3rd party provider for the HMAC calculations.? It just feels a little odd to hang a security argument on a 3rd party provider for HMAC, but be willing to do the encompassing PBKDF2 on SunJCE. All that said, I think even if HMAC is obtained from SunJCE, the underlying MessageDigest probably would come from that 3rd party provider.? But of course there's no key involved, no init to be done, so it's less prone to going wonky. > > One Option would be to make the Mac an Parameter, then at least new > Code could specify different implementers. It still would break > existing PKCS11 deployments (at least for those where the keymaterial > is not exportable) > JN: An option, certainly, but one that would mean at least an API change to PBEKeySpec so the Mac could be passed into the SecretKeyFactory.? That would require much more careful consideration and it would prevent backporting this bugfix since PBEKeySpec is set in stone for any released JDK. > I would argue that the case when you use a JCE PBKDF2 on a JVM where > BC FIPS has higher prio would be wrong anyway. > JN: Generally yes, but not for a case where you ask explicitly for PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, String provider).? That's what happened when the bug occurred. While I don't think it would happen otherwise on BC FIPS (I haven't checked but I assume it has PBKDF2WithHmacSHA1), it is possible for automatic selection to land on SunJCE for that SKF algorithm if some other higher priority provider doesn't have PBKDF2WithHmacSHA1, but does have HmacSHA1 with some FIPS-like key restrictions (which seems like a realistic possibility). > > I thin I havent seen what the case for the init falure in BC MAC was, > is this also key related? > JN: If you look at the original bug the stack trace is there.? In short BC is throwing org.bouncycastle.crypto.IllegalKeyException because the key that is being handed to it while running in FIPS mode is less than 112 bits (according to the exception message). > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Jamil Nimeh > *Gesendet: *Donnerstag, 14. M?rz 2019 17:18 > *An: *Bernd Eckenfels ; OpenJDK Dev > list > *Betreff: *Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, > provider_ )ignoresthe provider argument. > > Hi Bernd, thanks for the feedback, comments below: > > On 3/14/19 8:58 AM, Bernd Eckenfels wrote: > > Looking at the patch it seems obvious that this functionality was > intentional at least for having a PKCS11 MAC. Do we really want to > removbe that Option and if yes des it require some form of aproval? > > (I think the change is good in General but that case Needs to be > decided). > > JN: Yes, there is definitely an approval process which is in > progress.? The CSR link in the original email is the approval process > for a behavioral change like this.? The fix itself, even if it is > good, won't go back until the CSR is approved. > > As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: > Ideally the underlying Mac should be able to come from 3rd party > providers.? And for a long time this worked. But now we're up against > a case where a BC FIPS provider's HMAC implementation is causing the > SunJCE PBKDF2 implementation to fail.? And it fails not because the > PRF algorithm isn't found, it fails on init.? If we're requesting > SunJCE by name (as it was in the case that caused the bug) the mere > presence of BC FIPS as a higher priority provider shouldn't cause this > kind of failure.? There's nothing wrong with either provider in > general, but the interaction between the two has had this unexpected > consequence. > > There's no easy way get the best of both worlds.? By the time we're > down in the guts of the PBKDF2 key implementation where the PRF is > instantiated, we know we're on the SunJCE provider, but we don't know > *how* we got there (by automatic selection or by being chosen > explicitly).? So it's hard to make an intelligent decision about > whether to use the SunJCE version (which will always work) or risk > going out to a 3rd party provider (which usually works, but not in > this case). > > Given the choice, I'm opting for "always working" since SunJCE was > already selected (one way or the other) for PBKDF2.? The PRF is the > key cryptographic piece of that operation so it's not outrageous that > it too should come from SunJCE. > > Since this is relaed, using a whitebox prf would also allow to do > precomputing of the first hmac block outside of the Iteration, > thats an algorithmic speedup* which attackers implementations > surely feature. > > Gruss > > Bernd > > * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf > > -- > http://bernd.eckenfels.net > > *Von: *Jamil Nimeh > *Gesendet: *Donnerstag, 14. M?rz 2019 16:36 > *An: *OpenJDK Dev list > *Betreff: *RFR 8218723: SecretKeyFactory.getInstance( algo_, > provider_ ) ignoresthe provider argument. > > Hello all, > > This review will change the SunJCE implementation of PBKDF2 so > that it > > always uses the SunJCE version of the PRF algorithm internally. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Mar 14 17:23:37 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 Mar 2019 18:23:37 +0100 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument. In-Reply-To: <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com> <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com> <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com> <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com> Message-ID: <5c8a8e19.1c69fb81.8ffc3.5842@mx.google.com> Hello, yes you are right, in the PBKDF2 case there is no external key object which can hit the MAC, so this seems safe. Thanks for bearing with me ? Ist BTW funny how many people want to use a FIPS compliant library and then not use the FIPS restrictions ? (well actually it is not funny, the FIPS provisions are more sad in that case?) Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 18:16 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument. Hello Bernd, once again I appreciate your comments and have some of my own in-line, On 3/14/2019 9:30 AM, Bernd Eckenfels wrote: Hello, ? is there no case where the passed-in key cannot be used by the SunJCE provider? Isnt that a main reason to use an alternative Provider and PKCS11 especially? I think similiar could be said for MSCAPI (but I think they have no keyhandles for secret keys) or other FIPS Keystores which do not allow to Export key material. JN: Is there no case?? None that I'm aware of, none that have caused any bugs that I know of - the SecretKey object is made within SunJCE's PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the password bytes).? It seems like it should work for pretty much any password handed in AFAICT. If you were going to have a FIPS keystore come into play, why would you not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its entirety?? That way the resulting SecretKey from a generation operation would hopefully live on the FIPS keystore serviced by that provider.? For SunJCE I think you'd end up having a SecretKey that lived in SunJCE since you're only going to a 3rd party provider for the HMAC calculations.? It just feels a little odd to hang a security argument on a 3rd party provider for HMAC, but be willing to do the encompassing PBKDF2 on SunJCE. All that said, I think even if HMAC is obtained from SunJCE, the underlying MessageDigest probably would come from that 3rd party provider.? But of course there's no key involved, no init to be done, so it's less prone to going wonky. ? One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable) JN: An option, certainly, but one that would mean at least an API change to PBEKeySpec so the Mac could be passed into the SecretKeyFactory.? That would require much more careful consideration and it would prevent backporting this bugfix since PBEKeySpec is set in stone for any released JDK. ? I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway. JN: Generally yes, but not for a case where you ask explicitly for PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, String provider).? That's what happened when the bug occurred.? While I don't think it would happen otherwise on BC FIPS (I haven't checked but I assume it has PBKDF2WithHmacSHA1), it is possible for automatic selection to land on SunJCE for that SKF algorithm if some other higher priority provider doesn't have PBKDF2WithHmacSHA1, but does have HmacSHA1 with some FIPS-like key restrictions (which seems like a realistic possibility). ? I thin I havent seen what the case for the init falure in BC MAC was, is this also key related? JN: If you look at the original bug the stack trace is there.? In short BC is throwing org.bouncycastle.crypto.IllegalKeyException because the key that is being handed to it while running in FIPS mode is less than 112 bits (according to the exception message). ? Gruss Bernd -- http://bernd.eckenfels.net ? Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 17:18 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument. ? Hi Bernd, thanks for the feedback, comments below: On 3/14/19 8:58 AM, Bernd Eckenfels wrote: Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval? ? (I think the change is good in General but that case Needs to be decided). JN: Yes, there is definitely an approval process which is in progress.? The CSR link in the original email is the approval process for a behavioral change like this.? The fix itself, even if it is good, won't go back until the CSR is approved. As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.? And for a long time this worked.? But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF algorithm isn't found, it fails on init.? If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure.? There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence. There's no easy way get the best of both worlds.? By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).? So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case). Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.? The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE. ? Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature. ? Gruss Bernd ? * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf -- http://bernd.eckenfels.net ? Von: Jamil Nimeh Gesendet: Donnerstag, 14. M?rz 2019 16:36 An: OpenJDK Dev list Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument. ? Hello all, ? This review will change the SunJCE implementation of PBKDF2 so that it always uses the SunJCE version of the PRF algorithm internally. ? Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ ? JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 ? CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Fri Mar 15 04:55:45 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 15 Mar 2019 04:55:45 +0000 Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 Message-ID: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ This is the patch we split out from my original post for 8175120. It applies the same change to the @run command in KdcPolicy.java as was applied to the tests deleted by 8175120 in JDK-8190690. Without this fix, the test fails with a name lookup error. With it, it passes. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sgehwolf at redhat.com Fri Mar 15 09:07:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Mar 2019 10:07:52 +0100 Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> Message-ID: <715a7ac719a9a1ef652fd12c8050ab1d80913e9a.camel@redhat.com> Hi Andrew, On Fri, 2019-03-15 at 04:55 +0000, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 > Webrev: > https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ > > This is the patch we split out from my original post for 8175120. It > applies the same change to the @run command in KdcPolicy.java as was > applied to the tests deleted by 8175120 in JDK-8190690. > > Without this fix, the test fails with a name lookup error. With it, it > passes. This looks good to me. I'm not an 8u Reviewer, though. Thanks, Severin > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html From GROEGES at uk.ibm.com Fri Mar 15 09:46:33 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 15 Mar 2019 09:46:33 +0000 Subject: Use of OpenSSL as JCE security provider if available on system Message-ID: Hi all, Not sure whether something on this subject has been raised before but I was unable to see anything in the mailing lists. We have been looking at adding support to Java to use the OpenSSL libraries as a JCE security provider if available on the system that a Java application is being run on (or to build and bundle the OpenSSL libraries with the JDK). If not found then the security drops back to using the built in security that is part of the existing JDK. The use of the OpenSSL libraries can be disabled entirely or specific algorithms can be disabled by use of command line options, i.e. Djdk.nativeCrypto=true | false and -Djdk.nativeDigest=true | false Would this be something that might be useful to be contributed to OpenJDK. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Fri Mar 15 13:34:38 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 15 Mar 2019 10:34:38 -0300 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: Hi Steve, This looks interesting. I have a couple of questions: 1) Is this integrated to the JCE crypto providers framework or does it work separately? The properties "jdk.nativeCrypto" and "jdk.nativeDigest" made me think it's not. 2) Which algorithms are under scope? Kind regards, Martin.- From mbalao at redhat.com Fri Mar 15 13:34:46 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 15 Mar 2019 10:34:46 -0300 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: <0d4ad6ce-d2f0-16c1-13ae-8a8e74315579@redhat.com> Hi Steve, This looks interesting. I have a couple of questions: 1) Is this integrated to the JCE crypto providers framework or does it work separately? The properties "jdk.nativeCrypto" and "jdk.nativeDigest" made me think it's not. 2) Which algorithms are under scope? Kind regards, Martin.- From darran.lofthouse at jboss.com Fri Mar 15 14:26:58 2019 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 15 Mar 2019 14:26:58 +0000 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: - https://github.com/wildfly/wildfly-openssl On Fri, Mar 15, 2019 at 9:48 AM Steve Groeger wrote: > Hi all, > > Not sure whether something on this subject has been raised before but I > was unable to see anything in the mailing lists. > > We have been looking at adding support to Java to use the OpenSSL > libraries as a JCE security provider if available on the system that a Java > application is being run on (or to build and bundle the OpenSSL libraries > with the JDK). > > If not found then the security drops back to using the built in security > that is part of the existing JDK. > > The use of the OpenSSL libraries can be disabled entirely or specific > algorithms can be disabled by use of command line options, > i.e. Djdk.nativeCrypto=true | false and -Djdk.nativeDigest=true | false > > Would this be something that might be useful to be contributed to OpenJDK. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Fri Mar 15 15:31:05 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 15 Mar 2019 15:31:05 +0000 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: Martin, > 1) Is this integrated to the JCE crypto providers framework or does it work separately? No, this is not currently integrated into the JCE crypto providers framework. The implementation we currently have integrates into the existing JCE providers and it defaults to using the OpenSSL libraries, if they are found and can be used, otherwise it drops back to the existing implementation provided with the JDK. As I stated previously the entire use of the the OpenSSL library can be enabled / disabled as well as the use of specific OpenSSL algorithms using java runtime options. > 2) Which algorithms are under scope? The OpenSSL algorithms we have currently done this work for are RSA, CMC, GCM and Digest. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Martin Balao To: security-dev at openjdk.java.net Date: 15/03/2019 13:35 Subject: Re: Use of OpenSSL as JCE security provider if available on system Sent by: "security-dev" Hi Steve, This looks interesting. I have a couple of questions: 1) Is this integrated to the JCE crypto providers framework or does it work separately? The properties "jdk.nativeCrypto" and "jdk.nativeDigest" made me think it's not. 2) Which algorithms are under scope? Kind regards, Martin.- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Fri Mar 15 16:37:20 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 15 Mar 2019 17:37:20 +0100 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: Hi, On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse wrote: > FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: - > > https://github.com/wildfly/wildfly-openssl There is also the effort from Google, Conscrypt: https://github.com/google/conscrypt It's a full blown JCE and JSSE implementation based on OpenSSL, so it can easily be used in this way; java.security.Security.addProvider(new org.conscrypt.OpenSSLProvider()); To my knowledge, Conscrypt is what's being used in Android and we optionally use it in Jetty too. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From norman.maurer at googlemail.com Fri Mar 15 17:10:14 2019 From: norman.maurer at googlemail.com (Norman Maurer) Date: Fri, 15 Mar 2019 18:10:14 +0100 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: Actually this is not based on OpenSSL but it uses BoringSSL (which provides an OpenSSL API + some extra stuff), just in case it matters for anyone. Bye Norman > On 15. Mar 2019, at 17:37, Simone Bordet wrote: > > Hi, > > On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse > wrote: >> FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: - >> >> https://github.com/wildfly/wildfly-openssl > > There is also the effort from Google, Conscrypt: > https://github.com/google/conscrypt > > It's a full blown JCE and JSSE implementation based on OpenSSL, so it > can easily be used in this way; > > java.security.Security.addProvider(new org.conscrypt.OpenSSLProvider()); > > To my knowledge, Conscrypt is what's being used in Android and we > optionally use it in Jetty too. > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From grajmanu at outlook.com Fri Mar 15 08:50:41 2019 From: grajmanu at outlook.com (Manu G Raj) Date: Fri, 15 Mar 2019 08:50:41 +0000 Subject: [SSL Config] Pull certificate from Window's certificate store Message-ID: Hi, We were trying to simplify the certificate and SSL configuration during our java app deployment in Windows. As part of this, we were trying to pull certificates from Windows-ROOT or Windows-MY by setting System.setProperty("javax.net.ssl.trustStoreType","Windows-ROOT"); System.setProperty("javax.net.ssl.trustStore", "NUL"); There are several claims that only user certificates are available from Windows-ROOT, local machine certificates are not actually read. We have even encountered https://bugs.openjdk.java.net/browse/JDK-6782021 and its subsequent mails. Would just like to know, if the above properties are set, then will the machine certificates be resolved. Java version: Java8u201 Regards, Manu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri Mar 15 10:57:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 Mar 2019 11:57:53 +0100 Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> Message-ID: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com> On 3/15/19 5:55 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ Looks good, ship it. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From darran.lofthouse at redhat.com Fri Mar 15 14:24:43 2019 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Fri, 15 Mar 2019 14:24:43 +0000 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: - https://github.com/wildfly/wildfly-openssl On Fri, Mar 15, 2019 at 9:48 AM Steve Groeger wrote: > Hi all, > > Not sure whether something on this subject has been raised before but I > was unable to see anything in the mailing lists. > > We have been looking at adding support to Java to use the OpenSSL > libraries as a JCE security provider if available on the system that a Java > application is being run on (or to build and bundle the OpenSSL libraries > with the JDK). > > If not found then the security drops back to using the built in security > that is part of the existing JDK. > > The use of the OpenSSL libraries can be disabled entirely or specific > algorithms can be disabled by use of command line options, > i.e. Djdk.nativeCrypto=true | false and -Djdk.nativeDigest=true | false > > Would this be something that might be useful to be contributed to OpenJDK. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Mar 15 17:58:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 15 Mar 2019 17:58:59 +0000 Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 In-Reply-To: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com> References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com> Message-ID: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com> +1 Paul ?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: On 3/15/19 5:55 AM, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ Looks good, ship it. -Aleksey From gnu.andrew at redhat.com Fri Mar 15 18:58:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 15 Mar 2019 18:58:00 +0000 Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 In-Reply-To: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com> References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com> <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com> <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com> Message-ID: On 15/03/2019 17:58, Hohensee, Paul wrote: > +1 > > Paul > > ?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: > > On 3/15/19 5:55 AM, Andrew John Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/ > > Looks good, ship it. > > -Aleksey > > > Thanks, guys. Just waiting on aph to set jdk8u-fix-yes on it now. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From jamil.j.nimeh at oracle.com Fri Mar 15 22:05:22 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 15 Mar 2019 15:05:22 -0700 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> Message-ID: <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com> Hello all, I've updated the webrev with all of Adam's findings with one exception.? I did try bringing the crypto provider code in-line. That approach will work for OpenJDK where there is no 3rd party signing requirement, but on Oracle JDK it will not and the provider needs to be in the form of a signed jar file.? I would like this to run on both JDKs, especially since the provider selection codepaths are a bit different between Oracle and Open JDKs.? Also the original bug came in against Oracle JDK so it would be nice to have the test run there. http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.02 Thanks, --Jamil On 3/14/19 7:53 AM, Adam Petcher wrote: > The change to PBKDF2KeyImpl.java looks fine. About the test: > > *) Is it necessary to put the provider in a separate jar? It seems > unnecessary because you are adding it with Security.insertProviderAt. > > *) Line 54 of the test compares the result of a constructor to null. > Unless I'm missing something, this reference will always be non-null. > > *) At the end of the test, there are some methods that do conversion > between hex strings and bytes. Can you use the methods in Convert (in > the test list) instead? I think Convert.hexStringToByteArray is the > same thing as hex2bin. You may also want to move dumpHexBytes to > Convert, but it's fine either way. > > *) It looks the evilprovider source files have the wrong copyright > header. > > *) There is a commented out line of code on line 16 of EvilProvider.java > > On 3/14/2019 9:34 AM, Jamil Nimeh wrote: >> Hello all, >> >> This review will change the SunJCE implementation of PBKDF2 so that >> it always uses the SunJCE version of the PRF algorithm internally. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 >> From mbalao at redhat.com Sat Mar 16 19:52:09 2019 From: mbalao at redhat.com (Martin Balao) Date: Sat, 16 Mar 2019 16:52:09 -0300 Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider Message-ID: Hi, Can I have a review for JDK-8220753 [1]? * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/ The test is almost identical to the previous one [2], with a few changes in the "initialize" function (so it does not depend on the removed SunJSSE FIPS feature anymore). Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8220753 [2] - http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java From sha.jiang at oracle.com Mon Mar 18 12:28:49 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 18 Mar 2019 20:28:49 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> References: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> Message-ID: <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com> Hi Max, If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone. Currently, the testing machines should use GMT-7/PDT. If no user.timezone is specified, jarsigner just uses local timezone. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/ It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone. Best regards, John Jiang On 2019/3/14 09:52, Weijun Wang wrote: > >> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote: >> >> Hi, >> This fix just makes sure that specified timezone is not null, > Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop). > > BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z. > > --Max > >> and the jar verifying and date formatting use the same different timezone. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 >> >> Best regards, >> John Jiang >> > From adam.petcher at oracle.com Mon Mar 18 13:43:19 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 18 Mar 2019 09:43:19 -0400 Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores the provider argument. In-Reply-To: <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com> References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com> <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com> <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com> Message-ID: <70135120-3a26-0a6b-d579-9e535a670ec5@oracle.com> Hi Jamil, This looks good to me. I read through the discussion about running the Mac in hardware, and I think it is fine if this is not supported by SunJCE. It doesn't look like the current API for Mac fully allows this, and even if it did, it would be simpler to stay in SunJCE once that provider is selected. If running the PRF in hardware is desired, then the way to accomplish that is for all of PBKDF2 to happen in the hardware provider. On 3/15/2019 6:05 PM, Jamil Nimeh wrote: > Hello all, > > I've updated the webrev with all of Adam's findings with one > exception.? I did try bringing the crypto provider code in-line. That > approach will work for OpenJDK where there is no 3rd party signing > requirement, but on Oracle JDK it will not and the provider needs to > be in the form of a signed jar file.? I would like this to run on both > JDKs, especially since the provider selection codepaths are a bit > different between Oracle and Open JDKs.? Also the original bug came in > against Oracle JDK so it would be nice to have the test run there. > > http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.02 > > Thanks, > > --Jamil > > On 3/14/19 7:53 AM, Adam Petcher wrote: >> The change to PBKDF2KeyImpl.java looks fine. About the test: >> >> *) Is it necessary to put the provider in a separate jar? It seems >> unnecessary because you are adding it with Security.insertProviderAt. >> >> *) Line 54 of the test compares the result of a constructor to null. >> Unless I'm missing something, this reference will always be non-null. >> >> *) At the end of the test, there are some methods that do conversion >> between hex strings and bytes. Can you use the methods in Convert (in >> the test list) instead? I think Convert.hexStringToByteArray is the >> same thing as hex2bin. You may also want to move dumpHexBytes to >> Convert, but it's fine either way. >> >> *) It looks the evilprovider source files have the wrong copyright >> header. >> >> *) There is a commented out line of code on line 16 of EvilProvider.java >> >> On 3/14/2019 9:34 AM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This review will change the SunJCE implementation of PBKDF2 so that >>> it always uses the SunJCE version of the PRF algorithm internally. >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723 >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531 >>> From weijun.wang at oracle.com Mon Mar 18 14:04:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 18 Mar 2019 22:04:24 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com> References: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com> Message-ID: <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com> Hi John, The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good. Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot. Thanks, Max > On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote: > > Hi Max, > If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone. > Currently, the testing machines should use GMT-7/PDT. > If no user.timezone is specified, jarsigner just uses local timezone. > > Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/ > It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone. > > Best regards, > John Jiang > > On 2019/3/14 09:52, Weijun Wang wrote: >> >>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote: >>> >>> Hi, >>> This fix just makes sure that specified timezone is not null, >> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop). >> >> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z. >> >> --Max >> >>> and the jar verifying and date formatting use the same different timezone. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 >>> >>> Best regards, >>> John Jiang >>> >> From jamil.j.nimeh at oracle.com Mon Mar 18 16:26:47 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 18 Mar 2019 09:26:47 -0700 Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA signatures... In-Reply-To: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com> References: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com> Message-ID: <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com> Hi Adam, this looks good.? For your test it seems perfectly reasonable to make a mock SecureRandom that lets you control the bits since you're trying to run a known-answer test for a function that would normally be non-deterministic.? Just one really tiny nit, update the copyright on ec.c. --Jamil On 3/4/19 11:40 AM, Adam Petcher wrote: > webrev: https://cr.openjdk.java.net/~apetcher/8147502/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8147502 > > Please review this fix to a bug that causes ECDSA signatures to be > incorrect in some cases. The fix is simple, but testing this issue is > difficult because the API doesn't give access to the raw signing > operation so we can check it using known answer tests. I got around > this difficulty in the regression test by using a modified > SecureRandom that supplies specific bits in order to produce the > correct nonce. The test is a bit complicated and brittle, so if anyone > has any other suggestions on how to do this, please share. > From jamil.j.nimeh at oracle.com Mon Mar 18 16:48:33 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 18 Mar 2019 09:48:33 -0700 Subject: RFR: release note for JDK-8218723 Message-ID: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com> Hi guys, Can someone give a quick review for the release note for JDK-8218723 (the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the underlying PRF)?? Should be really quick.? I have it here: https://bugs.openjdk.java.net/browse/JDK-8220791 Thanks, --Jamil From adam.petcher at oracle.com Mon Mar 18 17:35:45 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 18 Mar 2019 13:35:45 -0400 Subject: RFR: release note for JDK-8218723 In-Reply-To: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com> References: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com> Message-ID: <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com> A couple of comments: *) I think it would be helpful to also describe the change using API terms, so it is more clear to programmers who may not recognize all the crypto terminology. Perhaps: "... will now exclusively use the SunJCE Mac service for the underlying pseudorandom function (PRF)." *) It's labeled RN-IssueFixed, but the text describes a change in behavior, not an issue. Maybe add a sentence like: "This change fixes an issue where..." Or perhaps use RN-Change, if the purpose of the note is to describe the change in behavior. On 3/18/2019 12:48 PM, Jamil Nimeh wrote: > Hi guys, > > Can someone give a quick review for the release note for JDK-8218723 > (the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the > underlying PRF)?? Should be really quick.? I have it here: > > https://bugs.openjdk.java.net/browse/JDK-8220791 > > Thanks, > > --Jamil > From jamil.j.nimeh at oracle.com Mon Mar 18 17:49:44 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 18 Mar 2019 10:49:44 -0700 Subject: RFR: release note for JDK-8218723 In-Reply-To: <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com> References: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com> <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com> Message-ID: <8c8e9db2-2840-1bc0-5b88-b02aacffa726@oracle.com> Thanks, I didn't see RN-Change on the guidance page I was looking at for the notes.? Underlying this change in behavior is an actual issue (that a BC FIPS provider was causing SunJCE's PBKDF SecKeyFac from working due to the interaction between the SKF and the underlying Mac from the two different providers).? I'll make the text changes you suggest and we'll see how it reads. Thanks for the feedback, --Jamil On 3/18/19 10:35 AM, Adam Petcher wrote: > A couple of comments: > > *) I think it would be helpful to also describe the change using API > terms, so it is more clear to programmers who may not recognize all > the crypto terminology. Perhaps: "... will now exclusively use the > SunJCE Mac service for the underlying pseudorandom function (PRF)." > > *) It's labeled RN-IssueFixed, but the text describes a change in > behavior, not an issue. Maybe add a sentence like: "This change fixes > an issue where..." Or perhaps use RN-Change, if the purpose of the > note is to describe the change in behavior. > > On 3/18/2019 12:48 PM, Jamil Nimeh wrote: >> Hi guys, >> >> Can someone give a quick review for the release note for JDK-8218723 >> (the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the >> underlying PRF)?? Should be really quick.? I have it here: >> >> https://bugs.openjdk.java.net/browse/JDK-8220791 >> >> Thanks, >> >> --Jamil >> From sha.jiang at oracle.com Mon Mar 18 23:19:14 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 19 Mar 2019 07:19:14 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com> References: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com> <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com> Message-ID: <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com> Hi Max, On 2019/3/18 22:04, Weijun Wang wrote: > Hi John, > > The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good. > > Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot. I had reproduced this issue. It only raised at the midnight. The cause is what I mentioned on "-J-Duser.timezone=null". The test passed with my fix. Best regards, John Jiang > > Thanks, > Max > >> On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote: >> >> Hi Max, >> If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone. >> Currently, the testing machines should use GMT-7/PDT. >> If no user.timezone is specified, jarsigner just uses local timezone. >> >> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/ >> It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone. >> >> Best regards, >> John Jiang >> >> On 2019/3/14 09:52, Weijun Wang wrote: >>>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote: >>>> >>>> Hi, >>>> This fix just makes sure that specified timezone is not null, >>> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop). >>> >>> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z. >>> >>> --Max >>> >>>> and the jar verifying and date formatting use the same different timezone. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 >>>> >>>> Best regards, >>>> John Jiang >>>> > From weijun.wang at oracle.com Tue Mar 19 00:39:34 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Mar 2019 08:39:34 +0800 Subject: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output In-Reply-To: <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com> References: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com> <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com> <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com> <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com> Message-ID: > On Mar 19, 2019, at 7:19 AM, sha.jiang at oracle.com wrote: > > Hi Max, > > On 2019/3/18 22:04, Weijun Wang wrote: >> Hi John, >> >> The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good. >> >> Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot. > > I had reproduced this issue. It only raised at the midnight. > The cause is what I mentioned on "-J-Duser.timezone=null". > The test passed with my fix. Great! --Max > > Best regards, > John Jiang > >> >> Thanks, >> Max >> >>> On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone. >>> Currently, the testing machines should use GMT-7/PDT. >>> If no user.timezone is specified, jarsigner just uses local timezone. >>> >>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/ >>> It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone. >>> >>> Best regards, >>> John Jiang >>> >>> On 2019/3/14 09:52, Weijun Wang wrote: >>>>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote: >>>>> >>>>> Hi, >>>>> This fix just makes sure that specified timezone is not null, >>>> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop). >>>> >>>> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z. >>>> >>>> --Max >>>> >>>>> and the jar verifying and date formatting use the same different timezone. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >> From xuelei.fan at oracle.com Tue Mar 19 15:51:58 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Mar 2019 08:51:58 -0700 Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider In-Reply-To: References: Message-ID: Hi Martin, In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" should be disabled in the test case? It may help for further update if RSASSA-PSS get supported in the SunPKCS11 provider in the future. Otherwise, looks fine to me. Thanks, Xuelei On 3/16/2019 12:52 PM, Martin Balao wrote: > Hi, > > Can I have a review for JDK-8220753 [1]? > > * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/ > > The test is almost identical to the previous one [2], with a few changes > in the "initialize" function (so it does not depend on the removed > SunJSSE FIPS feature anymore). > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8220753 > [2] - > http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java > From adam.petcher at oracle.com Tue Mar 19 19:22:15 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 19 Mar 2019 15:22:15 -0400 Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA signatures... In-Reply-To: <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com> References: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com> <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com> Message-ID: <15db61b6-c1b4-1cfd-937a-946b6bc1318f@oracle.com> Thanks! I updated the copyright in the push. On 3/18/2019 12:26 PM, Jamil Nimeh wrote: > Hi Adam, this looks good.? For your test it seems perfectly reasonable > to make a mock SecureRandom that lets you control the bits since > you're trying to run a known-answer test for a function that would > normally be non-deterministic.? Just one really tiny nit, update the > copyright on ec.c. > > --Jamil > > On 3/4/19 11:40 AM, Adam Petcher wrote: >> webrev: https://cr.openjdk.java.net/~apetcher/8147502/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8147502 >> >> Please review this fix to a bug that causes ECDSA signatures to be >> incorrect in some cases. The fix is simple, but testing this issue is >> difficult because the API doesn't give access to the raw signing >> operation so we can check it using known answer tests. I got around >> this difficulty in the regression test by using a modified >> SecureRandom that supplies specific bits in order to produce the >> correct nonce. The test is a bit complicated and brittle, so if >> anyone has any other suggestions on how to do this, please share. >> From valerie.peng at oracle.com Tue Mar 19 22:17:14 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 Mar 2019 15:17:14 -0700 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: References: Message-ID: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> How about another potential problem - wrapper key may never get deleted? If we don't have a good solution to addressing it, at least add a comment about it? Rest looks fine. Thanks, Valerie On 3/12/2019 3:34 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for JDK-8220513 [1]: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.00/ > > Testing: > > * No regressions found in sun/security/pkcs11 > > * This bug was exposed by TestTLS12 test, in jdk11u [2]. I'm working in > re-introducing this test to JDK (after JDK-8217835 deleted it). An issue > [4] has to be worked out first though. I'll followup on this. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8220513 > [2] - > http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d17a1764a0f3/test/jdk/sun/security/pkcs11/fips/TestTLS12.java > [3] - https://bugs.openjdk.java.net/browse/JDK-8217835 > [4] - > https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html From weijun.wang at oracle.com Wed Mar 20 02:20:28 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 Mar 2019 10:20:28 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190215214502.GB4046@twosigma.com> References: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com> <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> Message-ID: New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and interdiff at https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html I'll think more about secondsUntil() and getTGTEndTime(). Other comments below. > - sspi.cpp:61 > > 61 #define SEC_SUCCESS(status) (*minor_status = status, (status) >= SEC_E_OK) > ^^^^^^^^^^^^^^^^^^^^^^ > > Please add parenthesis around the whole assignment expression. OK, but what kind of bad things could happen? > > - sspi.cpp:129 > > 129 static long > 130 secondsUntil(int inputIsUTC, TimeStamp *time) > > There's no need to return a signed number, and you assign it to OM_uint32 > variables anyways, and we don't care if some credential expired in the past. > > So just make this return an unsigned integral type, preferably just > OM_uint32. > > So just rewrite as: > > static OM_uint32 > secondsUntil(int inputIsUTC, TimeStamp *time) > { > // time is local time > ULARGE_INTEGER uiLocal; > FILETIME now; > GetSystemTimeAsFileTime(&now); > if (!inputIsUTC) { > FILETIME nowLocal; > if (FileTimeToLocalFileTime(&now, &nowLocal) == 0) { > return -1; > } > now = nowLocal; > } > uiLocal.HighPart = now.dwHighDateTime; > uiLocal.LowPart = now.dwLowDateTime; > long diff = (long)((time->QuadPart - uiLocal.QuadPart) / 10000000); > if (diff < 0) > return 0; > if (sizeof(long) > sizeof(OM_uint32) && diff > (long)~(OM_uint32)0) > return GSS_C_INDEFINITE; > return diff; > } OK. > > - sspi.cpp:NewContext() > > Please fully-initialize all fields of the allocated context structure before > returning it. Some of them are of struct types, do I need to go inside and set each to zero? Or ZeroMemory the whole struct? For example: typedef struct _SecHandle { ULONG_PTR dwLower; ULONG_PTR dwUpper; } SecHandle, * PSecHandle; > > Or else use new gss_ctx_id_struct() syntax, or specify a constructor. > > - sspi.cpp:169 > > -->165 out->phCred = NULL; > 166 out->cbMaxMessage = pkgInfo->cbMaxToken; > 167 PP("pkgInfo->cbMaxToken: %ld", pkgInfo->cbMaxToken); > 168 FreeContextBuffer(pkgInfo); > -->169 out->phCred = NULL; > > Dup code. Ah yes. > > - sspi.cpp:flagSspi2Gss() and flagGss2Sspi() > > I realize that this would be a change to the Java bindings, so this is just > a note, but, we should add support for GSS_C_DELEG_POLICY_FLAG. How? Always set it with GSS_C_DELEG_FLAG? > > - sspi.cpp:getTGTEndTime() > > Please immediately write to the `endTime' output parameter upon entry. Are you afraid of garbages for "return 1"s? But I won't touch the parameter at all in this case. > > - sspi.cpp:getTGTEndTime() > > You leak the logonHandle. You have to close it with > LsaDeregisterLogonProcess() before returning after LsaConnectUntrusted() > returns successfully. OK. > > - sspi.cpp:getTGTEndTime() > > Maybe just make this return OM_uint32 and simplify the one call site, making > it return 86400 seconds (1 day) or whatever for the error case, else the > secondsUntil() the time indicated by the LSA in response to the > KerbRetrieveTicketMessage request. I'll think about it. > > - sspi.cpp:316,355 > > It is rather concerning that get_full_name() can return its input or a > modified copy of its input. At the call sites there's no check to see if > the returned value is allocated, and it's hard to analyze if you're > ultimately leaking or double-freeing. > > This isn't performance-critical code, so just always allocate a copy. OK. > > - sspi.cpp:315 > > 314 // input has realm, no need to add one > 315 if (wcschr(input, '@')) { > > This is not going to work with UPNs. Why not? I just want to find out if there is already a realm. > You should probably implement proper > RFC1864 name format support, including backslash-quoting. Ahh... > > - sspi.cpp:315 > > 315 if (wcschr(input, '@')) { > ^ > > I don't know if it is necessary that this be L'@' or if the compiler will do > the right thing because the `wc' argument of `wcschr()' is a `wchar_t'. > > Elsewhere you do use wide character literals, so I assume even if type > promotion works correctly for char->WCHAR (does it?) you might want to be > consistent. I'll made them all L'@'. > > - sspi.cpp:328 > > 328 // Solution #2: Or just use an empty string (and hope referral works). > 329 // This does not work now because ServicePermission check is based on > 330 // the exported name. Unless we update ServicePermission check to > 331 // be friendly with referral we need a realm. > 332 //realm = L""; > > Yes, ServicePermission is a bit of a disaster. I hope after we integrate > our contribution we can clean it up somewhat. > > - sspi.cpp:337 > > 337 realm = _wgetenv(L"USERDNSDOMAIN"); > > This is actually probably the best thing to do. Referrals should get chased > from there. > > Or we could get the realm from the user's principal name and use that. > > - sspi.cpp:344 > > There's no wide string version of strdup()?? Ugh. There is _wcsdup() but I need to make it longer here. > > wchar_t/WCHAR is cancer. > > I worry that adding any more wchar_t-using code makes worse the legacy > cleanup as Windows starts to prefer UTF-8. But whatever. > > - sspi.cpp:351 > > 351 wcscpy_s(fullname + oldlen + 1, wcslen(realm) + 1, realm); > > It would be safer to use wcscat_s(). How is this unsafe? If using wcscat_s(), I'll need to add a '\0' after the '@' first. > > - sspi.cpp:362 > > 362 #define CHECK_OUTPUT(x) if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; > > I would much prefer the more standard and safer do { ... } while (0) > construction: > > 362 #define CHECK_OUTPUT(x) \ > do { if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; } while (0) I can do that, but why is this safer? > > I would do this for all your macros. > > I'm also not sure it's worth having these macros. You mean there is actually no need to check the arguments? > > - sspi.cpp:398-405 > > I don't believe there's an exported name token format for SPNEGO MNs. In > principle any MNs produced by SPNEGO should be for the negotiated mechanism. > What you should do here instead is check that the exported name token is for > Kerberos, and if not return an error immediately. OK. > > And your gss_export_name() correctly always puts the Kerberos mechanism OID > in exported name tokens. > > - sspi.cpp:412 > > 412 len = MultiByteToWideChar(CP_ACP, 0, input, len, value, len+1); > ^^^^^^ > > Please use CP_UTF8 when en-widening the string in an exported Kerberos name > token. OK. > > - sspi.cpp:465 > > 465 // Initialized as different > 466 *name_equal = 0; > > No need to comment the obvious :) Oh. > > - sspi.cpp:gss_compare_name() > > Just a note: your `struct gss_name_struct' doesn't keep track of import name > type, so you can't check that here. That's OK. It's not worth trying to > keep track of it -- I'm just pointing this out. > > - sspi.cpp:527 > > 527 int len = (int)wcslen(fullname); > > You don't need that cast. There was a warning. > But you should check first that `wcslen()' did > not return a value larger than `INT_MAX'. > > You only even need an `int len' because `WideCharToMultiByte()' returns > `int'... > > I'd write this like: > > 527 int len; > size_t namelen = wcslen(fullname); > if (namelen > 255) > goto err; > // 04 01 00 ** 06 ** OID len:int32 name > // ... > // > > - sspi.cpp:545 > > 545 len = WideCharToMultiByte(CP_ACP, 0, fullname, len, > ^^^^^^ > > s/CP_ACP/CP_UTF8/ > > It's clear that the intent of RFC2743 was to have name strings be in some > standard encoding, not the locale's, though RFC2743 says "Latin-1", which > isn't precise enough, and useless anyways. Otherwise, if we needed to use > the codepage being used by the application we'd have to first determine what > that is. The application here is Java, which will be using UTF-8 anyways, > no? so just do that. Definitely not ANSI. > > - sspi.cpp:532,574 > > You can't assume the length of a multi-byte string will be the same number > of `char' as the number of `wchar_t' in the wide-char version of the string. > > Determinining the correct length is a bit tricky, though since we should be > converting to UTF-8 (see above), you can assume that 4x is enough, use > 4*len for the buffer allocation, then take the correct length from > WideCharToMultiByte(). OK. > > - sspi.cpp:630-644 > > This should be done after successfully acquiring a credential. Before that, > if actual_mechs != NULL then set *actual_mechs = GSS_C_NO_OID_SET. OK. > > - sspi.cpp:gss_acquire_cred() > > It would be good to set *minor_status in more cases. > > - sspi.cpp:607 > > 606 TimeStamp ts; > 607 ts.QuadPart = 0; > > Huh? TimeStamp is a typedef of SECURITY_INTEGER, and SECURITY_INTEGER is a > struct of the same shape and size as FILETIME, and has no QuadPart field. > > What am I missing? It compiles. I think it's a union of one Quad or two DWORD. > > - sspi.cpp:651 > > 651 ts.QuadPart = 0; > > You've already initialized this at 607. Oops. > > - sspi.cpp:704-711 > > As mentioned above, you could move this all into a utility function. And > there's no need to support anything other than unsigned expiration times. > GSS only uses OM_uint32 for those. If a credential is expired you'll get > GSS_S_NO_CRED, not a negative expiration time. (You might get > GSS_S_COMPLETE and a zero lifetime_rec, but that would be a race condition.) See above. > > - sspi.cpp:767 > > I would prefer that all output parameters be initialized early (to zero, > GSS_C_NO_NAME, etc.) before any work is done that might cause failure. OK. > > - sspi.cpp:813 > > I would prefer that *minor_status is always set to something, even zero. > > Meaningful minor status values would be nice, but that can come later. OK. > > - sspi.cpp:871 > > s/CP_ACP/CP_UTF8/ OK. > > - sspi.cpp:870-872 > > Check errors here: > > 870 gss_display_name(&minor, target_name, &tn, NULL); > > Wrong buffer length here: > > 871 int len = MultiByteToWideChar(CP_ACP, 0, (LPCCH)tn.value, (int)tn.length, > 872 outName, (int)tn.length); > ^^^^^^^^^^^^^^ > > Replace that with with `sizeof(outName) - 1' please (the `- 1' is > important). Yes. > > 873 if (len == 0) { > 874 return GSS_S_FAILURE; > 875 } > > - sspi.cpp:897-898 > > 897 } else { > 898 if (!pc->phCred) { > ... > 932 } > 933 } > > You can de-indent all of of 899-931 by re-writing as: > > 897 } else if (!pc->phCred) { > ... > 931 } Good. > > - sspi.cpp:844 > > 844 if (input_token->length == 0) { > > Technically-speaking input_token can be NULL here. Maybe the Java JNI > bindings for GSS always pass in a token? But I'd still change this to > `input_token == NULL || input_token->length == 0'. > > Similarly at 889. And 936. ... Yes. > > - sspi.cpp:596 > > 596 const gss_OID_set desired_mech, > > Nit: since it's an OID set, the name for this argument is `desired_mechs'. OK. > > - sspi.cpp:841 > > 841 BOOLEAN isSPNEGO = isSameOID(mech_type, &SPNEGO_OID); > > Watch out! mech_type can be GSS_C_NO_OID (NULL)! > > isSameOid() will dereference that. > > If the Java JNI bindings for GSS just happen to always pass in a mech_type, > that's OK, but I think you should not assume this and be safe. I'll fix isSameOID(). > > - sspi.cpp:954 > > Should you check if there's an output token before doing this: > > 954 ss = CompleteAuthToken(&pc->hCtxt, &outBuffDesc); > > ? Does this matter? Do you think CompleteAuthToken cannot deal with no token? > > - sspi.cpp:874 and others > > delete `output_token->value' and set it to NULL (and the length to 0) before > returning errors after 865. OK. Is this just a good habit or do you know someone using it even at a failure? > > - sspi.cpp:878,962-963 > > The local variable `pfDone' is set but not used. Drop it. OK, > > (The compiler should have warned about this, no?) No. > > - sspi.cpp:964-966 > > Change this: > > 964 outFlag = flagSspi2Gss(outFlag); > 965 > 966 *ret_flags = (OM_uint32)outFlag; > > to: > > 964 *ret_flags = flagSspi2Gss(outFlag); > > You don't use outFlag again. Setting it to a different kind of set of flags > seems like a trap for someone to fall into in the future. Good. > > - sspi.cpp:948 > > 948 if (!SEC_SUCCESS(ss)) { > 949 return GSS_S_FAILURE; > 950 } > 951 > 952 if ((SEC_I_COMPLETE_NEEDED == ss) > 953 || (SEC_I_COMPLETE_AND_CONTINUE == ss)) { > > I can't find documentation on SEC_SUCCES(). I don't know if it treats > SEC_I_COMPLETE_NEEDED as an error or not... I gues it must not. Can you > confirm? Not an error. I defined SEC_SUCCESS in this file. > > - sspi.cpp:967-970 > > Does QueryContextAttributes() initialize its output parameter if it fails: > > 967 // Ignore the result of the next call. Might fail before context established. > 968 QueryContextAttributes( > 969 &pc->hCtxt, SECPKG_ATTR_SIZES, &pc->SecPkgContextSizes); > > ? > > If not then you'll print garbage at 970: > > 970 PP("cbMaxToken: %ld. cbMaxSignature: %ld. cbBlockSize: %ld. cbSecurityTrailer: %ld", > 971 pc->SecPkgContextSizes.cbMaxToken, > 972 pc->SecPkgContextSizes.cbMaxSignature, > 973 pc->SecPkgContextSizes.cbBlockSize, > 974 pc->SecPkgContextSizes.cbSecurityTrailer); > > Though if you properly initialize the context, then these should all be > zeroes. > > Similarly at 979 and 980. I see. Now I initialize them at newContext(). > > - sspi.cpp:979-983 > > Move 980: > > 979 ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames); > --->980 PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName); > 981 if (!SEC_SUCCESS(ss)) { > 982 return GSS_S_FAILURE; > 983 } > > to after the SEC_SUCCESS(): > > 979 ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames); > 980 if (!SEC_SUCCESS(ss)) { > 981 return GSS_S_FAILURE; > 982 } > 983 PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName); OK. > > - sspi.cpp:1067 > > Since you don't initialize output parameters early in this function, you > might goto err and delete garbage: > > 1067 err: > 1068 if (n1 != NULL) { > 1069 if (n1->name != NULL) { > 1070 delete[] n1->name; > 1071 } > 1072 delete n1; > 1073 n1 = NULL; > 1074 } > 1075 if (n2 != NULL) { > 1076 if (n2->name != NULL) { > > Just initialize all output parameters early. Yes. > > - sspi.cpp:1002 > > It should be simple now to implement this... > > 1002 PP(">>>> Calling UNIMPLEMENTED gss_accept_sec_context..."); > 1003 return GSS_S_FAILURE; Not our goal this time, and I don't know how to test. Does server on Windows only run as services? > > - gssapi.h:gss_acquire_cred() > > @@ -387,13 +399,13 @@ > > /* Function Prototypes */ > > GSS_DLLIMP OM_uint32 gss_acquire_cred( > OM_uint32 *, /* minor_status */ > - gss_name_t, /* desired_name */ > + gss_const_name_t, /* desired_name */ > OM_uint32, /* time_req */ > - gss_OID_set, /* desired_mechs */ > ---->+ const gss_OID_set, /* desired_mechs */ > gss_cred_usage_t, /* cred_usage */ > gss_cred_id_t *, /* output_cred_handle */ > gss_OID_set *, /* actual_mechs */ > OM_uint32 * /* time_rec */ > ); > > That needs to be `gss_const_OID_set', not `const gss_OID_set'. > > There's a number of these. Just search for "const gss_" -- any time you see > that in a function prototype, it's wrong. I think I copied all of them from Heimdal. Do you mean Heimdal is not complete at using the types? Same below. Thanks, Max > > - gssapi.h:gss_init_sec_context() > > @@ -403,100 +415,100 @@ > gss_cred_id_t * /* cred_handle */ > ); > > GSS_DLLIMP OM_uint32 gss_init_sec_context( > OM_uint32 *, /* minor_status */ > - gss_cred_id_t, /* claimant_cred_handle */ > + gss_const_cred_id_t, /* claimant_cred_handle */ > gss_ctx_id_t *, /* context_handle */ > - gss_name_t, /* target_name */ > - gss_OID, /* mech_type (used to be const) */ > + gss_const_name_t, /* target_name */ > ---->+ const gss_OID, /* mech_type (used to be const) */ > OM_uint32, /* req_flags */ > OM_uint32, /* time_req */ > - gss_channel_bindings_t, /* input_chan_bindings */ > - gss_buffer_t, /* input_token */ > ---->+ const gss_channel_bindings_t, /* input_chan_bindings */ > ---->+ const gss_buffer_t, /* input_token */ > gss_OID *, /* actual_mech_type */ > gss_buffer_t, /* output_token */ > OM_uint32 *, /* ret_flags */ > OM_uint32 * /* time_rec */ > ); > > These too need to be the correct gss_const_* types. > > I won't list all of these... > > - NativeFunc.h > > Same issues here. E.g., > > @@ -55,42 +55,42 @@ > (OM_uint32 *minor_status, > gss_name_t *name); > > typedef OM_uint32 (*IMPORT_NAME_FN_PTR) > (OM_uint32 *minor_status, > - gss_buffer_t input_name_buffer, > - gss_OID input_name_type, > ---->+ const gss_buffer_t input_name_buffer, > ---->+ const gss_OID input_name_type, > gss_name_t *output_name); > > Though you got many right too: > > typedef OM_uint32 (*COMPARE_NAME_FN_PTR) > (OM_uint32 *minor_status, > - gss_name_t name1, > - gss_name_t name2, > + gss_const_name_t name1, > + gss_const_name_t name2, > int *name_equal); > > Done. > > This looks much better. Just a bit more work! > > Nico > -- From xuelei.fan at oracle.com Wed Mar 20 03:47:04 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Mar 2019 20:47:04 -0700 Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy In-Reply-To: References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com> Message-ID: Hi, I extended this CSR to cover more update, and update per the comments. Please let me know your concerns by the end of March 21, 2019. Thanks, Xuelei On 3/6/2019 3:41 PM, Bernd Eckenfels wrote: > I am not clear on what would ?preferred in current default context? > mean. Does that mean it preferred the PFS ciphers anyway.. for suggested > order in client handshake? as server? And what would be the non-Default > context. Is this ?TLS? context? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Sean Mullan > *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM > *An:* security-dev at openjdk.java.net > *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled > cipher suites should prefer forward secrecy > Hi Xuelei, > > In the Specification section, I think it would be useful to note which > cipher suites are forward secret and which are not. Otherwise, it is > difficult to see what has changed, since there are so many supported > suites. Perhaps in parentheses, ex: > > TLS_AES_128_GCM_SHA256 (forward secret) > ... > > I also think you should summarize what has changed or what is roughly > the new order, for example: > > - The TLS_RSA suites have moved down ... > - The TLS_ECDH suites have moved > - The SSL_RSA suites have moved down ... > etc... > > --Sean > > On 2/21/19 4:45 PM, Xuelei Fan wrote: > > Hi, > > > > Could I get the CSR reviewed? > > ??? https://bugs.openjdk.java.net/browse/JDK-8219545 > > > > It is proposed to increase the priority of forward secrecy cipher > > suites, and decrease the priority of RSA key exchange based cipher > > suites for the default enabled cipher suites in the SunJSSE provider. > > > > Thanks, > > Xuelei From ecki at zusammenkunft.net Wed Mar 20 07:34:22 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 20 Mar 2019 07:34:22 +0000 Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy In-Reply-To: References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com> , Message-ID: Good to understand now. Do you want to add a sentence how devs&ops can change the order (I.e. enabling the ciphers in a different order?) Just to be clear, In the Risk Evaluation the ?should have been used? does mean JDK should have done this before, it does not mean it has used the preference before, right? (Although in practice I guess especially DHE have been prefered over RSA by peers often) The main risk of the change to me seems to be: priotizing DHE over plain DSS/RSA. As this increases the likelyhood for DHE related interop problems (due to lack of negotiation of ?group? sizes). I suspect two aspects reduce the risk, but maybe it should be mentioned explicitely: ?Preference of DHE_RSA over RSA could increase group/size related interoperability problems. However it is expected that this is mitigated by the additional DHE parameters (FFDHE) in group announcement and also the fact that existing implementations have been confronted with bigger DHE keys for some time now. Besides many existing servers prefer ECDHE or would have picked DHE over RSA anyway.? I would expect no performance impact as most modern/perfcritical systems would use ECDHE already (and the perf impact of preferring GCM over CBC is a different discussion) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Mittwoch, M?rz 20, 2019 6:19 AM An: security-dev at openjdk.java.net Betreff: Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy Hi, I extended this CSR to cover more update, and update per the comments. Please let me know your concerns by the end of March 21, 2019. Thanks, Xuelei On 3/6/2019 3:41 PM, Bernd Eckenfels wrote: > I am not clear on what would ?preferred in current default context? > mean. Does that mean it preferred the PFS ciphers anyway.. for suggested > order in client handshake? as server? And what would be the non-Default > context. Is this ?TLS? context? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Sean Mullan > *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM > *An:* security-dev at openjdk.java.net > *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled > cipher suites should prefer forward secrecy > Hi Xuelei, > > In the Specification section, I think it would be useful to note which > cipher suites are forward secret and which are not. Otherwise, it is > difficult to see what has changed, since there are so many supported > suites. Perhaps in parentheses, ex: > > TLS_AES_128_GCM_SHA256 (forward secret) > ... > > I also think you should summarize what has changed or what is roughly > the new order, for example: > > - The TLS_RSA suites have moved down ... > - The TLS_ECDH suites have moved > - The SSL_RSA suites have moved down ... > etc... > > --Sean > > On 2/21/19 4:45 PM, Xuelei Fan wrote: > > Hi, > > > > Could I get the CSR reviewed? > > https://bugs.openjdk.java.net/browse/JDK-8219545 > > > > It is proposed to increase the priority of forward secrecy cipher > > suites, and decrease the priority of RSA key exchange based cipher > > suites for the default enabled cipher suites in the SunJSSE provider. > > > > Thanks, > > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Mar 20 15:38:03 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Mar 2019 08:38:03 -0700 Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy In-Reply-To: References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com> Message-ID: H Bernd, Thank you for the quick review. All good points! On 3/20/2019 12:34 AM, Bernd Eckenfels wrote: > Good to understand now. > > Do you want to add a sentence how devs&ops can change the order (I.e. > enabling the ciphers in a different order?) > In the JSSE Reference Guide, there are sections talking about cipher suite preference. I will add a note in the release-note about how to customize the preference. > Just to be clear, In the Risk Evaluation the ?should have been used? > does mean JDK should have done this before, it does not mean it has used > the preference before, right? (Although in practice I guess especially > DHE have been prefered over RSA by peers often) > Right. > The main risk of the change to me seems to be: priotizing DHE over plain > DSS/RSA. As this increases the likelyhood for DHE related interop > problems (due to lack of negotiation of ?group? sizes). > > I suspect two aspects reduce the risk, but maybe it should be mentioned > explicitely: > > ?Preference of DHE_RSA over RSA could increase group/size related > interoperability problems. However it is expected that this is mitigated > by the additional DHE parameters (FFDHE) in group announcement and also > the fact that existing implementations have been confronted with bigger > DHE keys for some time now. Besides many existing servers prefer ECDHE > or would have picked DHE over RSA anyway.? > It makes sense to me. I added to the "Compatibility Risk Description" field. Considering the existing DHE problems, it may be nice to decrease the priority of DHE cipher suites as well. I update the CSR accordingly. > I would expect no performance impact as most modern/perfcritical systems > would use ECDHE already (and the perf impact of preferring GCM over CBC > is a different discussion) > Agreed, I think the performance impact is minimal as well. Thanks, Xuelei > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Xuelei Fan > *Gesendet:* Mittwoch, M?rz 20, 2019 6:19 AM > *An:* security-dev at openjdk.java.net > *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled > cipher suites should prefer forward secrecy > Hi, > > I extended this CSR to cover more update, and update per the comments. > Please let me know your concerns by the end of March 21, 2019. > > Thanks, > Xuelei > > On 3/6/2019 3:41 PM, Bernd Eckenfels wrote: > > I am not clear on what would ?preferred in current default context? > > mean. Does that mean it preferred the PFS ciphers anyway.. for suggested > > order in client handshake? as server? And what would be the non-Default > > context. Is this ?TLS? context? > > > > Gruss > > Bernd > > -- > > http://bernd.eckenfels.net > > ------------------------------------------------------------------------ > > *Von:* security-dev im Auftrag > > von Sean Mullan > > *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM > > *An:* security-dev at openjdk.java.net > > *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled > > cipher suites should prefer forward secrecy > > Hi Xuelei, > > > > In the Specification section, I think it would be useful to note which > > cipher suites are forward secret and which are not. Otherwise, it is > > difficult to see what has changed, since there are so many supported > > suites. Perhaps in parentheses, ex: > > > > TLS_AES_128_GCM_SHA256 (forward secret) > > ... > > > > I also think you should summarize what has changed or what is roughly > > the new order, for example: > > > > - The TLS_RSA suites have moved down ... > > - The TLS_ECDH suites have moved > > - The SSL_RSA suites have moved down ... > > etc... > > > > --Sean > > > > On 2/21/19 4:45 PM, Xuelei Fan wrote: > > > Hi, > > > > > > Could I get the CSR reviewed? > > > ??? https://bugs.openjdk.java.net/browse/JDK-8219545 > > > > > > It is proposed to increase the priority of forward secrecy cipher > > > suites, and decrease the priority of RSA key exchange based cipher > > > suites for the default enabled cipher suites in the SunJSSE provider. > > > > > > Thanks, > > > Xuelei From Nico.Williams at twosigma.com Wed Mar 20 16:10:23 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 20 Mar 2019 16:10:23 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20181204203436.GA22527@twosigma.com> <20181206184824.GB22527@twosigma.com> <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> Message-ID: <20190320161023.GD9177@twosigma.com> On Wed, Mar 20, 2019 at 10:20:28AM +0800, Weijun Wang wrote: > New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and interdiff at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html Thanks. I'll take a look. > I'll think more about secondsUntil() and getTGTEndTime(). Other comments below. > > > - sspi.cpp:61 > > > > 61 #define SEC_SUCCESS(status) (*minor_status = status, (status) >= SEC_E_OK) > > ^^^^^^^^^^^^^^^^^^^^^^ > > > > Please add parenthesis around the whole assignment expression. > > OK, but what kind of bad things could happen? First, there's a matter of hygiene: you need to parenthesize `status`, and you do in the second part but not the first. Second, assignments in if statements need to be parenthesized to avoid compiler warnings -- and this one is parenthesized, but who knows if a compiler might be confused by the comma operator and emit a warning anyways. > > - sspi.cpp:NewContext() > > > > Please fully-initialize all fields of the allocated context structure before > > returning it. > > Some of them are of struct types, do I need to go inside and set each to zero? Or ZeroMemory the whole struct? C does not guarantee that (void*)0 is an all-bits-zero pattern, but I imagine all the supported Windows platforms do (certainly x86 and x86_64). So ZeroMemory will do. For more portable code you should ZeroMemory the struct then manually assign all the pointer values. > > - sspi.cpp:flagSspi2Gss() and flagGss2Sspi() > > > > I realize that this would be a change to the Java bindings, so this is just > > a note, but, we should add support for GSS_C_DELEG_POLICY_FLAG. > > How? Always set it with GSS_C_DELEG_FLAG? No, we'd have to add the Java bindings too. Forget this request. > > - sspi.cpp:getTGTEndTime() > > > > Please immediately write to the `endTime' output parameter upon entry. > > Are you afraid of garbages for "return 1"s? But I won't touch the parameter at all in this case. Yes. It's just defensive programming. > > - sspi.cpp:315 > > > > 314 // input has realm, no need to add one > > 315 if (wcschr(input, '@')) { > > > > This is not going to work with UPNs. > > Why not? I just want to find out if there is already a realm. UPNs are of the form name\@domain at REALM. You're not checking for `\@`. You can't search for `@` backwards either because realm names can actually have `\@` as well in them. > > You should probably implement proper > > RFC1864 name format support, including backslash-quoting. > > Ahh... Right :) > > - sspi.cpp:315 > > > > 315 if (wcschr(input, '@')) { > > ^ > > > > I don't know if it is necessary that this be L'@' or if the compiler will do > > the right thing because the `wc' argument of `wcschr()' is a `wchar_t'. > > > > Elsewhere you do use wide character literals, so I assume even if type > > promotion works correctly for char->WCHAR (does it?) you might want to be > > consistent. > > I'll made them all L'@'. Or stop using wchar_t... :) > > wchar_t/WCHAR is cancer. > > > > I worry that adding any more wchar_t-using code makes worse the legacy > > cleanup as Windows starts to prefer UTF-8. But whatever. > > > > - sspi.cpp:351 > > > > 351 wcscpy_s(fullname + oldlen + 1, wcslen(realm) + 1, realm); > > > > It would be safer to use wcscat_s(). > > How is this unsafe? If using wcscat_s(), I'll need to add a '\0' after the '@' first. You wouldn't have to compute the offset to copy at. I call that safer. > > - sspi.cpp:362 > > > > 362 #define CHECK_OUTPUT(x) if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; > > > > I would much prefer the more standard and safer do { ... } while (0) > > construction: > > > > 362 #define CHECK_OUTPUT(x) \ > > do { if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; } while (0) > > I can do that, but why is this safer? You don't have to worry about this if (something) CHECK_OUTPUT(out_arg); --->else other stuff That `else` will bind to the `if` that `CHECK_OUTPUT()` expands into. > You mean there is actually no need to check the arguments? No, I mean that they don't save that much work. > > - sspi.cpp:527 > > > > 527 int len = (int)wcslen(fullname); > > > > You don't need that cast. > > There was a warning. Yes, but see the comments that followed: > > But you should check first that `wcslen()' did > > not return a value larger than `INT_MAX'. > > > > You only even need an `int len' because `WideCharToMultiByte()' returns > > `int'... > > > > I'd write this like: > > > > 527 int len; > > size_t namelen = wcslen(fullname); > > if (namelen > 255) > > goto err; > > // 04 01 00 ** 06 ** OID len:int32 name > > // ... > > // > > - sspi.cpp:532,574 > > > > You can't assume the length of a multi-byte string will be the same number > > of `char' as the number of `wchar_t' in the wide-char version of the string. > > > > Determinining the correct length is a bit tricky, though since we should be > > converting to UTF-8 (see above), you can assume that 4x is enough, use > > 4*len for the buffer allocation, then take the correct length from > > WideCharToMultiByte(). > > OK. (And even this assumes that we Windows won't do normalization on the string, though if they normalize to NFC, I think the number of codepoints can't go up.) > > - sspi.cpp:607 > > > > 606 TimeStamp ts; > > 607 ts.QuadPart = 0; > > > > Huh? TimeStamp is a typedef of SECURITY_INTEGER, and SECURITY_INTEGER is a > > struct of the same shape and size as FILETIME, and has no QuadPart field. > > > > What am I missing? > > It compiles. I think it's a union of one Quad or two DWORD. Ok. > > - sspi.cpp:954 > > > > Should you check if there's an output token before doing this: > > > > 954 ss = CompleteAuthToken(&pc->hCtxt, &outBuffDesc); > > > > ? > > Does this matter? Do you think CompleteAuthToken cannot deal with no token? Hmm, probably not. > > - sspi.cpp:874 and others > > > > delete `output_token->value' and set it to NULL (and the length to 0) before > > returning errors after 865. > > OK. Is this just a good habit or do you know someone using it even at a failure? It's perfectly safe to gss_release_buffer() after a failure. After all, the failure might involve an error token. > > - sspi.cpp:878,962-963 > > > > The local variable `pfDone' is set but not used. Drop it. > > OK, > > > > > (The compiler should have warned about this, no?) > > No. Why not. > > - sspi.cpp:964-966 > > > > Change this: > > > > 964 outFlag = flagSspi2Gss(outFlag); > > 965 > > 966 *ret_flags = (OM_uint32)outFlag; > > > > to: > > > > 964 *ret_flags = flagSspi2Gss(outFlag); > > > > You don't use outFlag again. Setting it to a different kind of set of flags > > seems like a trap for someone to fall into in the future. > > Good. Huh? > > - sspi.cpp:948 > > > > 948 if (!SEC_SUCCESS(ss)) { > > 949 return GSS_S_FAILURE; > > 950 } > > 951 > > 952 if ((SEC_I_COMPLETE_NEEDED == ss) > > 953 || (SEC_I_COMPLETE_AND_CONTINUE == ss)) { > > > > I can't find documentation on SEC_SUCCES(). I don't know if it treats > > SEC_I_COMPLETE_NEEDED as an error or not... I gues it must not. Can you > > confirm? > > Not an error. I defined SEC_SUCCESS in this file. Oy, sorry! > > - sspi.cpp:1002 > > > > It should be simple now to implement this... > > > > 1002 PP(">>>> Calling UNIMPLEMENTED gss_accept_sec_context..."); > > 1003 return GSS_S_FAILURE; > > Not our goal this time, and I don't know how to test. Does server on Windows only run as services? Do we have servers that run on Windows? I think we do. Our shim (forked from SAP's) works for us. > > - gssapi.h:gss_acquire_cred() > > > > @@ -387,13 +399,13 @@ > > > > /* Function Prototypes */ > > > > GSS_DLLIMP OM_uint32 gss_acquire_cred( > > OM_uint32 *, /* minor_status */ > > - gss_name_t, /* desired_name */ > > + gss_const_name_t, /* desired_name */ > > OM_uint32, /* time_req */ > > - gss_OID_set, /* desired_mechs */ > > ---->+ const gss_OID_set, /* desired_mechs */ > > gss_cred_usage_t, /* cred_usage */ > > gss_cred_id_t *, /* output_cred_handle */ > > gss_OID_set *, /* actual_mechs */ > > OM_uint32 * /* time_rec */ > > ); > > > > That needs to be `gss_const_OID_set', not `const gss_OID_set'. > > > > There's a number of these. Just search for "const gss_" -- any time you see > > that in a function prototype, it's wrong. > > I think I copied all of them from Heimdal. Do you mean Heimdal is not complete at using the types? Yes. Thanks for noticing. I'll fix it. Nico -- From adam.petcher at oracle.com Wed Mar 20 18:32:49 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 20 Mar 2019 11:32:49 -0700 (PDT) Subject: RFR 8221172: SunEC specific test is not limited to SunEC Message-ID: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com> The regression test I added for JDK-8147502[1] has a minor bug. The test only works for SunEC, so the calls to getInstance should specify SunEC as the provider. Please review the fix for this test bug---it should only take a moment. Webrev: http://cr.openjdk.java.net/~apetcher/8221172/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8221172 [1] https://bugs.openjdk.java.net/browse/JDK-8147502 From sean.mullan at oracle.com Wed Mar 20 19:45:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Mar 2019 15:45:24 -0400 Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider In-Reply-To: References: Message-ID: Please add a noreg-self label to the bug since it is a test only fix. --Sean On 3/19/19 11:51 AM, Xuelei Fan wrote: > Hi Martin, > > In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" > should be disabled in the test case?? It may help for further update if > RSASSA-PSS get supported in the SunPKCS11 provider in the future. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > On 3/16/2019 12:52 PM, Martin Balao wrote: >> Hi, >> >> Can I have a review for JDK-8220753 [1]? >> >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/ >> >> The test is almost identical to the previous one [2], with a few changes >> in the "initialize" function (so it does not depend on the removed >> SunJSSE FIPS feature anymore). >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8220753 >> [2] - >> http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java >> >> From sean.mullan at oracle.com Wed Mar 20 19:59:49 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Mar 2019 15:59:49 -0400 Subject: RFR 8221172: SunEC specific test is not limited to SunEC In-Reply-To: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com> References: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com> Message-ID: <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com> Looks fine to me. --Sean On 3/20/19 2:32 PM, Adam Petcher wrote: > The regression test I added for JDK-8147502[1] has a minor bug. The test > only works for SunEC, so the calls to getInstance should specify SunEC > as the provider. Please review the fix for this test bug---it should > only take a moment. > > Webrev: http://cr.openjdk.java.net/~apetcher/8221172/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8221172 > > [1] https://bugs.openjdk.java.net/browse/JDK-8147502 > From sean.mullan at oracle.com Wed Mar 20 20:00:32 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Mar 2019 16:00:32 -0400 Subject: RFR 8221172: SunEC specific test is not limited to SunEC In-Reply-To: <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com> References: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com> <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com> Message-ID: <09985a80-6e38-6d39-dfe6-be8c21ea38e0@oracle.com> Just don't forget to add a noreg-self label to the bug... --Sean On 3/20/19 3:59 PM, Sean Mullan wrote: > Looks fine to me. > > --Sean > > On 3/20/19 2:32 PM, Adam Petcher wrote: >> The regression test I added for JDK-8147502[1] has a minor bug. The >> test only works for SunEC, so the calls to getInstance should specify >> SunEC as the provider. Please review the fix for this test bug---it >> should only take a moment. >> >> Webrev: http://cr.openjdk.java.net/~apetcher/8221172/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8221172 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8147502 >> From Nico.Williams at twosigma.com Wed Mar 20 21:26:26 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 20 Mar 2019 21:26:26 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> Message-ID: <20190320212626.GE9177@twosigma.com> On Wed, Mar 06, 2019 at 10:24:50AM +0800, Weijun Wang wrote: > Tell me the title and description of the bug/RFE, and I'll create one like > https://bugs.openjdk.java.net/browse/JDK-8212217. Thanks. All the commit subject lines work as bug synopses (when they differ, the commit subject is in parenthesis below proposed synopsis): - (bug) Add missing dbgsysGetLastErrorString() dbgsys*() are wrappers around dlopen() (Unix) / LoadLibrary() (Windows). A binding for dlerror() was missing. - (bug) cut/paste error in NativeUtil.c (Fix cut/paste error in NativeUtil.c) - (RFE) Cleanup error handling in GSSLibStub (Fix error handling in GSSLibStub) - (RFE) Need a String to gss_buffer_t conversion utility (Implement String to gss_buffer_t import) - (bug) GSS_S_FAILURE major status lost in importContext (Fix loss of GSS_S_FAILURE major status in importContext) - (bug) GSSNameElement constructor needs actual mechanism input (Add actual mechanism to native GSSNameElement state) - (RFE) Add getLocalName() GSSName method - (RFE) Add createCredential() with password - JDK-8212217 (exists) - (bug) SpNego multi-round-trip bug (Fix SpNego multi-round-trip bug) - (RFE) ServicePermission empty realm support - (bug) GSSCredentialSpineeds isDefaultCredential() method (Add isDefaultCredential() method to GSSCredentialSpi) - (bug) Prefer default cred handles if possible (JGSS: Prefer default cred handles if possible) - (bug) GSSName should extend Principal (Make GSSName implement Principal (add getName())) This is the key bug. Without this a GSSName backed by the native C GSS-API library cannot be used with JAAS. Note that GSS name objects conceptually *are* principals. The base RFCs, 2743 and 2744, both refer to them as such. A GSSName is notionally no different that a Krb5Principal, except as to implementation details. - (bug/RFE) Add GssLoginModule Naturally, Krb5LoginModule is not appropriate when using the native C GSS-API library. That makes the non-existence of GssLoginModule a bug when using the native C GSS-API library. Arguably, JAAS's continued existence in a world without applets is a bug! I would prefer JAAS be removed, but there is a great deal of cargo-culted JAAS-using application code out there that will not go away anytime soon, so at the very least stub classes and methods would have to stay behind. This commit adds a GssLoginModule that is almost a complete replacement for Krb5LoginModule. Missing functionality to make it a complete replacement of Krb5LoginModule: - kinit with key (maps to gss_acquire_cred_from()) - kinit with keytab (maps to gss_acquire_cred_from()) - (RFE) Krb5LoginModule cleanup - (bug) Output actual mechanism (fixup SEAM bug uncomments) - (bug) Memory leak in exception cases in getJavaOID() (Fix leak in exception cases in getJavaOID()) - (RFE) Simplify Krb5 context permissions checks (JGSS: Simplify context permissions checks) - (bug) Dispose of delegated cred handles early Like JDK-8212217. When a Java object has an associated C object, it's important to dispose() of the C object as soon as possible. The GC does not know there there is more memory pressure due to that C object. Java objects with unknown-to-the-GC C objects are icebergs. > You're an author now, right? You can post one yourself, webrev is at https://hg.openjdk.java.net/code-tools/webrev. OK, I'll figure that out. > > So Peter, for example, doesn't need to be a contributor? > > Anyone can reply, but to push the change, a formal openjdk reviewer is needed. OK, thanks. > If Peter rewrite the patch in total then he might need to sign the OCA. That will not be the case. > > Right, GitHub is sure a lot more convenient than webrevs. > > Hope so, but I do switch between the udiff, sdiff, frames and new > views of webrev a lot. It's not very friendly to comment of course. This could be fixed though. I'm surprised that webrev still doesn't have a comment facility all these years later. I left Sun (Oracle) in 2011 -- that webrev has hardly changed since it was created (when was that? I want to say it was around 2003) is a testament to its utility, but it is also surprising because writing code review comments in e-mail takes a lot more time than on a web page. Nico -- From weijun.wang at oracle.com Thu Mar 21 03:01:32 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 21 Mar 2019 11:01:32 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20190320212626.GE9177@twosigma.com> References: <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20190305185743.GA9177@twosigma.com> <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com> <20190306020946.GC9177@twosigma.com> <20190320212626.GE9177@twosigma.com> Message-ID: All of them at https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams You might want to add more descriptions. Thanks, Max From mbalao at redhat.com Thu Mar 21 04:24:13 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 Mar 2019 01:24:13 -0300 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> Message-ID: Hi Valerie, On 3/19/19 7:17 PM, Valerie Peng wrote: > > How about another potential problem - wrapper key may never get deleted? > If we don't have a good solution to addressing it, at least add a > comment about it? > Rest looks fine. > Thanks for your feedback. The Wrapper Key was never meant to be destroyed. However, it's a good idea and we should do it, in addition to fixing this bug. Here it's my proposal for getting rid of the Wrapper Key when it's no longer needed: Webrev 01: * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.01/ Please note that a few changes were required in SessionKeyRef objects lifetime. SessionKeyRef objects will live as long as their corresponding P11Key object lives -a similar scheme was implemented in the original patch-. This allows us to decrement Wrapper Key references -and eventually destroy it- while P11Key objects which don't have a native key created are deleted. In other words, objects that have wrapped native key information but don't have a native key alive can also decrement the Wrapper Key reference counter when deleted. Testing: * No regressions found in sun/security/pkcs11. * I've verified with the debugger all the new execution flows, including the deletion of a Wrapper Key. It would be a bit difficult to assert this from an automated test though. Kind regards, Martin.- From mbalao at redhat.com Thu Mar 21 05:16:40 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 Mar 2019 02:16:40 -0300 Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider In-Reply-To: References: Message-ID: Hi Xuelei, Thanks for your feedback. On 3/19/19 12:51 PM, Xuelei Fan wrote: > > In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" > should be disabled in the test case?? It may help for further update if > RSASSA-PSS get supported in the SunPKCS11 provider in the future. Sure. I've also added a similar comment explaining why we disable Extended Master Secret for this test. Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.01/ Are we good to go? Thanks, Martin.- From xuelei.fan at oracle.com Thu Mar 21 05:33:08 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Mar 2019 22:33:08 -0700 Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider In-Reply-To: References: Message-ID: <9e8d87a9-0e12-2b94-8804-3f7a5e4c23c1@oracle.com> Looks good to me. Thanks for adding the comments.. Thanks, Xuelei On 3/20/2019 10:16 PM, Martin Balao wrote: > Hi Xuelei, > > Thanks for your feedback. > > On 3/19/19 12:51 PM, Xuelei Fan wrote: >> >> In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" >> should be disabled in the test case?? It may help for further update if >> RSASSA-PSS get supported in the SunPKCS11 provider in the future. > > Sure. I've also added a similar comment explaining why we disable > Extended Master Secret for this test. > > Webrev.01: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.01/ > > Are we good to go? > > Thanks, > Martin.- > From christoph.langer at sap.com Thu Mar 21 10:20:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 21 Mar 2019 10:20:34 +0000 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? Message-ID: Hi, I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update? With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests. Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all? Just trying to start a discussion? ? Best regards Christoph [0] http://openjdk.java.net/jeps/319 [1] https://bugs.openjdk.java.net/browse/JDK-8189131 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Mar 21 14:43:41 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Mar 2019 10:43:41 -0400 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: On 3/15/19 5:46 AM, Steve Groeger wrote: > Hi all, > > Not sure whether something on this subject has been raised before but I > was unable to see anything in the mailing lists. I don't think it has been discussed in any detail on this alias. However, there are some other libraries and toolkits that allow OpenSSL to be used for the crypto or TLS/SSL with Java applications, so it is something that is not unreasonable to inquire about - i.e., whether it would be useful to include something like this in the JDK. > We have been looking at adding support to Java to use the OpenSSL > libraries as a JCE security provider if available on the system that a > Java application is being run on (or to build and bundle the OpenSSL > libraries with the JDK). > > If not found then the security drops back to using the built in security > that is part of the existing JDK. > > The use of the OpenSSL libraries can be disabled entirely or specific > algorithms can be disabled by use of command line options, > i.e. Djdk.nativeCrypto=true | false ?and ?-Djdk.nativeDigest=true | false > > Would this be something that might be useful to be contributed to OpenJDK. Not sure w/o more information, but from a followup reply, it doesn't seem to be a proper fit for the JDK since it is not a separate JCE provider. But, if we want to explore this further, I think it first makes sense to take a step back and focus more on what benefits an OpenSSL provider or "native bridge" would provide. I think you would have to make a strong case that the benefits outweigh the cost of maintaining a separate provider with additional code, etc. There are probably licensing issues as well that would need to be explored. Anyway, happy to explore that in more detail if you like. One suggestion is to use the JEP template [1] to provide more detail as it contains the type of information that would be useful to start this type of discussion. Thanks, Sean [1] https://openjdk.java.net/jeps/2 > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From simone.bordet at gmail.com Thu Mar 21 15:42:25 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 21 Mar 2019 16:42:25 +0100 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: Hi, On Thu, Mar 21, 2019 at 3:43 PM Sean Mullan wrote: > But, if we want to explore this further, I think it first makes sense to > take a step back and focus more on what benefits an OpenSSL provider or > "native bridge" would provide. Benchmarked 3x-10x performance improvements. https://nbsoftsolutions.com/blog/dropwizard-1-3-upcoming-tls-improvements I guess the memory allocation/footprint has similar improvements, with the JDK insisting at requiring ~17 KiB buffers to read HTTP requests in the order of <1 KiB. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Mar 21 18:49:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Mar 2019 11:49:11 -0700 Subject: RFR [13] JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl Message-ID: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com> Hi, Could I have the following update reviewed? http://cr.openjdk.java.net/~xuelei/8221270/webrev.00/ The implementation of SSLSocketImpl.getHandshakeSession() uses two synchronized over the same object. One should be sufficient. Code cleanup, no new regression test. Thanks, Xuelei From sean.mullan at oracle.com Thu Mar 21 19:18:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Mar 2019 15:18:24 -0400 Subject: RFR [13] JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl In-Reply-To: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com> References: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com> Message-ID: <6533c2a2-0de3-243b-dc3a-47d23b5ee375@oracle.com> Looks good. --Sean On 3/21/19 2:49 PM, Xuelei Fan wrote: > Hi, > > Could I have the following update reviewed? > > ?? http://cr.openjdk.java.net/~xuelei/8221270/webrev.00/ > > The implementation of SSLSocketImpl.getHandshakeSession() uses two > synchronized over the same object.? One should be sufficient. > > Code cleanup, no new regression test. > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Mar 21 19:27:22 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Mar 2019 12:27:22 -0700 Subject: RFR [13] JDK-8221273, sun/security/pkcs11/tls/tls12/TestTLS12.java on ProblemList.txt Message-ID: Hi, Please review this update to problem list sun/security/pkcs11/tls/tls12/TestTLS12.java, which is failing on windows. The issue will be addressed in JDK-8221271. Thanks, Xuelei $ hg diff test/jdk/ProblemList.txt diff -r f10ca228b22f test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Thu Mar 21 17:38:41 2019 +0000 +++ b/test/jdk/ProblemList.txt Thu Mar 21 12:24:51 2019 -0700 @@ -683,6 +683,7 @@ sun/security/pkcs11/tls/TestMasterSecret.java 8204203 windows-all sun/security/pkcs11/tls/TestPRF.java 8204203 windows-all sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all +sun/security/pkcs11/tls/tls12/TestTLS12.java 8221271 windows-all sun/security/tools/keytool/NssTest.java 8204203 windows-all From sean.mullan at oracle.com Thu Mar 21 19:32:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Mar 2019 15:32:24 -0400 Subject: RFR [13] JDK-8221273, sun/security/pkcs11/tls/tls12/TestTLS12.java on ProblemList.txt In-Reply-To: References: Message-ID: <384d3d5e-b4ae-703c-a1ce-03e0fc00f0dc@oracle.com> Looks good. --Sean On 3/21/19 3:27 PM, Xuelei Fan wrote: > Hi, > > Please review this update to problem list > sun/security/pkcs11/tls/tls12/TestTLS12.java, which is failing on > windows.? The issue will be addressed in JDK-8221271. > > Thanks, > Xuelei > > $ hg diff test/jdk/ProblemList.txt > diff -r f10ca228b22f test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Thu Mar 21 17:38:41 2019 +0000 > +++ b/test/jdk/ProblemList.txt? Thu Mar 21 12:24:51 2019 -0700 > @@ -683,6 +683,7 @@ > ?sun/security/pkcs11/tls/TestMasterSecret.java 8204203 windows-all > ?sun/security/pkcs11/tls/TestPRF.java 8204203 windows-all > ?sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all > +sun/security/pkcs11/tls/tls12/TestTLS12.java??????????????????? 8221271 > windows-all > ?sun/security/tools/keytool/NssTest.java 8204203 windows-all From 1983-01-06 at gmx.net Thu Mar 21 21:17:36 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 21 Mar 2019 22:17:36 +0100 Subject: RFR 6722928: Support SSPI as a native GSS-API provider Message-ID: Hi Max, here is my review based on webrev.04. Some of the statements might not be correct due to my little C/C++ knowledge, just correct me if I am wrong. I am really looking to test this, especially as a SASL provider for my extended LDAP communication with Active Directory. gssapi.h: * There are several unnecessary formatting (whitespace) changes in the prototypes sspi.cpp: * I don't like the inconsistent naming of functions: PascalCase, camelCase, snake_case. Is that on purpose? * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as it is intended to work. Means less code you have to maintain * Why do you redefine SEC_SUCCESS macro from sspi.h? * OID defs: shouldn't the char * be casted to void *? * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name. * showTime(): please use a readable format akin to %FT%T * NewContext(): ** why don't you just pass the package name as WCHAR pointer? There is no clear definition what happens if it is not SPNEGO w/o looking into the code ** If you log the token size you should also log if SecurityStatus isn't positive, just in case * flagSspi2Gss() and complement: please document that ANON_FLAG is not supported by SSPI * displayOID(): The function name is misleading. It claims to display an OID, but it doesn't. It displays a custom name It should be somewhat similar to gss_oid_to_str() shouldn't it? * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field? * get_full_name(): ** wcschr() doesn't it expect a L"string" as a second arg? ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com * gss_import_name(): ** BOOLEAN isNegotiate isn't really readable code ** I am a bit confused, Kerberos/GSS names should be UTF-8 encoded, but you do "new SEC_WCHAR[len + 1];" where len denotes the length of bytes and not chars. This might a minor one, but may allocate more memory than necessary ** CP_ACP: I'd expect CP_UTF8 here ** " value[len] = 0;" rather '\0'? ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function ** "if (value[len-1] == '@') {" you should comment this block and explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? ** SPN conversion, why do you replace the '@' with '/' explicitly for SSPI? A non-mech specific hostbased service is always neutral with '@' * gss_canonicalize_name(): something is fishy consider the following case: gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but get_full_name() doesn't do this * gss_export_name(): probably the same issues as with gss_import_name() * gss_display_name(): ** "char* buffer = new char[len+1];" you are changing sematics again. len is length of wide chars. If you have L"J?rg.Bj?rn at EXAMPLE.COM" it won't fit into buffer. ** CP_ACP: UTF8? * gss_acquire_cred(): ** Why again duplicate code, but only package name differs? ** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you populate it at all if we need default credentials only?! ** TGT time from CredHandle is huge, true. I believe it is that huge because LSA retains your password in memory so you will ALWAYS have a valid TGT compared to the MIT Kerberos approach. Shall we really care for that value? ** Can someone explain me for the stupid why there is pszPrincipal in AcquireCredentialsHandle if a user principal cannot have anything else and machine principals do not retain any local SPN longterm keys?! * gss_inquire_cred(): ** Why do you ignore cred_usage? You do support all three values in gss_acquire_cred() * gss_init_sec_conent(): ** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token for NewContext? ** Why do you already assign output_token length and value of nothing has yet happened and test for a NULL value? ** Same here with SEC_WINNT_AUTH_IDENTITY_EX Michael From weijun.wang at oracle.com Fri Mar 22 01:10:00 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 Mar 2019 09:10:00 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com> Hi Michael, Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and I write very little C code these days. > On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Hi Max, > > here is my review based on webrev.04. Some of the statements might not be correct due to my little C/C++ knowledge, just correct me if I am wrong. > > I am really looking to test this, especially as a SASL provider for my extended LDAP communication with Active Directory. > > gssapi.h: > * There are several unnecessary formatting (whitespace) changes in the prototypes I'll go thru all changes again. > sspi.cpp: > * I don't like the inconsistent naming of functions: PascalCase, camelCase, snake_case. Is that on purpose? The PascalCase should not exist. Now all GSS-API implementations use snake_case and other helper functions use camelCase. I assume that's because I've written too many Java methods. > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as it is intended to work. Means less code you have to maintain Java's GSS codes are not very good at using NTLM as a mechanism (the header, multi-round...). > * Why do you redefine SEC_SUCCESS macro from sspi.h? Oops, I didn't realized it's a redefinition. I'll change the name. Or, do you know if my definition is too different from the original one? > * OID defs: shouldn't the char * be casted to void *? No compiler warning, so I haven't added any cast. > * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name. How about only support "set KRB5_TRACE=/dev/stdout" now and be silent otherwise? > * showTime(): please use a readable format akin to %FT%T Sure. > * NewContext(): > ** why don't you just pass the package name as WCHAR pointer? There is no clear definition what happens if it is not SPNEGO w/o looking into the code OK I can do that. Only Negotiate and Kerberos are supported now... > ** If you log the token size you should also log if SecurityStatus isn't positive, just in case Many logs are actually used by myself while debugging. I don't have a list of what to show and what not. I'll see if this can be embedded into the SEC_SUCCESS macro. > * flagSspi2Gss() and complement: please document that ANON_FLAG is not supported by SSPI OK. > * displayOID(): The function name is misleading. It claims to display an OID, but it doesn't. It displays a custom name It should be somewhat similar to gss_oid_to_str() shouldn't it? The method is enough for my debugging purpose now. Unless there is a Windows function for that, I don't want to spend many time implementing that. I'm also afraid of C programming. > * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field? The field has a strange value. See https://stackoverflow.com/questions/11028798/how-do-i-interpret-the-expiry-returned-by-acquirecredentialshandle-kerberos > * get_full_name(): > ** wcschr() doesn't it expect a L"string" as a second arg? Will fix it. But currently seems the compiler does a i8 -> i16 promotion. > ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com Java does not support realm-less service name so I'll have to add one to make ServicePermission check working. In your case, is this a stopper? Can windows find out the correct realm even if I provide a false one? Or maybe I can give Java back the (possibly wrong) full name and remove it when passing to the windows API. > * gss_import_name(): I'll make quite some changes in this function. I'll also reject non-Kerberos exports. > ** BOOLEAN isNegotiate isn't really readable code > ** I am a bit confused, Kerberos/GSS names should be UTF-8 encoded, but you do "new SEC_WCHAR[len + 1];" where len denotes the length of bytes and not chars. > This might a minor one, but may allocate more memory than necessary > ** CP_ACP: I'd expect CP_UTF8 here Yes. > ** " value[len] = 0;" rather '\0'? > ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function > ** "if (value[len-1] == '@') {" you should comment this block and explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? > ** SPN conversion, why do you replace the '@' with '/' explicitly for SSPI? A non-mech specific hostbased service is always neutral with '@' > * gss_canonicalize_name(): something is fishy consider the following case: > gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but get_full_name() doesn't do this Ideally it should be realm-less, but... See above. > * gss_export_name(): probably the same issues as with gss_import_name() > * gss_display_name(): > ** "char* buffer = new char[len+1];" you are changing sematics again. len is length of wide chars. If you have L"J?rg.Bj?rn at EXAMPLE.COM" it won't fit into buffer. I'll x4 to be safe. > ** CP_ACP: UTF8? > * gss_acquire_cred(): > ** Why again duplicate code, but only package name differs? To produce different tokens I'll need different CredHandle. Since I only want to support 2 mechs here it's easy to just hardcode them. > ** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you populate it at all if we need default credentials only?! Please give me more detail. I only want to exclude NTLM here. > ** TGT time from CredHandle is huge, true. I believe it is that huge because LSA retains your password in memory so you will ALWAYS have a valid TGT compared to the MIT Kerberos approach. > Shall we really care for that value? What's your suggestion? > ** Can someone explain me for the stupid why there is pszPrincipal in AcquireCredentialsHandle if a user principal cannot have anything else and machine principals do not retain any local SPN longterm keys?! Maybe someone will call this function with a non-null name, and then I'll reject the one which is not myself. > * gss_inquire_cred(): > ** Why do you ignore cred_usage? You do support all three values in gss_acquire_cred() This first version of sspi.cpp only support the client side. > * gss_init_sec_conent(): > ** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token for NewContext? Is that more RFC compliant? > ** Why do you already assign output_token length and value of nothing has yet happened and test for a NULL value? Is there a way to let windows allocating it? > ** Same here with SEC_WINNT_AUTH_IDENTITY_EX To exclude NTLM. Thanks, Max > > Michael > From xuelei.fan at oracle.com Fri Mar 22 03:24:25 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Mar 2019 20:24:25 -0700 Subject: RFR [13] JDK-8168261: Use server cipher suites preference by default Message-ID: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com> Hi, Could I get the update reviewed? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/ With this update, server cipher suite preference will be used by default for TLS handshaking in the SunJSSE provider. For more details, please refer to CSR: https://bugs.openjdk.java.net/browse/JDK-8219657 Thanks, Xuelei From 1983-01-06 at gmx.net Fri Mar 22 09:28:24 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 22 Mar 2019 10:28:24 +0100 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com> References: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com> Message-ID: <07ec0ae4-c5e6-266a-e149-faa5868b4b45@gmx.net> Hi Max, Am 2019-03-22 um 02:10 schrieb Weijun Wang: > Hi Michael, > > Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and I write very little C code these days. > >> On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Hi Max, >> >> here is my review based on webrev.04. Some of the statements might not be correct due to my little C/C++ knowledge, just correct me if I am wrong. >> >> I am really looking to test this, especially as a SASL provider for my extended LDAP communication with Active Directory. > >> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as it is intended to work. Means less code you have to maintain > > Java's GSS codes are not very good at using NTLM as a mechanism (the header, multi-round...). Can you please elaborate why? The token content is opaque to the API and isEstablished() will fail unless type 3 token has been received. I'd use this as a change to improve JGSS regardless of NTLM. >> * Why do you redefine SEC_SUCCESS macro from sspi.h? > > Oops, I didn't realized it's a redefinition. I'll change the name. Or, do you know if my definition is too different from the original one? Here is sample code from Microsoft: https://docs.microsoft.com/en-us/windows/desktop/secauthn/using-sspi-with-a-windows-sockets-server I would not even bother adding it myself. What is the reason for this? >> * OID defs: shouldn't the char * be casted to void *? > > No compiler warning, so I haven't added any cast. Don't expect cl be a decent compiler. clang will give you one. Have a look at this const array: https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_generic.c#L38 Code hygiene. >> * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name. > > How about only support "set KRB5_TRACE=/dev/stdout" now and be silent otherwise? Hmm, I'd still insist on somthing else, it just doesn't feel right. Maybe JGSS_KRB5_TRACE with fprintf(stderr,...)? And later one you can imrpove/replace it? >> * NewContext(): >> ** why don't you just pass the package name as WCHAR pointer? There is no clear definition what happens if it is not SPNEGO w/o looking into the code > > OK I can do that. Only Negotiate and Kerberos are supported now... That is ok, if you signal unsupported mech. >> * displayOID(): The function name is misleading. It claims to display an OID, but it doesn't. It displays a custom name It should be somewhat similar to gss_oid_to_str() shouldn't it? > > The method is enough for my debugging purpose now. Unless there is a Windows function for that, I don't want to spend many time implementing that. I'm also afraid of C programming. I see. I am not aware of any Windows function because SSPI is at a higher level than GSS-API. The user does not interact with OIDs. Why not statically reserve a char array with OID strings? >> * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field? > > The field has a strange value. See > > https://stackoverflow.com/questions/11028798/how-do-i-interpret-the-expiry-returned-by-acquirecredentialshandle-kerberos Please see the third comment, it is from me. I have exprienced the same. To be frank, I would accept it as-is because that is the way LSA works. the way you do it now is as if you would use the internal KRB5 functions from MIT Kerberos. It doesn't feel right. >> * get_full_name(): >> ** wcschr() doesn't it expect a L"string" as a second arg? > > Will fix it. But currently seems the compiler does a i8 -> i16 promotion. I wouldn't really rely on that. Otherwise you should always work with _("string"). >> ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com > > Java does not support realm-less service name so I'll have to add one to make ServicePermission check working. In your case, is this a stopper? Can windows find out the correct realm even if I provide a false one? Or maybe I can give Java back the (possibly wrong) full name and remove it when passing to the windows API. Wait a second, don't you deduce the realm from the krb5.conf? I have been using JGSS for the past 10 years now and since referrals don't really work, I have used the domain_realm setion to solve that problem, e.g, blnn719x.ww004.siemens.net = AD001.SIEMENS.NET. If you are talking about domainbased services ldap at dc1.ad001.siemens.net@ad001.siemens.net Windows does support them, but there is no OID for, it uses UKNOWN or hostbased with three components. Windows does *not* require the realm with the SPN, unless for the usecase about specified, it will apply proper routing by itself if the namespaces are properly configured. We moved two years ago from one forest to another with a bidirectional trust and everything just work with referrals with MIT Kerberos and MS Kerberos. Maybe you need to provide an example to me to understand the JGSS shortcomings. >> * gss_import_name(): > > I'll make quite some changes in this function. I'll also reject non-Kerberos exports. OK, I will wait for the change. >> ** " value[len] = 0;" rather '\0'? >> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function >> ** "if (value[len-1] == '@') {" you should comment this block and explain why you are doing this. Is this because of "@ignore_me_rfcXXX"? >> ** SPN conversion, why do you replace the '@' with '/' explicitly for SSPI? A non-mech specific hostbased service is always neutral with '@' >> * gss_canonicalize_name(): something is fishy consider the following case: >> gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but get_full_name() doesn't do this > > Ideally it should be realm-less, but... See above. Same as above, it probably needs some example for me. >> ** CP_ACP: UTF8? >> * gss_acquire_cred(): >> ** Why again duplicate code, but only package name differs? > > To produce different tokens I'll need different CredHandle. Since I only want to support 2 mechs here it's easy to just hardcode them. I concur, all you need is the package name, the code remains the same. The out handle will have the appropriate dwLower, dwUpper to LSA to the mech. >> ** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you populate it at all if we need default credentials only?! > > Please give me more detail. I only want to exclude NTLM here. Strike that, I just reread the API. Everything is fine. Though, I think this shouldn't be necessary. >> ** TGT time from CredHandle is huge, true. I believe it is that huge because LSA retains your password in memory so you will ALWAYS have a valid TGT compared to the MIT Kerberos approach. >> Shall we really care for that value? > > What's your suggestion? I'd accept it as-is or truncate to year 9999 for ISO 8601 compliance. A note in the docs is sufficient about that fact. This binding has other semantics. >> ** Can someone explain me for the stupid why there is pszPrincipal in AcquireCredentialsHandle if a user principal cannot have anything else and machine principals do not retain any local SPN longterm keys?! > > Maybe someone will call this function with a non-null name, and then I'll reject the one which is not myself. So you are only thinking about a negative case? >> * gss_inquire_cred(): >> ** Why do you ignore cred_usage? You do support all three values in gss_acquire_cred() > > This first version of sspi.cpp only support the client side. You should then log at least that if usage is not initiator. >> * gss_init_sec_conent(): >> ** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token for NewContext? > > Is that more RFC compliant? This is my understanding of the NO_ macros in MIT Kerbros. See also the first hit: https://github.com/krb5/krb5/search?q=GSS_C_NO_CONTEXT&unscoped_q=GSS_C_NO_CONTEXT int initialContextToken = (*context_handle == GSS_C_NO_CONTEXT); I'd always use the NO_ macros for cleaner code. >> ** Why do you already assign output_token length and value of nothing has yet happened and test for a NULL value? > > Is there a way to let windows allocating it? Consider to evaluate: ISC_REQ_ALLOCATE_MEMORY. Frees your from the malloc() with the maxTokenSize from registry. Michael From xuelei.fan at oracle.com Fri Mar 22 14:51:48 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Mar 2019 07:51:48 -0700 Subject: RFR [13] JDK-8163326: Update the default enabled cipher suites preference Message-ID: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8163326/webrev.00/ With this update, the SunJSSE default enabled cipher suites preference is adjusted accordingly. For more details, please refer to CSR: https://bugs.openjdk.java.net/browse/JDK-8219545 Thanks, Xuelei From Nico.Williams at twosigma.com Fri Mar 22 15:28:24 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 22 Mar 2019 15:28:24 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <20190322152824.GF9177@twosigma.com> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as > it is intended to work. Means less code you have to maintain There's a few reasons: - NTLM doesn't have an OID, at least as I remember - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards to the ServicePermission stuff IMO JAAS (and with it, *Permission) should be removed with prejudice now that applet support has been removed. Perhaps stubs should be left behind for compatibility reasons, and all the doAs*() methods should just act as though permission is granted. Removing JAAS would be a wonderful simplification, then the JGSS stuff could stop being Kerberos-specific. Nico -- From 1983-01-06 at gmx.net Fri Mar 22 16:23:27 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 22 Mar 2019 17:23:27 +0100 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190322152824.GF9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> Message-ID: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> Am 2019-03-22 um 16:28 schrieb Nico Williams: > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: >> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as >> it is intended to work. Means less code you have to maintain > > There's a few reasons: > > - NTLM doesn't have an OID, at least as I remember I don't agree: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/e21c0b07-8662-41b7-8853-2b9184eab0db Heimdal uses it, look at a SPNEGO token from SSPI in Wireshark, you'll see it. > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > to the ServicePermission stuff Granted. > IMO JAAS (and with it, *Permission) should be removed with prejudice now > that applet support has been removed. Perhaps stubs should be left > behind for compatibility reasons, and all the doAs*() methods should > just act as though permission is granted. > > Removing JAAS would be a wonderful simplification, then the JGSS stuff > could stop being Kerberos-specific. Fully agree, it has been a pain in the last couple of years. This would also require an RFC update for the JGSS bindings to logon onto network with username/password or keytab w/o login modules. Michael From xuelei.fan at oracle.com Fri Mar 22 16:39:34 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Mar 2019 09:39:34 -0700 Subject: RFR [13] JDK-8218889: Improperly use of the Optional API Message-ID: Hi, Could I have the following update reviewed: http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/ In general Optional is a good option. However, Optional.ofNullable?(null).get() throws NoSuchElementException, as limit the benefits to use Optional.ofNullable?() for null object in the session management context. With this update, the Optional is replaced with other coding conventions. Code cleanup, no new regression test. Thanks, Xuelei From jamil.j.nimeh at oracle.com Fri Mar 22 16:41:59 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 22 Mar 2019 09:41:59 -0700 Subject: RFR [13] JDK-8218889: Improperly use of the Optional API In-Reply-To: References: Message-ID: <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com> This looks fine to me. --Jamil On 3/22/19 9:39 AM, Xuelei Fan wrote: > Hi, > > Could I have the following update reviewed: > ??? http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/ > > In general Optional is a good option.? However, > Optional.ofNullable?(null).get() throws NoSuchElementException, as > limit the benefits to use Optional.ofNullable?() for null object in > the session management context.?? With this update, the Optional is > replaced with other coding conventions. > > Code cleanup, no new regression test. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Fri Mar 22 17:40:22 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 22 Mar 2019 10:40:22 -0700 Subject: RFR [13] JDK-8218889: Improperly use of the Optional API In-Reply-To: <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com> References: <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com> Message-ID: <8247cad2-a56c-c0e9-3a8a-8d3119603b95@oracle.com> +1. I noticed this earlier while looking at my other work, and was wondering if this was a new style that I had missed. Thanks, Brad On 3/22/2019 9:41 AM, Jamil Nimeh wrote: > This looks fine to me. > > --Jamil > > On 3/22/19 9:39 AM, Xuelei Fan wrote: >> Hi, >> >> Could I have the following update reviewed: >> ??? http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/ >> >> In general Optional is a good option.? However, Optional.ofNullable? >> (null).get() throws NoSuchElementException, as limit the benefits to >> use Optional.ofNullable?() for null object in the session management >> context.?? With this update, the Optional is replaced with other >> coding conventions. >> >> Code cleanup, no new regression test. >> >> Thanks, >> Xuelei From Nico.Williams at twosigma.com Fri Mar 22 19:24:02 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 22 Mar 2019 19:24:02 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> Message-ID: <20190322192402.GG9177@twosigma.com> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote: > Am 2019-03-22 um 16:28 schrieb Nico Williams: > > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: > > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as > > > it is intended to work. Means less code you have to maintain > > > > There's a few reasons: > > > > - NTLM doesn't have an OID, at least as I remember > > I don't agree: > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/e21c0b07-8662-41b7-8853-2b9184eab0db Ah, good to know. > Heimdal uses it, look at a SPNEGO token from SSPI in Wireshark, you'll > see it. Then I should have known... lib/gssapi/mech/gss_oid.c:/* GSS_NTLM_MECHANISM - 1.3.6.1.4.1.311.2.2.10 */ lib/gssapi/oid.txt:oid base GSS_NTLM_MECHANISM 1.3.6.1.4.1.311.2.2.10 Nico -- From Nico.Williams at twosigma.com Fri Mar 22 19:29:06 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 22 Mar 2019 19:29:06 +0000 Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> Message-ID: <20190322192906.GH9177@twosigma.com> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote: > Am 2019-03-22 um 16:28 schrieb Nico Williams: > > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > > to the ServicePermission stuff > > Granted. :( > > IMO JAAS (and with it, *Permission) should be removed with prejudice now > > that applet support has been removed. Perhaps stubs should be left > > behind for compatibility reasons, and all the doAs*() methods should > > just act as though permission is granted. > > > > Removing JAAS would be a wonderful simplification, then the JGSS stuff > > could stop being Kerberos-specific. > > Fully agree, it has been a pain in the last couple of years. This would > also require an RFC update for the JGSS bindings to logon onto network > with username/password or keytab w/o login modules. Our contributions add acquireCredWithPassword() methods. And we could add acquireCredFrom() to match gss_acquire_cred_from() / gss_add_cred_from() (a Heimdal and MIT innovation that allows, among other things, to use a specific keytab). But also, most JGSS users don't need the JDK to have this functionality since using kinit externally and KRB5* env vars works perfectly fine for the vast majority of cases. Nico -- From sean.mullan at oracle.com Fri Mar 22 19:33:27 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 Mar 2019 15:33:27 -0400 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? In-Reply-To: References: Message-ID: Hi Christoph, On 3/21/19 6:20 AM, Langer, Christoph wrote: > Hi, > > I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update? > > With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests. > > Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all? I can answer the first two questions. I talked to one of our Product Managers who was involved with this JEP and he said that we have permission to release these certificates as open source at OpenJDK (much as Mozilla has roots in Firefox). Therefore there should be no concerns using with OpenJDK 8 or other versions for that matter. If you mean the jdk8u project specifically, you should check with the current maintainers for interest in this as I think they currently use other means for their builds. --Sean > > Just trying to start a discussion? ? > > Best regards > Christoph > > [0] http://openjdk.java.net/jeps/319 > [1] https://bugs.openjdk.java.net/browse/JDK-8189131 > From Nico.Williams at twosigma.com Fri Mar 22 19:43:46 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 22 Mar 2019 19:43:46 +0000 Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support SSPI as a native GSS-API provider) In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> Message-ID: <20190322194346.GI9177@twosigma.com> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote: > Am 2019-03-22 um 16:28 schrieb Nico Williams: > > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > > to the ServicePermission stuff > > Granted. > > > IMO JAAS (and with it, *Permission) should be removed with prejudice now > > that applet support has been removed. Perhaps stubs should be left > > behind for compatibility reasons, and all the doAs*() methods should > > just act as though permission is granted. > > > > Removing JAAS would be a wonderful simplification, then the JGSS stuff > > could stop being Kerberos-specific. > > Fully agree, it has been a pain in the last couple of years. This would > also require an RFC update for the JGSS bindings to logon onto network > with username/password or keytab w/o login modules. I replied separately about the kinit functionality of Krb5LoginModule. I want to call out the point that JAAS has no raison d'?tre in a world without applets. Even in a JVM multi-tenancy project (which I'm told there's continued desire for), while there may be uses for doAs() and doAsPrivileged(), those would be subtly but very different notions than in JAAS. Any JVM multi-tenancy project should either start from scratch, or if it will reuse JAAS classes, should clean up the mess that is ServicePermissions (and probably others). (I would also argue against JVM multi-tenancy.) IMO it would be better to remove JAAS altogether. All LoginModule functionality that is used to acquire credentials should be made available outside JAAS. E.g., JGSS could use kinit-style functionality (acquireCredWithPassword() and so on). "Could use", not "needs", because external use of kinit and KRB5* env vars works for 97% of cases, though being able to cover 100% is nice, and since I've done a lot of the necessary work (acquireCredWithPassword()), might as well do the rest (i.e., add acquireCredFrom()). It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult reasons (i.e., devs copy-pasting what [appears to] works for others), or else because the developers don't know how to use kinit externally. The Krb5 stack appears to be practically abandoned and far behind all other Kerberos implementations. With our JGSS contributions (and Max's SSPI bridge) there is also the opportunity to remove the Krb5 stack, which would lighten the development and maintenance burden on Oracle engineers, freeing up cycles for other, more interesting work. Nico -- From xuelei.fan at oracle.com Fri Mar 22 21:02:53 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Mar 2019 14:02:53 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 Message-ID: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8217610/webrev.00/ For EC key exchange in TLS connections, the private key should use the specified EC groups. The current code is calling ECPrivateKey.getParams(). However, the private key may be not an instance of ECPrivateKey, for example for non-extractable private key in the SunPKCS11 provider. To fix the tricky bug, in this update, if private key is an instance of ECPrivateKey, use it; otherwise, try to check the groups in the public key of the X.509 certificate bound to the private key. No hardware to reproduce the issue, and no new regression test. The update is straightforward. Please help to check the patch if you can play with a hardware token. Thanks, Xuelei From weijun.wang at oracle.com Fri Mar 22 23:21:24 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 Mar 2019 07:21:24 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190322152824.GF9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> Message-ID: <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> > On Mar 22, 2019, at 11:28 PM, Nico Williams wrote: > > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: >> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as >> it is intended to work. Means less code you have to maintain > > There's a few reasons: > > - NTLM doesn't have an OID, at least as I remember > > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > to the ServicePermission stuff Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated. --Max > > IMO JAAS (and with it, *Permission) should be removed with prejudice now > that applet support has been removed. Perhaps stubs should be left > behind for compatibility reasons, and all the doAs*() methods should > just act as though permission is granted. > > Removing JAAS would be a wonderful simplification, then the JGSS stuff > could stop being Kerberos-specific. > > Nico > -- From 1983-01-06 at gmx.net Fri Mar 22 23:50:34 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sat, 23 Mar 2019 00:50:34 +0100 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> Message-ID: Am 2019-03-23 um 00:21 schrieb Weijun Wang: > > >> On Mar 22, 2019, at 11:28 PM, Nico Williams wrote: >> >> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: >>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as >>> it is intended to work. Means less code you have to maintain >> >> There's a few reasons: >> >> - NTLM doesn't have an OID, at least as I remember >> >> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards >> to the ServicePermission stuff > > Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated. Reminds me of https://issues.apache.org/jira/browse/HTTPCLIENT-1625... From 1983-01-06 at gmx.net Sat Mar 23 00:03:17 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sat, 23 Mar 2019 01:03:17 +0100 Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190322192906.GH9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> <20190322192906.GH9177@twosigma.com> Message-ID: <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net> Am 2019-03-22 um 20:29 schrieb Nico Williams: > On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote: >> Am 2019-03-22 um 16:28 schrieb Nico Williams: >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards >>> to the ServicePermission stuff >> >> Granted. > > :( > >>> IMO JAAS (and with it, *Permission) should be removed with prejudice now >>> that applet support has been removed. Perhaps stubs should be left >>> behind for compatibility reasons, and all the doAs*() methods should >>> just act as though permission is granted. >>> >>> Removing JAAS would be a wonderful simplification, then the JGSS stuff >>> could stop being Kerberos-specific. >> >> Fully agree, it has been a pain in the last couple of years. This would >> also require an RFC update for the JGSS bindings to logon onto network >> with username/password or keytab w/o login modules. > > Our contributions add acquireCredWithPassword() methods. > > And we could add acquireCredFrom() to match gss_acquire_cred_from() / > gss_add_cred_from() (a Heimdal and MIT innovation that allows, among > other things, to use a specific keytab). Based on this: https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_ext.h That would be awesome. We have several use cases for keytabs: 1) traditional one, machine account with SPNs (acceptor, sometimes initiator) 2) service account (initiator) 3) service account with SPNs (both) That would make JAAS and the Krb5LoginModule completely obsolete. > But also, most JGSS users don't need the JDK to have this functionality > since using kinit externally and KRB5* env vars works perfectly fine for > the vast majority of cases. I see several cases not covered if MIT Kerberos is used: 1) # export KRB5_CLIENT_KTNAME=/etc/krb5.keytab # curl --negotiate -u : ...do magic... will simply not work with a keytab created by Samba because the machine UPN is not the first entry of the table. One would require KRB5_CLIENT_PRINCIPAL for that. It would cover gss_acquire_cred_from() with the gss_name_t. 2) non-file based ccaches cannot be accessed by Java ATM (e.g., keyring). 3) serialization of credentials to disk for futher usage (e.g., credetial delegation) 4) Consider you use MIT Kerberos via JGSS and receive a delegated credential via HTTP, you store that in the request (no session). There is no Servlet API callback that the request has been disposed, you cannot call GSSCredential#dispose(). It will or may lead to a memory leak. I don't know whether the GC will handle this. Frankly, I need to check mod_auth_gssapi how they solve that because that memory does not come from apr_pool_t. But I really would like to see https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions coming. Michael From 1983-01-06 at gmx.net Sat Mar 23 00:07:45 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sat, 23 Mar 2019 01:07:45 +0100 Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support SSPI as a native GSS-API provider) In-Reply-To: <20190322194346.GI9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> <20190322194346.GI9177@twosigma.com> Message-ID: <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net> Am 2019-03-22 um 20:43 schrieb Nico Williams: > On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote: >> Am 2019-03-22 um 16:28 schrieb Nico Williams: >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards >>> to the ServicePermission stuff >> >> Granted. >> >>> IMO JAAS (and with it, *Permission) should be removed with prejudice now >>> that applet support has been removed. Perhaps stubs should be left >>> behind for compatibility reasons, and all the doAs*() methods should >>> just act as though permission is granted. >>> >>> Removing JAAS would be a wonderful simplification, then the JGSS stuff >>> could stop being Kerberos-specific. >> >> Fully agree, it has been a pain in the last couple of years. This would >> also require an RFC update for the JGSS bindings to logon onto network >> with username/password or keytab w/o login modules. > > I replied separately about the kinit functionality of Krb5LoginModule. > > I want to call out the point that JAAS has no raison d'?tre in a world > without applets. > > Even in a JVM multi-tenancy project (which I'm told there's continued > desire for), while there may be uses for doAs() and doAsPrivileged(), > those would be subtly but very different notions than in JAAS. Any JVM > multi-tenancy project should either start from scratch, or if it will > reuse JAAS classes, should clean up the mess that is ServicePermissions > (and probably others). (I would also argue against JVM multi-tenancy.) > > IMO it would be better to remove JAAS altogether. > > All LoginModule functionality that is used to acquire credentials should > be made available outside JAAS. E.g., JGSS could use kinit-style > functionality (acquireCredWithPassword() and so on). "Could use", not > "needs", because external use of kinit and KRB5* env vars works for 97% > of cases, though being able to cover 100% is nice, and since I've done a > lot of the necessary work (acquireCredWithPassword()), might as well do > the rest (i.e., add acquireCredFrom()). acquireCredFrom() is a must have for multi-tenancy and services. Think of TLS virtual hosting with one keytab per host on a Tomcat. > It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult > reasons (i.e., devs copy-pasting what [appears to] works for others), or > else because the developers don't know how to use kinit externally. > > The Krb5 stack appears to be practically abandoned and far behind all > other Kerberos implementations. With our JGSS contributions (and Max's > SSPI bridge) there is also the opportunity to remove the Krb5 stack, > which would lighten the development and maintenance burden on Oracle > engineers, freeing up cycles for other, more interesting work. That is true, but it would require to have a very good coverage via SSPI or MIT Kerberos on all platforms where Java runs, not just those Oracle officially supports. I do use the same code one four operating systems with Java. Michael From david.lloyd at redhat.com Sat Mar 23 15:45:34 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Sat, 23 Mar 2019 10:45:34 -0500 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190322152824.GF9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> Message-ID: On Fri, Mar 22, 2019 at 10:29 AM Nico Williams wrote: > > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as > > it is intended to work. Means less code you have to maintain > > There's a few reasons: > > - NTLM doesn't have an OID, at least as I remember > > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > to the ServicePermission stuff > > IMO JAAS (and with it, *Permission) should be removed with prejudice now > that applet support has been removed. Perhaps stubs should be left > behind for compatibility reasons, and all the doAs*() methods should > just act as though permission is granted. I assume that you mean SecurityManager and AccessController as well (which are not a part of JAAS AFAIK)? -- - DML From andimullaraj at gmail.com Sun Mar 24 03:04:55 2019 From: andimullaraj at gmail.com (Andi Mullaraj) Date: Sat, 23 Mar 2019 20:04:55 -0700 Subject: Java SSLSocketChannel/SSLSelector? In-Reply-To: References: Message-ID: Thank you Alan, I am in awe! If Loom delivers on its promises I see no point continuing this (or any blocking/async/io) discussion. I think I will open source my implementation. Thanks to all for the feedback, Best, --Andi On Mon, Mar 11, 2019 at 12:58 AM Alan Bateman wrote: > On 09/03/2019 09:35, Andi Mullaraj wrote: > > > In light of the previous point, I couldn't disagree more. As it is > painfully clear, the proposed approach stays within the confines of nio, > and no duplication is needed (I also hate duplication). > > This is a topic that was explored, and ruled out, in JSR-51 but lead to > SSLEngine. Yes, SSLEngine has pain points and performance issues and I > think it would be better to focus on those issues and see how SSLEngine > could be improved. This would be more beneficial for the eco system today > as most developers don't use SocketChannels or Selectors directly (those > APIs tend to be hidden by libraries and frameworks so most developers don't > see them). > > Also as a reminder is that we are exploring, in Project Loom, ways to make > it easy to develop simple blocking code that scales as well as code forced > to asynchronous frameworks today. If we get that right then it should > eliminate many of the reasons to create further asynchronous or > non-blocking APIs. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Sun Mar 24 20:38:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 24 Mar 2019 20:38:14 +0000 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? In-Reply-To: References: Message-ID: Hi Sean, > > Now my questions are: Is it legally possible to bring these root certificates > also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK > 8 via an update release? And, last but not least, would there be interest in > the community for that at all? > > I can answer the first two questions. I talked to one of our Product > Managers who was involved with this JEP and he said that we have > permission to release these certificates as open source at OpenJDK (much > as Mozilla has roots in Firefox). Therefore there should be no concerns > using with OpenJDK 8 or other versions for that matter. If you mean the > jdk8u project specifically, you should check with the current > maintainers for interest in this as I think they currently use other > means for their builds. Thank you for responding. So I'll check with the jdk8u project whether there's interest in this. Best regards Christoph From weijun.wang at oracle.com Mon Mar 25 02:42:10 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Mar 2019 10:42:10 +0800 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> Message-ID: <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> Ping again. No new test added. Thanks, Max > On Mar 5, 2019, at 11:06 AM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8157404/webrev.00/ > > When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes. > > A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases. > > Note this could block but it should only happen when data is not enough, and it only reads one byte. > > The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data. > > And I'm running a mach5 test job now. > > Thanks, > Max > From Nico.Williams at twosigma.com Mon Mar 25 02:52:49 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 25 Mar 2019 02:52:49 +0000 Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support SSPI as a native GSS-API provider) In-Reply-To: <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> <20190322194346.GI9177@twosigma.com> <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net> Message-ID: <20190325025249.GJ9177@twosigma.com> On Sat, Mar 23, 2019 at 01:07:45AM +0100, Michael Osipov wrote: > Am 2019-03-22 um 20:43 schrieb Nico Williams: > > All LoginModule functionality that is used to acquire credentials should > > be made available outside JAAS. E.g., JGSS could use kinit-style > > functionality (acquireCredWithPassword() and so on). "Could use", not > > "needs", because external use of kinit and KRB5* env vars works for 97% > > of cases, though being able to cover 100% is nice, and since I've done a > > lot of the necessary work (acquireCredWithPassword()), might as well do > > the rest (i.e., add acquireCredFrom()). > > acquireCredFrom() is a must have for multi-tenancy and services. Think of > TLS virtual hosting with one keytab per host on a Tomcat. I'm talking about multi-tenancy where you need isolation. If you mereley want multiple hostnames (and to dispatch on them), then on the server side you can always just check what name the initiator called the acceptor by, and that's good enough. (You have to put all the relevant keys in the same keytab.) If you need isolation, then you need acquireCredFrom() and an access control mechanism. > > It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult > > reasons (i.e., devs copy-pasting what [appears to] works for others), or > > else because the developers don't know how to use kinit externally. > > > > The Krb5 stack appears to be practically abandoned and far behind all > > other Kerberos implementations. With our JGSS contributions (and Max's > > SSPI bridge) there is also the opportunity to remove the Krb5 stack, > > which would lighten the development and maintenance burden on Oracle > > engineers, freeing up cycles for other, more interesting work. > > That is true, but it would require to have a very good coverage via SSPI or > MIT Kerberos on all platforms where Java runs, not just those Oracle > officially supports. I do use the same code one four operating systems with > Java. We use the Martin Rex's gsskrb5 GSS->SSPI bridge, with our own patches to it (mostly to remove code). This has a license that has an advertising clause, which is probably the only reason Oracle wouldn't accept it. You can find our fork here: https://github.com/twosigma/gsskrb5 It's missing channel binding support, and, of course, doesn't have some of the newer extensions, but it does work. One or both of Heimdal and MIT Kerberos work on all platforms that Java does, no? Though on Windows one really wants a GSS->SSPI bridge, even though Heimdal and MIT have some support for using the LSA as a credential store. Nico -- From Nico.Williams at twosigma.com Mon Mar 25 02:56:48 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 25 Mar 2019 02:56:48 +0000 Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net> References: <20190322152824.GF9177@twosigma.com> <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net> <20190322192906.GH9177@twosigma.com> <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net> Message-ID: <20190325025648.GK9177@twosigma.com> On Sat, Mar 23, 2019 at 01:03:17AM +0100, Michael Osipov wrote: > Am 2019-03-22 um 20:29 schrieb Nico Williams: > > Our contributions add acquireCredWithPassword() methods. > > > > And we could add acquireCredFrom() to match gss_acquire_cred_from() / > > gss_add_cred_from() (a Heimdal and MIT innovation that allows, among > > other things, to use a specific keytab). > > Based on this: > https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_ext.h > > That would be awesome. We have several use cases for keytabs: > > 1) traditional one, machine account with SPNs (acceptor, sometimes > initiator) > 2) service account (initiator) > 3) service account with SPNs (both) > > That would make JAAS and the Krb5LoginModule completely obsolete. Yes, that's the idea. > > But also, most JGSS users don't need the JDK to have this functionality > > since using kinit externally and KRB5* env vars works perfectly fine for > > the vast majority of cases. > > I see several cases not covered if MIT Kerberos is used: > > 1) > # export KRB5_CLIENT_KTNAME=/etc/krb5.keytab > # curl --negotiate -u : ...do magic... > > will simply not work with a keytab created by Samba because the machine > UPN is not the first entry of the table. One would require > KRB5_CLIENT_PRINCIPAL for that. It would cover gss_acquire_cred_from() > with the gss_name_t. You can set KRB5_CLIENT_KTNAME to deal with that. > 2) non-file based ccaches cannot be accessed by Java ATM (e.g., keyring). If you're using the JGSS native C JNI interface and MIT Kerberos (or the upcoming Heimdal 8.0), then you can use the Linux kernel keyring. > 3) serialization of credentials to disk for futher usage (e.g., > credetial delegation) This definitely requires JGSS bindings for gss_store_cred() and gss_store_cred_into(). > 4) Consider you use MIT Kerberos via JGSS and receive a delegated > credential via HTTP, you store that in the request (no session). There > is no Servlet API callback that the request has been disposed, you > cannot call GSSCredential#dispose(). It will or may lead to a memory > leak. I don't know whether the GC will handle this. Frankly, I need to > check mod_auth_gssapi how they solve that because that memory does not > come from apr_pool_t. At least our patches do let you dispose of it. > But I really would like to see > https://secure-web.cisco.com/1QDhZ_p9aOLNhO8eSoC7nft6Vay_RWeIFcEMzgJqDQfx-5XV1-ueeUw9GWNtzl_Hsj8Qqmlg9P3VX-LqydOZN2u2bqSJMC7w5TOPYv48kYSl5USixBe75-RKm9cgK2ZDYK2mqkX4b83Tud3TUffwL5SRkf-mpbHvE6YC5nANzW1Lwx0NB9AIsP2FhqBe9fp1KYXdYbknF2prfVcXKpUu81nnWnwfRhXr1Ror2TF75RRZbs-ON27jRx7Cm7LoxLmNJgDCi-AaB41hmGV9KUJKkEQ/https%3A%2F%2Fk5wiki.kerberos.org%2Fwiki%2FProjects%2FCredential_Store_extensions > coming. Yes. Direct link: https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions Nico -- From Nico.Williams at twosigma.com Mon Mar 25 02:58:03 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 25 Mar 2019 02:58:03 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20190322152824.GF9177@twosigma.com> Message-ID: <20190325025803.GL9177@twosigma.com> On Sat, Mar 23, 2019 at 10:45:34AM -0500, David Lloyd wrote: > On Fri, Mar 22, 2019 at 10:29 AM Nico Williams > wrote: > > > > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: > > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as > > > it is intended to work. Means less code you have to maintain > > > > There's a few reasons: > > > > - NTLM doesn't have an OID, at least as I remember > > > > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards > > to the ServicePermission stuff > > > > IMO JAAS (and with it, *Permission) should be removed with prejudice now > > that applet support has been removed. Perhaps stubs should be left > > behind for compatibility reasons, and all the doAs*() methods should > > just act as though permission is granted. > > I assume that you mean SecurityManager and AccessController as well > (which are not a part of JAAS AFAIK)? Anything that's only used for applets. From weijun.wang at oracle.com Mon Mar 25 03:17:17 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 Mar 2019 11:17:17 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> Message-ID: <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2019-03-23 um 00:21 schrieb Weijun Wang: >> >> >>> On Mar 22, 2019, at 11:28 PM, Nico Williams wrote: >>> >>> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: >>>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as >>>> it is intended to work. Means less code you have to maintain >>> >>> There's a few reasons: >>> >>> - NTLM doesn't have an OID, at least as I remember >>> >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards >>> to the ServicePermission stuff >> >> Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated. It works. Java's (old) HTTPConnection sends an NTLM token to IIS and after 4 messages I see 200 OK. But 1) Java GSS acceptor does not accept it and I don't want to break interop inside Java. 2) No more permission check. Not going to do it this time. Later I might ask networking how transparent NTLM works and if they needs any permission checking or other settings I can probably follow. I'll work on other comments from you. --Max > > Reminds me of https://issues.apache.org/jira/browse/HTTPCLIENT-1625... From thomas.stuefe at gmail.com Mon Mar 25 07:01:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 08:01:08 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: Hi David, (added net-dev, awt-dev, security-dev since part of these fixes are in their territory) On Mon, Mar 25, 2019 at 1:34 AM David Holmes wrote: > Hi Thomas, > > A few queries, comments and concerns ... > > On 25/03/2019 6:58 am, Thomas St?fe wrote: > > Hi all, > > > > After a long time I tried to build a Windows 32bit VM (VS2017) and > failed; > > I'm somewhat surprised as I thought someone was actively doing Windows > 32-bit builds out there, plus there are shared code changes that should > also have been caught by non-Windows 32-bit builds. :( > > Not sure what others do. I did a 32bit windows build, slowdebug, warning enabled, and it failed with those 5+ issues. > > multiple errors and warnings. Lets reverse the bitrot: > > > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > > > > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE > > callbacks), printf specifiers etc. > > > > Had to supress a warning in os_windows_x86.cpp - I was surprised by this > > since this did not look 32bit specifc, do we disable warnings on Windows > > 64bit builds? > > What version of VS2017? We use VS2017 15.9.6 and we don't disable warnings. > > I use VS2017 CE. Not sure which version spcifically, but my compiler is at Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86 > > The error I had in vmStructs.cpp was a bit weird: compiler complained > about > > an assignment of an enum value defined like this: > > > > hash_mask_in_place = (address_word)hash_mask << hash_shift > > > > to an uint64_t variable, complaining about narrowing. I did not find out > > what his problem was. In the end, I decided to add an explicit cast to > > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). > > Not at all sure that's the right fix. In markOop.hpp we see that value > gets special treatment on Windows-x64: > > #ifndef _WIN64 > ,hash_mask = right_n_bits(hash_bits), > hash_mask_in_place = (address_word)hash_mask << hash_shift > #endif > }; > > // Alignment of JavaThread pointers encoded in object header required > by biased locking > enum { biased_lock_alignment = 2 << (epoch_shift + epoch_bits) > }; > > #ifdef _WIN64 > // These values are too big for Win64 > const static uintptr_t hash_mask = right_n_bits(hash_bits); > const static uintptr_t hash_mask_in_place = > (address_word)hash_mask << hash_shift; > #endif > > perhaps something special is needed for Windows-x86. I'm unclear how the > values can be "too big" ?? > > I banged my head against this for an hour or so and I think this is a compiler bug. What I get is: warning C4838: conversion from '' to 'uint64_t' requires a narrowing conversion (Note the empty "from" string.) Here are my tries to provoke the error: VMLongConstantEntry iii[] = { { "hallo", markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place }; << but this succeeds uint64_t iii = markOopDesc::hash_mask_in_place; << this succeeds too I have no clue what this means. It is difficult to fix since the expression is hidden in such a macro pile. But I think either we go with my change or we disable the warning for win32 for the whole section. > > > > With this patch we can build with warnings enabled on 32bit and 64bit > > windows. > > > > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev > and > > core-libs-dev. > > Don't see anything that actually comes under core-libs-dev. Looks like > one net-dev, one awt-dev and one security-dev. Sorry. > > Okay, I will add them. > Cheers, > David > ----- > > Thanks for reviewing, Thomas > > Thanks, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Mar 25 07:17:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Mar 2019 17:17:05 +1000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> Message-ID: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com> Hi Thomas, On 25/03/2019 5:01 pm, Thomas St?fe wrote: > Hi David, > > (added net-dev, awt-dev, security-dev since part of these fixes are in > their territory) May be better to split up the reviews, cross-posting that many groups gets very messy given most people won't be subscribed to them all - myself included. > On Mon, Mar 25, 2019 at 1:34 AM David Holmes > wrote: > > Hi Thomas, > > A few queries, comments and concerns ... > > On 25/03/2019 6:58 am, Thomas St?fe wrote: > > Hi all, > > > > After a long time I tried to build a Windows 32bit VM (VS2017) > and failed; > > I'm somewhat surprised as I thought someone was actively doing Windows > 32-bit builds out there, plus there are shared code changes that should > also have been caught by non-Windows 32-bit builds. :( > > > Not sure what others?do. I did a 32bit windows build, slowdebug, warning > enabled, and it failed with those 5+ issues. > > > multiple errors and warnings. Lets reverse the bitrot: > > > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > > > > Most of the fixes are trivial: Calling convention mismatches (awt > DTRACE > > callbacks), printf specifiers etc. > > > > Had to supress a warning in os_windows_x86.cpp - I was surprised > by this > > since this did not look 32bit specifc, do we disable warnings on > Windows > > 64bit builds? > > What version of VS2017? We use VS2017 15.9.6 and we don't disable > warnings. > > > I use VS2017 CE. Not sure which version spcifically, but my compiler is at > > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86 I think that would equate to an older version - 15.7 MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7) Any chance you can upgrade to latest version? (Especially in light of the apparent compiler bug you cite below.) Thanks, David ----- > > The error I had in vmStructs.cpp was a bit weird: compiler > complained about > > an assignment of an enum value defined like this: > > > > hash_mask_in_place? ? ? ?= (address_word)hash_mask << hash_shift > > > > to an uint64_t variable, complaining about narrowing. I did not > find out > > what his problem was. In the end, I decided to add an explicit > cast to > > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). > > Not at all sure that's the right fix. In markOop.hpp we see that value > gets special treatment on Windows-x64: > > > #ifndef _WIN64 > ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?= right_n_bits(hash_bits), > ? ? ? ? ? hash_mask_in_place? ? ? ?= (address_word)hash_mask << > hash_shift > #endif > ? ?}; > > ? ?// Alignment of JavaThread pointers encoded in object header > required > by biased locking > ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift + epoch_bits) > ? ?}; > > #ifdef _WIN64 > ? ? ?// These values are too big for Win64 > ? ? ?const static uintptr_t hash_mask = right_n_bits(hash_bits); > ? ? ?const static uintptr_t hash_mask_in_place? = > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(address_word)hash_mask << hash_shift; > #endif > > perhaps something special is needed for Windows-x86. I'm unclear how > the > values can be "too big" ?? > > > I banged my head against this for an hour or so and I think this is a > compiler bug. > > What I get is: > > warning C4838: conversion from '' to 'uint64_t' requires a narrowing > conversion > > (Note the empty "from" string.) > > Here are my tries to provoke the error: > > VMLongConstantEntry iii[] = {? { "hallo", > markOopDesc::hash_mask_in_place }, {0,0}};? <<< this fails > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place }; > ?<< but this succeeds > uint64_t iii = markOopDesc::hash_mask_in_place;? ?<< this succeeds? too > > I have no clue what this means. It is difficult to fix since the > expression is hidden in such a macro pile. But I think either we go with > my change or we disable the warning for win32 for the whole section. > > > > > With this patch we can build with warnings enabled on 32bit and 64bit > > windows. > > > > Since patch fixes both hotspot and JDK parts, I'm sending it to > hs-dev and > > core-libs-dev. > > Don't see anything that actually comes under core-libs-dev. Looks like > one net-dev, one awt-dev and one security-dev. Sorry. > > > Okay, I will add them. > > Cheers, > David > ----- > > > Thanks for reviewing, > > Thomas > > > Thanks, Thomas > > > From christoph.langer at sap.com Mon Mar 25 07:22:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Mar 2019 07:22:34 +0000 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? In-Reply-To: References: Message-ID: Hi Martijn, as far as I understand the AdoptOpenJDK infrastructure, you have created a cacerts file from the Mozilla certificates which you are using in the AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I missing something? I was planning to bring the cacerts file from jdk/jdk down to 8 with the associated tests. Your build setup should still work then, I guess. However, if somebody from AdoptOpenJDK wants to do the work of bringing it into OpenJDK8 updates, feel free. It?s not the very first thing on my todo list ? Thanks & Best regards Christoph [1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security From: Martijn Verburg Sent: Freitag, 22. M?rz 2019 20:38 To: Sean Mullan Cc: Langer, Christoph ; jdk8u-dev at openjdk.java.net; OpenJDK Dev list Subject: Re: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a patch to upstream that change. Cheers, Martijn On Fri, 22 Mar 2019 at 19:35, Sean Mullan > wrote: Hi Christoph, On 3/21/19 6:20 AM, Langer, Christoph wrote: > Hi, > > I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update? > > With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests. > > Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all? I can answer the first two questions. I talked to one of our Product Managers who was involved with this JEP and he said that we have permission to release these certificates as open source at OpenJDK (much as Mozilla has roots in Firefox). Therefore there should be no concerns using with OpenJDK 8 or other versions for that matter. If you mean the jdk8u project specifically, you should check with the current maintainers for interest in this as I think they currently use other means for their builds. --Sean > > Just trying to start a discussion? ? > > Best regards > Christoph > > [0] http://openjdk.java.net/jeps/319 > [1] https://bugs.openjdk.java.net/browse/JDK-8189131 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Mar 25 12:44:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 13:44:21 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com> References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com> Message-ID: Hi David, Updating vs2017 did not help :/ Cheers, Thomas On Mon, Mar 25, 2019 at 8:17 AM David Holmes wrote: > Hi Thomas, > > On 25/03/2019 5:01 pm, Thomas St?fe wrote: > > Hi David, > > > > (added net-dev, awt-dev, security-dev since part of these fixes are in > > their territory) > > May be better to split up the reviews, cross-posting that many groups > gets very messy given most people won't be subscribed to them all - > myself included. > > > > On Mon, Mar 25, 2019 at 1:34 AM David Holmes > > wrote: > > > > Hi Thomas, > > > > A few queries, comments and concerns ... > > > > On 25/03/2019 6:58 am, Thomas St?fe wrote: > > > Hi all, > > > > > > After a long time I tried to build a Windows 32bit VM (VS2017) > > and failed; > > > > I'm somewhat surprised as I thought someone was actively doing > Windows > > 32-bit builds out there, plus there are shared code changes that > should > > also have been caught by non-Windows 32-bit builds. :( > > > > > > Not sure what others do. I did a 32bit windows build, slowdebug, warning > > enabled, and it failed with those 5+ issues. > > > > > multiple errors and warnings. Lets reverse the bitrot: > > > > > > cr: > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > > > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > > > > > > Most of the fixes are trivial: Calling convention mismatches (awt > > DTRACE > > > callbacks), printf specifiers etc. > > > > > > Had to supress a warning in os_windows_x86.cpp - I was surprised > > by this > > > since this did not look 32bit specifc, do we disable warnings on > > Windows > > > 64bit builds? > > > > What version of VS2017? We use VS2017 15.9.6 and we don't disable > > warnings. > > > > > > I use VS2017 CE. Not sure which version spcifically, but my compiler is > at > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86 > > I think that would equate to an older version - 15.7 > > MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7) > > Any chance you can upgrade to latest version? (Especially in light of > the apparent compiler bug you cite below.) > > Thanks, > David > ----- > > > > The error I had in vmStructs.cpp was a bit weird: compiler > > complained about > > > an assignment of an enum value defined like this: > > > > > > hash_mask_in_place = (address_word)hash_mask << hash_shift > > > > > > to an uint64_t variable, complaining about narrowing. I did not > > find out > > > what his problem was. In the end, I decided to add an explicit > > cast to > > > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). > > > > Not at all sure that's the right fix. In markOop.hpp we see that > value > > gets special treatment on Windows-x64: > > > > > > #ifndef _WIN64 > > ,hash_mask = right_n_bits(hash_bits), > > hash_mask_in_place = (address_word)hash_mask << > > hash_shift > > #endif > > }; > > > > // Alignment of JavaThread pointers encoded in object header > > required > > by biased locking > > enum { biased_lock_alignment = 2 << (epoch_shift + epoch_bits) > > }; > > > > #ifdef _WIN64 > > // These values are too big for Win64 > > const static uintptr_t hash_mask = right_n_bits(hash_bits); > > const static uintptr_t hash_mask_in_place = > > (address_word)hash_mask << hash_shift; > > #endif > > > > perhaps something special is needed for Windows-x86. I'm unclear how > > the > > values can be "too big" ?? > > > > > > I banged my head against this for an hour or so and I think this is a > > compiler bug. > > > > What I get is: > > > > warning C4838: conversion from '' to 'uint64_t' requires a narrowing > > conversion > > > > (Note the empty "from" string.) > > > > Here are my tries to provoke the error: > > > > VMLongConstantEntry iii[] = { { "hallo", > > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails > > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place }; > > << but this succeeds > > uint64_t iii = markOopDesc::hash_mask_in_place; << this succeeds too > > > > I have no clue what this means. It is difficult to fix since the > > expression is hidden in such a macro pile. But I think either we go with > > my change or we disable the warning for win32 for the whole section. > > > > > > > > With this patch we can build with warnings enabled on 32bit and > 64bit > > > windows. > > > > > > Since patch fixes both hotspot and JDK parts, I'm sending it to > > hs-dev and > > > core-libs-dev. > > > > Don't see anything that actually comes under core-libs-dev. Looks > like > > one net-dev, one awt-dev and one security-dev. Sorry. > > > > > > Okay, I will add them. > > > > Cheers, > > David > > ----- > > > > > > Thanks for reviewing, > > > > Thomas > > > > > Thanks, Thomas > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Mar 25 12:45:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 13:45:21 +0100 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com> Message-ID: Hi all, Following David's suggestion, I withdraw this bug and will open issues for each area separately. Cheers, Thomas On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe wrote: > Hi David, > > Updating vs2017 did not help :/ > > Cheers, Thomas > > On Mon, Mar 25, 2019 at 8:17 AM David Holmes > wrote: > >> Hi Thomas, >> >> On 25/03/2019 5:01 pm, Thomas St?fe wrote: >> > Hi David, >> > >> > (added net-dev, awt-dev, security-dev since part of these fixes are in >> > their territory) >> >> May be better to split up the reviews, cross-posting that many groups >> gets very messy given most people won't be subscribed to them all - >> myself included. >> > > >> >> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes > > > wrote: >> > >> > Hi Thomas, >> > >> > A few queries, comments and concerns ... >> > >> > On 25/03/2019 6:58 am, Thomas St?fe wrote: >> > > Hi all, >> > > >> > > After a long time I tried to build a Windows 32bit VM (VS2017) >> > and failed; >> > >> > I'm somewhat surprised as I thought someone was actively doing >> Windows >> > 32-bit builds out there, plus there are shared code changes that >> should >> > also have been caught by non-Windows 32-bit builds. :( >> > >> > >> > Not sure what others do. I did a 32bit windows build, slowdebug, >> warning >> > enabled, and it failed with those 5+ issues. >> > >> > > multiple errors and warnings. Lets reverse the bitrot: >> > > >> > > cr: >> > > >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ >> > > >> > > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 >> > > >> > > Most of the fixes are trivial: Calling convention mismatches (awt >> > DTRACE >> > > callbacks), printf specifiers etc. >> > > >> > > Had to supress a warning in os_windows_x86.cpp - I was surprised >> > by this >> > > since this did not look 32bit specifc, do we disable warnings on >> > Windows >> > > 64bit builds? >> > >> > What version of VS2017? We use VS2017 15.9.6 and we don't disable >> > warnings. >> > >> > >> > I use VS2017 CE. Not sure which version spcifically, but my compiler is >> at >> > >> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86 >> >> I think that would equate to an older version - 15.7 >> >> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7) >> >> Any chance you can upgrade to latest version? (Especially in light of >> the apparent compiler bug you cite below.) >> >> Thanks, >> David >> ----- >> >> > > The error I had in vmStructs.cpp was a bit weird: compiler >> > complained about >> > > an assignment of an enum value defined like this: >> > > >> > > hash_mask_in_place = (address_word)hash_mask << hash_shift >> > > >> > > to an uint64_t variable, complaining about narrowing. I did not >> > find out >> > > what his problem was. In the end, I decided to add an explicit >> > cast to >> > > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp). >> > >> > Not at all sure that's the right fix. In markOop.hpp we see that >> value >> > gets special treatment on Windows-x64: >> > >> > >> > #ifndef _WIN64 >> > ,hash_mask = right_n_bits(hash_bits), >> > hash_mask_in_place = (address_word)hash_mask << >> > hash_shift >> > #endif >> > }; >> > >> > // Alignment of JavaThread pointers encoded in object header >> > required >> > by biased locking >> > enum { biased_lock_alignment = 2 << (epoch_shift + >> epoch_bits) >> > }; >> > >> > #ifdef _WIN64 >> > // These values are too big for Win64 >> > const static uintptr_t hash_mask = right_n_bits(hash_bits); >> > const static uintptr_t hash_mask_in_place = >> > (address_word)hash_mask << hash_shift; >> > #endif >> > >> > perhaps something special is needed for Windows-x86. I'm unclear how >> > the >> > values can be "too big" ?? >> > >> > >> > I banged my head against this for an hour or so and I think this is a >> > compiler bug. >> > >> > What I get is: >> > >> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing >> > conversion >> > >> > (Note the empty "from" string.) >> > >> > Here are my tries to provoke the error: >> > >> > VMLongConstantEntry iii[] = { { "hallo", >> > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails >> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place >> }; >> > << but this succeeds >> > uint64_t iii = markOopDesc::hash_mask_in_place; << this succeeds too >> > >> > I have no clue what this means. It is difficult to fix since the >> > expression is hidden in such a macro pile. But I think either we go >> with >> > my change or we disable the warning for win32 for the whole section. >> > >> > > >> > > With this patch we can build with warnings enabled on 32bit and >> 64bit >> > > windows. >> > > >> > > Since patch fixes both hotspot and JDK parts, I'm sending it to >> > hs-dev and >> > > core-libs-dev. >> > >> > Don't see anything that actually comes under core-libs-dev. Looks >> like >> > one net-dev, one awt-dev and one security-dev. Sorry. >> > >> > >> > Okay, I will add them. >> > >> > Cheers, >> > David >> > ----- >> > >> > >> > Thanks for reviewing, >> > >> > Thomas >> > >> > > Thanks, Thomas >> > > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Mar 25 13:12:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 14:12:49 +0100 Subject: RFR(xxs): 8221407: Windows 32bit build error in libsunmscapi/security.cpp Message-ID: Hi all, please review this tiny fix to the windows 32 build: issue: https://bugs.openjdk.java.net/browse/JDK-8221407 cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/ Just a bunch of obvious fixes for cases where a jlong was handed into system APIs requiring HANDLEs, which are pointer sized. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Mon Mar 25 15:37:41 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 25 Mar 2019 15:37:41 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> Message-ID: <20190325153741.GM9177@twosigma.com> On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote: > > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >>> There's a few reasons: > >>> > >>> - NTLM doesn't have an OID, at least as I remember > >>> > >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ > >>> regards to the ServicePermission stuff > >> > >> Yes, it needs to check a permission if the token is SPNEGO and > >> internally it's Kerberos. I also believe the HTTP Negotiate code > >> there is probably not good at dealing with a Negotiate dialog with > >> 2 rounds. The first problem should be easy to fix, I'll see if the > >> 2nd is complicated. I expect lots of implementations of HTTP/Negotiate to not support more than one round trip. However, if a client and server lack credentials for a common mechanism, authentication will fail or not even start, and if they do have credentials for a common mechanism but one or both cannot handle more than one round trip, they'll fail. Either way they fail, so what's the problem? Ignoring for a moment NTLM's weakness, adding support for it adds ways to win, not ways to fail. > It works. Java's (old) HTTPConnection sends an NTLM token to IIS and > after 4 messages I see 200 OK. > > But 1) Java GSS acceptor does not accept it and I don't want to break > interop inside Java. That's not breaking interop. A Windows initiator and non-Windows acceptor (and vice-versa) will still interop provided both have Kerberos credentials. > 2) No more permission check. I don't understand (2). > Not going to do it this time. Later I might ask networking how > transparent NTLM works and if they needs any permission checking or > other settings I can probably follow. Of course it needs permission checking, except that in a world without applets that's a bit pointless. Nico -- From ecki at zusammenkunft.net Mon Mar 25 19:45:07 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 25 Mar 2019 19:45:07 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190325153741.GM9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>, <20190325153741.GM9177@twosigma.com> Message-ID: Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft?s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly TDS (SQL Server), SMB and http. So having a GSS provider, even when it is not used by default would hugely benefit a lot of projects (especially if it does not require JAAS wrapping and will support Windows 10 with Credential Guard for NTLM and Kerberos) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Nico Williams Gesendet: Montag, M?rz 25, 2019 6:38 PM An: Weijun Wang Cc: security-dev at openjdk.java.net Betreff: Re: RFR 6722928: Support SSPI as a native GSS-API provider On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote: > > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >>> There's a few reasons: > >>> > >>> - NTLM doesn't have an OID, at least as I remember > >>> > >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ > >>> regards to the ServicePermission stuff > >> > >> Yes, it needs to check a permission if the token is SPNEGO and > >> internally it's Kerberos. I also believe the HTTP Negotiate code > >> there is probably not good at dealing with a Negotiate dialog with > >> 2 rounds. The first problem should be easy to fix, I'll see if the > >> 2nd is complicated. I expect lots of implementations of HTTP/Negotiate to not support more than one round trip. However, if a client and server lack credentials for a common mechanism, authentication will fail or not even start, and if they do have credentials for a common mechanism but one or both cannot handle more than one round trip, they'll fail. Either way they fail, so what's the problem? Ignoring for a moment NTLM's weakness, adding support for it adds ways to win, not ways to fail. > It works. Java's (old) HTTPConnection sends an NTLM token to IIS and > after 4 messages I see 200 OK. > > But 1) Java GSS acceptor does not accept it and I don't want to break > interop inside Java. That's not breaking interop. A Windows initiator and non-Windows acceptor (and vice-versa) will still interop provided both have Kerberos credentials. > 2) No more permission check. I don't understand (2). > Not going to do it this time. Later I might ask networking how > transparent NTLM works and if they needs any permission checking or > other settings I can probably follow. Of course it needs permission checking, except that in a world without applets that's a bit pointless. Nico -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Mar 25 20:58:23 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 25 Mar 2019 13:58:23 -0700 Subject: [13] RFR JDK-8216039 "TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange" Message-ID: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> Based on the earlier internal discussion, here is a "backportable" fix for JDK-8216039 "TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange" which does not bear any public API change. Existing JDK codes which uses PSS signature with parameters will call the new internal JDK APIs which select the provider based on both key and parameters. There is no provider-specific checking and it accommodate the usage of the BouncyCastle FIPS provider for TLS and other applications. Default implementations of the new methods are provided, so existing JDK crypto providers should continue to work without change. The default impl also set the parameters before calling init() to avoid trigger the known PSS behavior/issue in BC FIPS provider which leads to signature interoperabilities. As for making the JDK internal APIs public, I plan to file a separate bug (and CCC) later if this approach is acceptable. Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Webrev: http://cr.openjdk.java.net/~valeriep/8216039/webrev.00/ Mach5 result is clean. Thanks, Valerie From Nico.Williams at twosigma.com Mon Mar 25 21:22:48 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 25 Mar 2019 21:22:48 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> <20190325153741.GM9177@twosigma.com> Message-ID: <20190325212248.GN9177@twosigma.com> On Mon, Mar 25, 2019 at 07:45:07PM +0000, Bernd Eckenfels wrote: > Just to add another aspect to the discussion, there are at least 3 DLLs out > there which implement this functionality (Microsoft?s JDBC driver, jTDS > driver and Waffle) + commercial solutions as we have heared. All of them are > used to allow authenticating the current user against services (mostly TDS > (SQL Server), SMB and http. > > So having a GSS provider, even when it is not used by default would hugely > benefit a lot of projects (especially if it does not require JAAS wrapping > and will support Windows 10 with Credential Guard for NTLM and Kerberos) Good point. Oh, and BTW, Windows too has acquireCredential extensions not unlike gss_acquire_cred_from(). From martijnverburg at gmail.com Fri Mar 22 19:37:37 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 22 Mar 2019 19:37:37 +0000 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? In-Reply-To: References: Message-ID: FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a patch to upstream that change. Cheers, Martijn On Fri, 22 Mar 2019 at 19:35, Sean Mullan wrote: > Hi Christoph, > > On 3/21/19 6:20 AM, Langer, Christoph wrote: > > Hi, > > > > I recently came across a scenario where I wanted to use a self-built > OpenJDK 8 in a maven build and it could not download artefacts due to > missing root certificates. I helped myself by replacing the cacerts with > some other version from a later OpenJDK and came over the issue. However, > I?ve asked myself whether it was possible/worthwhile to get the root > certificates also into an OpenJDK 8 update? > > > > With JEP 319 [0], Oracle has open-sourced the root certificates into > OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. > After that, several commits have been made to update the set of root > certificates and improve the tests. > > > > Now my questions are: Is it legally possible to bring these root > certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be > added to OpenJDK 8 via an update release? And, last but not least, would > there be interest in the community for that at all? > > I can answer the first two questions. I talked to one of our Product > Managers who was involved with this JEP and he said that we have > permission to release these certificates as open source at OpenJDK (much > as Mozilla has roots in Firefox). Therefore there should be no concerns > using with OpenJDK 8 or other versions for that matter. If you mean the > jdk8u project specifically, you should check with the current > maintainers for interest in this as I think they currently use other > means for their builds. > > --Sean > > > > > Just trying to start a discussion? ? > > > > Best regards > > Christoph > > > > [0] http://openjdk.java.net/jeps/319 > > [1] https://bugs.openjdk.java.net/browse/JDK-8189131 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Mon Mar 25 19:47:19 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 25 Mar 2019 19:47:19 +0000 Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ? In-Reply-To: References: Message-ID: We basically pulled in the JEP 319 certs from 11 and put them into 8. Happy to create a patch if that helps, might be a slightly different set to what you are proposing though? Cheers, Martijn On Mon, 25 Mar 2019 at 07:22, Langer, Christoph wrote: > Hi Martijn, > > > > as far as I understand the AdoptOpenJDK infrastructure, you have created a > cacerts file from the Mozilla certificates which you are using in the > AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I > missing something? > > > > I was planning to bring the cacerts file from jdk/jdk down to 8 with the > associated tests. Your build setup should still work then, I guess. > > > > However, if somebody from AdoptOpenJDK wants to do the work of bringing it > into OpenJDK8 updates, feel free. It?s not the very first thing on my todo > list ? > > > > Thanks & Best regards > > Christoph > > > > [1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security > > > > > > *From:* Martijn Verburg > *Sent:* Freitag, 22. M?rz 2019 20:38 > *To:* Sean Mullan > *Cc:* Langer, Christoph ; > jdk8u-dev at openjdk.java.net; OpenJDK Dev list < > security-dev at openjdk.java.net> > *Subject:* Re: [8u] Is it possible to bring root certificates to OpenJDK > 8 [JEP319] ? > > > > FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide > a patch to upstream that change. > > > Cheers, > Martijn > > > > > > On Fri, 22 Mar 2019 at 19:35, Sean Mullan wrote: > > Hi Christoph, > > On 3/21/19 6:20 AM, Langer, Christoph wrote: > > Hi, > > > > I recently came across a scenario where I wanted to use a self-built > OpenJDK 8 in a maven build and it could not download artefacts due to > missing root certificates. I helped myself by replacing the cacerts with > some other version from a later OpenJDK and came over the issue. However, > I?ve asked myself whether it was possible/worthwhile to get the root > certificates also into an OpenJDK 8 update? > > > > With JEP 319 [0], Oracle has open-sourced the root certificates into > OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. > After that, several commits have been made to update the set of root > certificates and improve the tests. > > > > Now my questions are: Is it legally possible to bring these root > certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be > added to OpenJDK 8 via an update release? And, last but not least, would > there be interest in the community for that at all? > > I can answer the first two questions. I talked to one of our Product > Managers who was involved with this JEP and he said that we have > permission to release these certificates as open source at OpenJDK (much > as Mozilla has roots in Firefox). Therefore there should be no concerns > using with OpenJDK 8 or other versions for that matter. If you mean the > jdk8u project specifically, you should check with the current > maintainers for interest in this as I think they currently use other > means for their builds. > > --Sean > > > > > Just trying to start a discussion? ? > > > > Best regards > > Christoph > > > > [0] http://openjdk.java.net/jeps/319 > > [1] https://bugs.openjdk.java.net/browse/JDK-8189131 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Mar 25 14:46:25 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 25 Mar 2019 14:46:25 +0000 Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken In-Reply-To: References: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com> <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com> Message-ID: <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com> Hi Thomas, There was a thread about failing build on 32 bit Windows: http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023767.html It continued in February 2019: http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024925.html Fast debug builds were affected. Likely there was mismatch between CALLBACK / JNICALL macro: http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024972.html http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024973.html Magnus suggested a fix: http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024996.html Yet there was no reply as whether it fixed the debug build or not. Hope these pointers help. Regards, Alexey On 25/03/2019 12:45, Thomas St?fe wrote: > Hi all, > > Following David's suggestion, I withdraw this bug and will open issues > for each area separately. > > Cheers, Thomas > > > > On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe > wrote: > > Hi David, > > Updating vs2017 did not help :/ > > Cheers, Thomas > > On Mon, Mar 25, 2019 at 8:17 AM David Holmes > > wrote: > > Hi Thomas, > > On 25/03/2019 5:01 pm, Thomas St?fe wrote: > > Hi David, > > > > (added net-dev, awt-dev, security-dev since part of these > fixes are in > > their territory) > > May be better to split up the reviews, cross-posting that many > groups > gets very messy given most people won't be subscribed to them > all - > myself included. > > > > > On Mon, Mar 25, 2019 at 1:34 AM David Holmes > > > >> wrote: > > > >? ? ?Hi Thomas, > > > >? ? ?A few queries, comments and concerns ... > > > >? ? ?On 25/03/2019 6:58 am, Thomas St?fe wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > After a long time I tried to build a Windows 32bit VM > (VS2017) > >? ? ?and failed; > > > >? ? ?I'm somewhat surprised as I thought someone was actively > doing Windows > >? ? ?32-bit builds out there, plus there are shared code > changes that should > >? ? ?also have been caught by non-Windows 32-bit builds. :( > > > > > > Not sure what others?do. I did a 32bit windows build, > slowdebug, warning > > enabled, and it failed with those 5+ issues. > > > >? ? ? > multiple errors and warnings. Lets reverse the bitrot: > >? ? ? > > >? ? ? > cr: > >? ? ? > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/ > >? ? ? > > >? ? ? > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375 > >? ? ? > > >? ? ? > Most of the fixes are trivial: Calling convention > mismatches (awt > >? ? ?DTRACE > >? ? ? > callbacks), printf specifiers etc. > >? ? ? > > >? ? ? > Had to supress a warning in os_windows_x86.cpp - I > was surprised > >? ? ?by this > >? ? ? > since this did not look 32bit specifc, do we disable > warnings on > >? ? ?Windows > >? ? ? > 64bit builds? > > > >? ? ?What version of VS2017? We use VS2017 15.9.6 and we > don't disable > >? ? ?warnings. > > > > > > I use VS2017 CE. Not sure which version spcifically, but my > compiler is at > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 > for x86 > > I think that would equate to an older version - 15.7 > > MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7) > > Any chance you can upgrade to latest version? (Especially in > light of > the apparent compiler bug you cite below.) > > Thanks, > David > ----- > > >? ? ? > The error I had in vmStructs.cpp was a bit weird: > compiler > >? ? ?complained about > >? ? ? > an assignment of an enum value defined like this: > >? ? ? > > >? ? ? > hash_mask_in_place? ? ? ?= (address_word)hash_mask << > hash_shift > >? ? ? > > >? ? ? > to an uint64_t variable, complaining about narrowing. > I did not > >? ? ?find out > >? ? ? > what his problem was. In the end, I decided to add an > explicit > >? ? ?cast to > >? ? ? > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see > vmStructs.hpp). > > > >? ? ?Not at all sure that's the right fix. In markOop.hpp we > see that value > >? ? ?gets special treatment on Windows-x64: > > > > > >? ? ?#ifndef _WIN64 > >? ? ? ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?= > right_n_bits(hash_bits), > >? ? ? ? ? ? ? ? hash_mask_in_place? ? ? ?= > (address_word)hash_mask << > >? ? ?hash_shift > >? ? ?#endif > >? ? ? ? ?}; > > > >? ? ? ? ?// Alignment of JavaThread pointers encoded in > object header > >? ? ?required > >? ? ?by biased locking > >? ? ? ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift > + epoch_bits) > >? ? ? ? ?}; > > > >? ? ?#ifdef _WIN64 > >? ? ? ? ? ?// These values are too big for Win64 > >? ? ? ? ? ?const static uintptr_t hash_mask = > right_n_bits(hash_bits); > >? ? ? ? ? ?const static uintptr_t hash_mask_in_place? = > > ?(address_word)hash_mask << hash_shift; > >? ? ?#endif > > > >? ? ?perhaps something special is needed for Windows-x86. I'm > unclear how > >? ? ?the > >? ? ?values can be "too big" ?? > > > > > > I banged my head against this for an hour or so and I think > this is a > > compiler bug. > > > > What I get is: > > > > warning C4838: conversion from '' to 'uint64_t' requires a > narrowing > > conversion > > > > (Note the empty "from" string.) > > > > Here are my tries to provoke the error: > > > > VMLongConstantEntry iii[] = {? { "hallo", > > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails > > VMLongConstantEntry iii = { "hallo", > markOopDesc::hash_mask_in_place }; > >? ?<< but this succeeds > > uint64_t iii = markOopDesc::hash_mask_in_place; ?<< this > succeeds? too > > > > I have no clue what this means. It is difficult to fix since > the > > expression is hidden in such a macro pile. But I think > either we go with > > my change or we disable the warning for win32 for the whole > section. > > > >? ? ? > > >? ? ? > With this patch we can build with warnings enabled on > 32bit and 64bit > >? ? ? > windows. > >? ? ? > > >? ? ? > Since patch fixes both hotspot and JDK parts, I'm > sending it to > >? ? ?hs-dev and > >? ? ? > core-libs-dev. > > > >? ? ?Don't see anything that actually comes under > core-libs-dev. Looks like > >? ? ?one net-dev, one awt-dev and one security-dev. Sorry. > > > > > > Okay, I will add them. > > > >? ? ?Cheers, > >? ? ?David > >? ? ?----- > > > > > > Thanks for reviewing, > > > > Thomas > > > >? ? ? > Thanks, Thomas > >? ? ? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 25 23:12:21 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 Mar 2019 07:12:21 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190325153741.GM9177@twosigma.com> References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> <20190325153741.GM9177@twosigma.com> Message-ID: <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com> > On Mar 25, 2019, at 11:37 PM, Nico Williams wrote: > > On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote: >>> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>>>> There's a few reasons: >>>>> >>>>> - NTLM doesn't have an OID, at least as I remember >>>>> >>>>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ >>>>> regards to the ServicePermission stuff >>>> >>>> Yes, it needs to check a permission if the token is SPNEGO and >>>> internally it's Kerberos. I also believe the HTTP Negotiate code >>>> there is probably not good at dealing with a Negotiate dialog with >>>> 2 rounds. The first problem should be easy to fix, I'll see if the >>>> 2nd is complicated. > > I expect lots of implementations of HTTP/Negotiate to not support more > than one round trip. However, if a client and server lack credentials > for a common mechanism, authentication will fail or not even start, and > if they do have credentials for a common mechanism but one or both > cannot handle more than one round trip, they'll fail. Either way they > fail, so what's the problem? Ignoring for a moment NTLM's weakness, > adding support for it adds ways to win, not ways to fail. > >> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and >> after 4 messages I see 200 OK. >> >> But 1) Java GSS acceptor does not accept it and I don't want to break >> interop inside Java. > > That's not breaking interop. A Windows initiator and non-Windows > acceptor (and vice-versa) will still interop provided both have Kerberos > credentials. But there needs another round of negotiation and you know Java might not be good at it. > >> 2) No more permission check. > > I don't understand (2). Now that the ServicePermission check is skipped, some sort of NTLMPermission check will be needed. --Max > >> Not going to do it this time. Later I might ask networking how >> transparent NTLM works and if they needs any permission checking or >> other settings I can probably follow. > > Of course it needs permission checking, except that in a world without > applets that's a bit pointless. > > Nico > -- From valerie.peng at oracle.com Tue Mar 26 00:03:39 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 25 Mar 2019 17:03:39 -0700 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> Message-ID: <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> Hi, Martin, Thanks for trying to address this "free-wrapper-key" issue. However, changes in the key clean up/free area is difficult to verify and check for issues and I am a little concerned that this new model may be hard to trace when the key id is mutable and potentially fragile/error prone for future changes/fixes. I still need to think through a few things. Maybe you can help me understand the current changes or we can explore alternatives. My questions/feedbacks on current changes are: 1) line 1283: ref may be null (see line 1220) and this will lead to NPE? 2) It looks like you don't really need to store the "wrapperKeyUsed" value in both NativeKeyHolder and SessionKeyRef classes. It can be a local variable for NativeKeyHolder class and the increment of nativeKeyWrapperRefCount can be moved to SessionKeyRef constructor.? The counter nativeKeyWrapperRefCount is incremented inside NativeKeyHolder constructor 3) I have not spent as much time as you on tracing this. However, I think we should be able to keep the "final keyID" approach and handle the NativeKeyWrapperRefCount inc/dec in SessionKeyRef constructor/dispose methods. Have you tried this? 4) It may not be enough to just run tests under sun/security/pkcs11, as SunPKCS11 provider is used by many other JDK security components such as TLS. To be safe, you should submit the test against jdk-tier1,jdk-tier2 to check for possible regressions. If you can't, please let me know. Thanks, Valerie On 3/20/2019 9:24 PM, Martin Balao wrote: > Hi Valerie, > > On 3/19/19 7:17 PM, Valerie Peng wrote: >> How about another potential problem - wrapper key may never get deleted? >> If we don't have a good solution to addressing it, at least add a >> comment about it? >> Rest looks fine. >> > Thanks for your feedback. > > The Wrapper Key was never meant to be destroyed. However, it's a good > idea and we should do it, in addition to fixing this bug. > > Here it's my proposal for getting rid of the Wrapper Key when it's no > longer needed: > > Webrev 01: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.01/ > > Please note that a few changes were required in SessionKeyRef objects > lifetime. SessionKeyRef objects will live as long as their corresponding > P11Key object lives -a similar scheme was implemented in the original > patch-. This allows us to decrement Wrapper Key references -and > eventually destroy it- while P11Key objects which don't have a native > key created are deleted. In other words, objects that have wrapped > native key information but don't have a native key alive can also > decrement the Wrapper Key reference counter when deleted. > > Testing: > > * No regressions found in sun/security/pkcs11. > > * I've verified with the debugger all the new execution flows, > including the deletion of a Wrapper Key. It would be a bit difficult to > assert this from an automated test though. > > Kind regards, > Martin.- From raell at web.de Mon Mar 25 23:17:59 2019 From: raell at web.de (raell at web.de) Date: Tue, 26 Mar 2019 00:17:59 +0100 Subject: Release plan for ChaCha20/Poly1305 cipher suite Message-ID: Dear, in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is neither part of Java 12. Out of interest: Is there a plan in which Java release the cipher suite will be supported. Thanks and regards, Ralph From bradford.wetmore at oracle.com Tue Mar 26 00:14:24 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 25 Mar 2019 17:14:24 -0700 Subject: Release plan for ChaCha20/Poly1305 cipher suite In-Reply-To: References: Message-ID: Please see the SunJSSE provider documentation for JDK 12. https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 Brad On 3/25/2019 4:17 PM, raell at web.de wrote: > Dear, > > in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is neither part of Java 12. > > Out of interest: Is there a plan in which Java release the cipher suite will be supported. > > Thanks and regards, > > Ralph > From jamil.j.nimeh at oracle.com Tue Mar 26 01:33:09 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 25 Mar 2019 18:33:09 -0700 Subject: Release plan for ChaCha20/Poly1305 cipher suite In-Reply-To: References: Message-ID: <28c42571-811c-16a9-2b8a-487d1b290d3c@oracle.com> Hello Ralph, to add to what Brad already said: The TLS 1.2 and 1.3 ChaCha20-Poly1305 suites are present in JDK 12, but not JDK 11 (that was just the JCE Cipher support). JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 Commit: http://hg.openjdk.java.net/jdk/jdk/rev/720fd6544b03 --Jamil On 3/25/19 5:14 PM, Bradford Wetmore wrote: > Please see the SunJSSE provider documentation for JDK 12. > > https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 > > > Brad > > > On 3/25/2019 4:17 PM, raell at web.de wrote: >> Dear, >> >> in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms >> had been implemented. However, the cipher suite >> TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher >> suites. As far as I can see, support for this cipher suite is? >> neither part of Java 12. >> >> Out of interest: Is there a plan in which Java release the cipher >> suite will be supported. >> >> Thanks and regards, >> >> Ralph >> From weijun.wang at oracle.com Tue Mar 26 03:20:10 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 Mar 2019 11:20:10 +0800 Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain java tests In-Reply-To: References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com> <1550223285.2497.12.camel@paratix.ch> <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com> Message-ID: Ding-dong. > On Mar 5, 2019, at 8:26 AM, Weijun Wang wrote: > > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8180573/webrev.01 > > BTW, last time I mistakenly removed ExportPrivateKeyNoPwd.java which is used by ListKeychainStore.sh. It's now back. > > Thanks, > Max > >> On Feb 15, 2019, at 9:31 PM, Weijun Wang wrote: >> >> Hi Philipp, >> >> In most cases, it's just about creating a non-empty file; in some case, the content is relevant. For the former, I will change it to something like "new byte[10]"; for the latter, I'll use getBytes(UTF_8). >> >> Thanks, >> Max >> >> >>> On Feb 15, 2019, at 5:34 PM, Philipp Kunz wrote: >>> >>> Hi Max, >>> >>> I don't know if it is important enough, certainly not a serious issue. >>> In your patch, for example in DiffEnd.java and a few other tests, Strings are encoded to byte streams with String.getBytes() which uses the default platform character set to encode the strings. >>> Manifests, however, always use UTF-8 as the character set to encode. In my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be appropriate to specify the encoding in a platform-independent way. >>> Now the manifests used in the tests use so few different characters that this might not even make a real difference because the first around 100 characters or so of most character sets are the same in most encodings. >>> I suspect that the encoding might also have been platform-dependent in at least some of the previous shell tests and therefore this aspect might as well be addressed separately and is not strictly necessary to just properly convert shell tests to java. >>> >>> Regards, >>> Philipp >>> >>> >>> On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote: >>>> Please review the fix at >>>> >>>> >>>> https://cr.openjdk.java.net/~weijun/8180573/webrev.00/ >>>> >>>> >>>> Notes: >>>> >>>> - Most changes are just .sh -> .java >>>> >>>> - StorePasswordsByShell.sh combined into StorePasswords.java >>>> >>>> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also. >>>> >>>> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty. >>>> >>>> - Copyright year updated to 2019, @bug unchanged. >>>> >>>> Two files not converted yet: >>>> >>>> - ./keytool/console.sh >>>> >>>> This is a manual test calling old versions of JDK. >>>> >>>> - ./keytool/ListKeychainStore.sh >>>> >>>> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it. >>>> >>>> Thanks, >>>> Max >>>> >>>> >> > From christoph.langer at sap.com Tue Mar 26 08:39:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 26 Mar 2019 08:39:33 +0000 Subject: RFR(xxs): 8221407: Windows 32bit build error in libsunmscapi/security.cpp In-Reply-To: References: Message-ID: Hi Thomas, looks good to me. Best regards Christoph From: security-dev On Behalf Of Thomas St?fe Sent: Montag, 25. M?rz 2019 14:13 To: security-dev at openjdk.java.net Subject: RFR(xxs): 8221407: Windows 32bit build error in libsunmscapi/security.cpp Hi all, please review this tiny fix to the windows 32 build: issue: https://bugs.openjdk.java.net/browse/JDK-8221407 cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/ Just a bunch of obvious fixes for cases where a jlong was handed into system APIs requiring HANDLEs, which are pointer sized. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue Mar 26 08:50:33 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Mar 2019 09:50:33 +0100 Subject: RFR(xxs): 8221407: Windows 32bit build error in libsunmscapi/security.cpp In-Reply-To: References: Message-ID: Thanks, Christoph! On Tue, Mar 26, 2019, 9:39 AM Langer, Christoph wrote: > Hi Thomas, > > > > looks good to me. > > > > Best regards > > Christoph > > > > *From:* security-dev *On Behalf > Of *Thomas St?fe > *Sent:* Montag, 25. M?rz 2019 14:13 > *To:* security-dev at openjdk.java.net > *Subject:* RFR(xxs): 8221407: Windows 32bit build error in > libsunmscapi/security.cpp > > > > Hi all, > > > > please review this tiny fix to the windows 32 build: > > > > issue: https://bugs.openjdk.java.net/browse/JDK-8221407 > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/ > > > > Just a bunch of obvious fixes for cases where a jlong was handed into > system APIs requiring HANDLEs, which are pointer sized. > > > > Thanks, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Tue Mar 26 15:24:04 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 26 Mar 2019 15:24:04 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com> References: <20190322152824.GF9177@twosigma.com> <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com> <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com> <20190325153741.GM9177@twosigma.com> <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com> Message-ID: <20190326152404.GO9177@twosigma.com> On Tue, Mar 26, 2019 at 07:12:21AM +0800, Weijun Wang wrote: > > On Mar 25, 2019, at 11:37 PM, Nico Williams wrote: > >> But 1) Java GSS acceptor does not accept it and I don't want to break > >> interop inside Java. > > > > That's not breaking interop. A Windows initiator and non-Windows > > acceptor (and vice-versa) will still interop provided both have Kerberos > > credentials. > > But there needs another round of negotiation and you know Java might not be good at it. As long as it doesn't crash it's good enough. There's two ways to fail, and that's OK. > >> 2) No more permission check. > > > > I don't understand (2). > > Now that the ServicePermission check is skipped, some sort of > NTLMPermission check will be needed. IIRC that's too difficult. It would be easier to map generic GSS names to Kerberos names for use with ServicePermission. The design of ServicePermission was all wrong, it should always have dealt with GSS names only, and Krb5Principal should never have been a thing because GSSName should have been a (extend) Principal. By making GSSName extend Principal we can begin to fix these issues. From weijun.wang at oracle.com Wed Mar 27 13:53:00 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 Mar 2019 21:53:00 +0800 Subject: RFR 8221257: Improve serial number generation mechanism for keytool -gencert Message-ID: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8221257/webrev.00/ The test would intermittently fail, which could be annoying in the future although the randomness keyword is used. But the test is meant to ensure that we provide 64 bits of randomness so I'll keep it. Thanks, Max From xuelei.fan at oracle.com Wed Mar 27 14:44:17 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Mar 2019 07:44:17 -0700 Subject: RFR 8221257: Improve serial number generation mechanism for keytool -gencert In-Reply-To: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com> References: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com> Message-ID: Looks fine to me. Xuelei On 3/27/2019 6:53 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8221257/webrev.00/ > > The test would intermittently fail, which could be annoying in the future although the randomness keyword is used. But the test is meant to ensure that we provide 64 bits of randomness so I'll keep it. > > Thanks, > Max > From xuelei.fan at oracle.com Wed Mar 27 15:48:59 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Mar 2019 08:48:59 -0700 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> Message-ID: <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com> DerIndefLenConverter.convertStream(). Is it a concern that this method read too much? For example, the DER bytes of the target object is 256 bytes, but read 1024 bytes from the input stream. And then the next DER or other object in the inputstream may not be able to properly parsed. BTW, if the input stream is a slow traffic, there might be a few DataNotEnoughException get thrown. Throwing and catching of exceptions are expensive. I may divide the convertBytes() into two parts, one looking for the DER ending position, the other one converting to DER encoding. Then the DataNotEnoughException in convertStream() could be avoided. Thanks, Xuelei On 3/24/2019 7:42 PM, Weijun Wang wrote: > Ping again. > > No new test added. > > Thanks, > Max > >> On Mar 5, 2019, at 11:06 AM, Weijun Wang wrote: >> >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8157404/webrev.00/ >> >> When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes. >> >> A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases. >> >> Note this could block but it should only happen when data is not enough, and it only reads one byte. >> >> The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data. >> >> And I'm running a mach5 test job now. >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Thu Mar 28 12:20:29 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 Mar 2019 20:20:29 +0800 Subject: 8219861: Add new keytool -tls command for displaying TLS configuration information Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8219861/webrev.01/ The ShowInfo::tls method is extracted from the JSSE Provider doc [1]. Noreg-other? Thanks, Max [1] https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 From xuelei.fan at oracle.com Thu Mar 28 14:50:56 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Mar 2019 07:50:56 -0700 Subject: RFR [13] JDK-8168261: Use server cipher suites preference by default In-Reply-To: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com> References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com> Message-ID: <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com> ping ... Xuelei On 3/21/2019 8:24 PM, Xuelei Fan wrote: > Hi, > > Could I get the update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/ > > With this update, server cipher suite preference will be used by default > for TLS handshaking in the SunJSSE provider.? For more details, please > refer to CSR: > ?? https://bugs.openjdk.java.net/browse/JDK-8219657 > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Mar 28 14:50:10 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Mar 2019 07:50:10 -0700 Subject: RFR [13] JDK-8163326: Update the default enabled cipher suites preference In-Reply-To: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com> References: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com> Message-ID: <23208a33-0b70-4f25-2c8e-61b36f112e5f@oracle.com> ping ... Xuelei On 3/22/2019 7:51 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8163326/webrev.00/ > > With this update, the SunJSSE default enabled cipher suites preference > is adjusted accordingly.? For more details, please refer to CSR: > ??? https://bugs.openjdk.java.net/browse/JDK-8219545 > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Mar 28 14:52:59 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 28 Mar 2019 07:52:59 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> References: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> Message-ID: ping ... Xuelei On 3/22/2019 2:02 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8217610/webrev.00/ > > For EC key exchange in TLS connections, the private key should use the > specified EC groups.? The current code is calling > ECPrivateKey.getParams().? However, the private key may be not an > instance of ECPrivateKey, for example for non-extractable private key in > the SunPKCS11 provider. > > To fix the tricky bug, in this update, if private key is an instance of > ECPrivateKey, use it; otherwise, try to check the groups in the public > key of the X.509 certificate bound to the private key. > > No hardware to reproduce the issue, and no new regression test.? The > update is straightforward.? Please help to check the patch if you can > play with a hardware token. > > Thanks, > Xuelei From sean.mullan at oracle.com Thu Mar 28 19:33:29 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 28 Mar 2019 15:33:29 -0400 Subject: RFR [13] JDK-8168261: Use server cipher suites preference by default In-Reply-To: <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com> References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com> <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com> Message-ID: On 3/28/19 10:50 AM, Xuelei Fan wrote: > ping ... > > Xuelei > > On 3/21/2019 8:24 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the update reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/ >> >> With this update, server cipher suite preference will be used by >> default for TLS handshaking in the SunJSSE provider.? For more >> details, please refer to CSR: >> ??? https://bugs.openjdk.java.net/browse/JDK-8219657 Can you explain why the change in SSLContextSpi was necessary? Also, why do we need to override the engine methods in SSLContextImpl? Probably something simple, but not seeing the reason just from the diffs ... --Sean From xuelei.fan at oracle.com Fri Mar 29 15:23:13 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 Mar 2019 08:23:13 -0700 Subject: RFR [13] JDK-8168261: Use server cipher suites preference by default In-Reply-To: References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com> <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com> Message-ID: On 3/28/2019 12:33 PM, Sean Mullan wrote: > On 3/28/19 10:50 AM, Xuelei Fan wrote: >> ping ... >> >> Xuelei >> >> On 3/21/2019 8:24 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the update reviewed? >>> ??? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/ >>> >>> With this update, server cipher suite preference will be used by >>> default for TLS handshaking in the SunJSSE provider.? For more >>> details, please refer to CSR: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657 > > Can you explain why the change in SSLContextSpi was necessary? > There is a bug in the implementation. The spec says: "The default implementation obtains the parameters from an SSLSocket ..." The parameters should be populated by the socket. > Also, why do we need to override the engine methods in SSLContextImpl? > Probably something simple, but not seeing the reason just from the diffs > ... > The SSLContextSpi implementation uses default SSLSocket instance for the parameters, which does not apply to DTLS protocols as the SunJSSE provider does not support DTLS protocols. If we update SSLContextSpi within this update, the SSLContextImpl update is not necessary any more. Here is the new webrev that removes the SSLContextImpl update: http://cr.openjdk.java.net/~xuelei/8168261/webrev.01/ Thanks, Xuelei From mbalao at redhat.com Fri Mar 29 16:05:26 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 29 Mar 2019 13:05:26 -0300 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> Message-ID: <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com> Hi Valerie, Thanks for having a look at this proposal. On 3/25/19 9:03 PM, Valerie Peng wrote: > > Thanks for trying to address this "free-wrapper-key" issue. However, > changes in the key clean up/free area is difficult to verify and check > for issues and I am a little concerned that this new model may be hard > to trace when the key id is mutable and potentially fragile/error prone > for future changes/fixes. I agree in that there is some complexity involved, but it is not much different than the one we have dealt with before in this whole "memory leak" fix. > > My questions/feedbacks on current changes are: > > 1) line 1283: ref may be null (see line 1220) and this will lead to NPE? For line 1283 to be executed, nativeKeyInfo has to be non-null (see line 1264). When nativeKeyInfo is non-null, a SessionKeyRef instance is always assigned to a "ref" variable, and no execution path can set "ref" back to null -we removed the previous "this.ref = this.ref.dispose()" line-. This is not by-chance, this is because we now keep SessionKeyRef instances always alive when there is native key info extracted. Previous to this patch, a SessionKeyRef instance was alive only while there was a native key created. The reason for this change, as I said, is that SessionKeyRef instances now protect not only a created native key but a wrapper key that may have been used to encrypt the extracted native key information. > > 2) It looks like you don't really need to store the "wrapperKeyUsed" > value in both NativeKeyHolder and SessionKeyRef classes. It can be a > local variable for NativeKeyHolder class and the increment of > nativeKeyWrapperRefCount can be moved to SessionKeyRef constructor.? The > counter nativeKeyWrapperRefCount is incremented inside NativeKeyHolder > constructor Yes, I thought about that when coming to the proposed patch but was not convinced for clarity and safety reasons. When a wrapper key does not exist and has to be created, we must exit the creation block with the reference counter incremented to protect the key. Otherwise, a race condition is possible: while one thread creates the native key but still does not increment the reference counter, a short-living object may destroy the wrapper key. Moving the whole creation block to the SessionKeyRef constructor is less clear to me -see below-. > > 3) I have not spent as much time as you on tracing this. However, I > think we should be able to keep the "final keyID" approach and handle > the NativeKeyWrapperRefCount inc/dec in SessionKeyRef > constructor/dispose methods. Have you tried this? Keeping the "final keyID" approach is creating different SessionKeyRef instances every time a native key is created. However, this approach does not have a SessionKeyRef instance when there is extracted native key information but there isn't a native key created. Now suppose that this extracted native key information is protected by a wrapper key and that the P11Key gets garbage-collected. There is no one to decrement the reference counter and the wrapper key will be always alive. > > 4) It may not be enough to just run tests under sun/security/pkcs11, as > SunPKCS11 provider is used by many other JDK security components such as > TLS. To be safe, you should submit the test against jdk-tier1,jdk-tier2 > to check for possible regressions. If you can't, please let me know. > I'm not exactly sure how can I do that but sounds good. If I cannot find public information, I'll ask you for help. Thanks, Martin.- From weijun.wang at oracle.com Sat Mar 30 13:32:35 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 30 Mar 2019 21:32:35 +0800 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com> References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com> Message-ID: > On Mar 27, 2019, at 11:48 PM, Xuelei Fan wrote: > > DerIndefLenConverter.convertStream(). > > Is it a concern that this method read too much? For example, the DER bytes of the target object is 256 bytes, but read 1024 bytes from the input stream. And then the next DER or other object in the inputstream may not be able to properly parsed. Yes, this is possible, but I am not going to deal with it here. > > BTW, if the input stream is a slow traffic, there might be a few DataNotEnoughException get thrown. Throwing and catching of exceptions are expensive. I may divide the convertBytes() into two parts, one looking for the DER ending position, the other one converting to DER encoding. Then the DataNotEnoughException in convertStream() could be avoided. You mean still using the same logic but just not with an exception? Can I just return null? Thanks, Max > > Thanks, > Xuelei > > On 3/24/2019 7:42 PM, Weijun Wang wrote: >> Ping again. >> No new test added. >> Thanks, >> Max >>> On Mar 5, 2019, at 11:06 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> https://cr.openjdk.java.net/~weijun/8157404/webrev.00/ >>> >>> When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes. >>> >>> A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases. >>> >>> Note this could block but it should only happen when data is not enough, and it only reads one byte. >>> >>> The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data. >>> >>> And I'm running a mach5 test job now. >>> >>> Thanks, >>> Max >>> From weijun.wang at oracle.com Sat Mar 30 15:01:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 30 Mar 2019 23:01:18 +0800 Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <1550666474.2433.13.camel@paratix.ch> References: <1550666474.2433.13.camel@paratix.ch> Message-ID: <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> Hi Philipp, Sorry I'm so late giving a response. I've filed https://bugs.openjdk.java.net/browse/JDK-8221719 Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case The fix is good. Since we don't support identitydb anymore I think we can remove the parenthesis around the alias in the storeHash now. Thanks, Max > On Feb 20, 2019, at 8:41 PM, Philipp Kunz wrote: > > Hi, > > When signing a jarfile the specified alias is converted by JavaKeyStore (storetype JKS) to lower case. > When verifying the jarfile with the same alias, it is currently not converted by JKS to lower case and jarsigner reports that the jar is not signed by the alias even after having just signed it with that same alias if not all characters are in lower case. > > I found no statement in the documentation that an alias would support only lower case or which characters could be used. It could, however, be worth noting in the documentation of JavaKeyStore or the keytool that the alias can be changed by the keystore in certain circumstances. > In my opinion, it feels like a bug that aliases are treated differently when signing and verifying with respect to their upper and lower case. > > Find a patch attached. Some explanations, just in case not too obvious anyway: > > - The jarsigner never changed the upper and lower cases of aliases itself and neither does with the patch. That is now delegated to the keystore implementation not only for signing but in addition also for verifying. The fix is therefore not JSK-specific. > - I assume it is correct that the if (store != null) check and the try catch KeyStoreException can both be moved outside the for loop over the certificates because before as well as now with the patch the result was alway 0 if store was null and KeyStoreException can happen only when loading the keystore, which is certainly true for JKS. > - storeHash is used only by printCert and inKeyStoreForOneSigner and contains the aliases as values enclosed in parentheses "(" and ")" which is how it is printed by printCert. It would have probably been easier to add the parentheses only later in printCert but then I tried to change as little as possible. > - Two pairs of "result |= " statements were duplicate. Therefore there are the two methods in the test which show that both actually failed with "ckaliases.contains" being the offending piece of code. In the patch I refactored to recombine them. > - I really wonder how "result |= SIGNED_BY_ALIAS;" should be set for any certificate c and not only the one an alias in ckaliases points at but I guess that is another story if one at all and might have come from filling storeHash with all certificates and not only the ones in ckaliases or so. > - At first glance it might look like a mistake that "alias" is not used inside the loop over ckaliases but instead of comparing "alias" in lower case to ckaliases with unspecified case, the certificate c is now compared to the one gotten from the keystore handling the alias case in its own way. > > Would someone sponsor this fix or can/should it be improved? > > Regards, > Philipp > From raell at web.de Tue Mar 26 10:18:47 2019 From: raell at web.de (raell at web.de) Date: Tue, 26 Mar 2019 10:18:47 -0000 Subject: Release plan for ChaCha20/Poly1305 cipher suite In-Reply-To: References: Message-ID: Great! Thank you Bradford and Jamil. ? -- Ralph ? On 3/26 0:14:24 AM, Bradford Wetmore wrote: >Please see the SunJSSE provider documentation for JDK 12. > >https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 > >Brad > > >On 3/25/2019 4:17 PM, raell at web.de wrote: >> Dear, >> >> in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is neither part of Java 12. >> >> Out of interest: Is there a plan in which Java release the cipher suite will be supported. >> >> Thanks and regards, >> >> Ralph >>