From xuelei.fan at oracle.com Mon Apr 1 14:16:46 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Apr 2019 07:16:46 -0700 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: 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 3/30/2019 6:32 AM, Weijun Wang wrote: > > >> 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. > Okay. Do you plan to file a new bug? >> >> 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? > Yes. Returning null should be fine as well. Xuelei > 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 Mon Apr 1 14:53:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Apr 2019 22:53:49 +0800 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com> Message-ID: Webrev updated at https://cr.openjdk.java.net/~weijun/8157404/webrev.01/ > On Apr 1, 2019, at 10:16 PM, Xuelei Fan wrote: > > On 3/30/2019 6:32 AM, Weijun Wang wrote: >>> 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. > Okay. Do you plan to file a new bug? Cannot access JBS. I'll remember to file one. Thanks, Max > >>> >>> 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? > Yes. Returning null should be fine as well. > > Xuelei > >> 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 xuelei.fan at oracle.com Mon Apr 1 15:09:13 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Apr 2019 08:09:13 -0700 Subject: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream In-Reply-To: References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com> <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com> <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com> Message-ID: <8c953912-622e-78d7-72db-342b03c731e3@oracle.com> Looks fine to me. Thanks, Xuelei On 4/1/2019 7:53 AM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8157404/webrev.01/ > >> On Apr 1, 2019, at 10:16 PM, Xuelei Fan wrote: >> >> On 3/30/2019 6:32 AM, Weijun Wang wrote: >>>> 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. >> Okay. Do you plan to file a new bug? > > Cannot access JBS. I'll remember to file one. > > Thanks, > Max > >> >>>> >>>> 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? >> Yes. Returning null should be fine as well. >> >> Xuelei >> >>> 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 sean.mullan at oracle.com Mon Apr 1 17:10:59 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 Apr 2019 13:10:59 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings Message-ID: It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. bug: https://bugs.openjdk.java.net/browse/JDK-8020637 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ Thanks, Sean From sean.mullan at oracle.com Mon Apr 1 19:34:28 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 Apr 2019 15:34:28 -0400 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/29/19 11:23 AM, Xuelei Fan wrote: > 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/ Ok, looks good. --Sean From vladimir.kozlov at oracle.com Mon Apr 1 21:44:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 1 Apr 2019 14:44:54 -0700 Subject: [13] RFR(S) 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services Message-ID: https://bugs.openjdk.java.net/browse/JDK-8221782 Recent 'Update Graal' JDK-8221341 added import jdk.vm.ci.services.Services class to HotSpotGraalRuntimeMBean.java. JVMCI module-info.java was updated accordingly [1] but src/java.base/share/lib/security/default.policy file was not. Ran failed java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java test. diff -r 18547cad9ec6 src/java.base/share/lib/security/default.policy --- a/src/java.base/share/lib/security/default.policy +++ b/src/java.base/share/lib/security/default.policy @@ -160,6 +160,7 @@ grant codeBase "jrt:/jdk.internal.vm.compiler.management" { permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.vm.compiler.collections"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.runtime"; + permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.services"; permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.core.common"; permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.debug"; permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"; -- Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/dd5c64326027/src/jdk.internal.vm.ci/share/classes/module-info.java#l27 From weijun.wang at oracle.com Tue Apr 2 02:10:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Apr 2019 10:10:49 +0800 Subject: RFR 8221801: Update src/java.base/share/legal/public_suffix.md Message-ID: I missed a file last time updating the PSL file, please take a review https://cr.openjdk.java.net/~weijun/8221801/webrev.00 Thanks, Max From xuelei.fan at oracle.com Tue Apr 2 02:51:13 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Apr 2019 19:51:13 -0700 Subject: RFR 8221801: Update src/java.base/share/legal/public_suffix.md In-Reply-To: References: Message-ID: <8b085d65-8ba1-3622-9a73-e966955ea490@oracle.com> Looks fine to me. Xuelei On 4/1/2019 7:10 PM, Weijun Wang wrote: > I missed a file last time updating the PSL file, please take a review > > https://cr.openjdk.java.net/~weijun/8221801/webrev.00 > > Thanks, > Max > From weijun.wang at oracle.com Tue Apr 2 03:12:34 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Apr 2019 11:12:34 +0800 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: References: Message-ID: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> I can understand the change in Permissions, but is there any difference in PermissionsHash? --Max > On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: > > It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. > > This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. > > bug: https://bugs.openjdk.java.net/browse/JDK-8020637 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ > > Thanks, > Sean > From david.holmes at oracle.com Tue Apr 2 05:03:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Apr 2019 15:03:24 +1000 Subject: RFR (S): 8213233: [TESTBUG] re-evaluate test/hotspot/jtreg/runtime/JVMDoPrivileged tests following JDK-8212605 Message-ID: <8e69d454-8739-0178-bb24-3c5e945b2519@oracle.com> Hi Security-libs team, webrev: http://cr.openjdk.java.net/~dholmes/8213233/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8213233 Now that doPrivileged is Java-based these older runtime regression tests don't really belong in runtime any longer. I'd like to hg move them to test/jdk/java/security/AccessController Thanks, David From Alan.Bateman at oracle.com Tue Apr 2 06:56:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Apr 2019 07:56:27 +0100 Subject: [13] RFR(S) 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services In-Reply-To: References: Message-ID: <52d17eea-d7f8-45f1-6277-05b97f9a4af3@oracle.com> On 01/04/2019 22:44, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8221782 > > Recent 'Update Graal' JDK-8221341 added import > jdk.vm.ci.services.Services class to HotSpotGraalRuntimeMBean.java. > JVMCI module-info.java was updated accordingly [1] but > src/java.base/share/lib/security/default.policy file was not. > > Ran failed > java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java test. > > diff -r 18547cad9ec6 src/java.base/share/lib/security/default.policy > --- a/src/java.base/share/lib/security/default.policy > +++ b/src/java.base/share/lib/security/default.policy > @@ -160,6 +160,7 @@ > ?grant codeBase "jrt:/jdk.internal.vm.compiler.management" { > ???? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.internal.vm.compiler.collections"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.vm.ci.runtime"; > +??? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.vm.ci.services"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.core.common"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.debug"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.hotspot"; This looks okay. -Alan From sean.mullan at oracle.com Tue Apr 2 12:47:28 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Apr 2019 08:47:28 -0400 Subject: RFR (S): 8213233: [TESTBUG] re-evaluate test/hotspot/jtreg/runtime/JVMDoPrivileged tests following JDK-8212605 In-Reply-To: <8e69d454-8739-0178-bb24-3c5e945b2519@oracle.com> References: <8e69d454-8739-0178-bb24-3c5e945b2519@oracle.com> Message-ID: <25928787-325d-53f9-c66c-783ced225f04@oracle.com> Hi David, These tests still seem somewhat VM-specific to me. We don't have any *.jasm files in our tests area. Are these tests even relevant anymore now that doPriv is all-Java? The previous bug fix that introduced these tests was entirely in the hotspot code and had to do with default methods not being called in a PrivilegedAction instance. I would be more inclined to just remove these tests unless there is some possibility this could be an issue in Java code, but it seems like that would be a more general issue then and not specific to doPriv because the Java code just invokes PrivilegedAction.run() now. --Sean On 4/2/19 1:03 AM, David Holmes wrote: > Hi Security-libs team, > > webrev: http://cr.openjdk.java.net/~dholmes/8213233/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8213233 > > Now that doPrivileged is Java-based these older runtime regression tests > don't really belong in runtime any longer. I'd like to hg move them to > test/jdk/java/security/AccessController > > Thanks, > David From sean.mullan at oracle.com Tue Apr 2 12:54:09 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Apr 2019 08:54:09 -0400 Subject: [13] RFR(S) 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services In-Reply-To: References: Message-ID: <9c7d7965-fdb7-26b7-ff1c-8c0597592aea@oracle.com> Looks good. For future reference, can you add a link to the bug (8221341) that introduced this regression? --Sean On 4/1/19 5:44 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8221782 > > Recent 'Update Graal' JDK-8221341 added import > jdk.vm.ci.services.Services class to HotSpotGraalRuntimeMBean.java. > JVMCI module-info.java was updated accordingly [1] but > src/java.base/share/lib/security/default.policy file was not. > > Ran failed > java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java test. > > diff -r 18547cad9ec6 src/java.base/share/lib/security/default.policy > --- a/src/java.base/share/lib/security/default.policy > +++ b/src/java.base/share/lib/security/default.policy > @@ -160,6 +160,7 @@ > ?grant codeBase "jrt:/jdk.internal.vm.compiler.management" { > ???? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.internal.vm.compiler.collections"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.vm.ci.runtime"; > +??? permission java.lang.RuntimePermission > "accessClassInPackage.jdk.vm.ci.services"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.core.common"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.debug"; > ???? permission java.lang.RuntimePermission > "accessClassInPackage.org.graalvm.compiler.hotspot"; > From sean.mullan at oracle.com Tue Apr 2 13:33:34 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Apr 2019 09:33:34 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> Message-ID: <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> On 4/1/19 11:12 PM, Weijun Wang wrote: > I can understand the change in Permissions, but is there any difference in PermissionsHash? The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? --Sean > > --Max > >> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >> >> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >> >> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >> >> Thanks, >> Sean >> > From weijun.wang at oracle.com Tue Apr 2 13:44:44 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Apr 2019 21:44:44 +0800 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> Message-ID: > On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: > > On 4/1/19 11:12 PM, Weijun Wang wrote: >> I can understand the change in Permissions, but is there any difference in PermissionsHash? > > The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? Yes, you are right. I thought the old code can also enforce this relation. Now for the test, perms.ser is binary and you haven't described how it is generated. Thanks, Max > > --Sean > >> --Max >>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>> >>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>> >>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>> >>> Thanks, >>> Sean >>> From sean.mullan at oracle.com Tue Apr 2 13:50:08 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Apr 2019 09:50:08 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> Message-ID: On 4/2/19 9:44 AM, Weijun Wang wrote: > > >> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >> >> On 4/1/19 11:12 PM, Weijun Wang wrote: >>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >> >> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? > > Yes, you are right. I thought the old code can also enforce this relation. > > Now for the test, perms.ser is binary and you haven't described how it is generated. I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. --Sean > > Thanks, > Max > >> >> --Sean >> >>> --Max >>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>> >>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>> >>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>> >>>> Thanks, >>>> Sean >>>> > From Roger.Riggs at oracle.com Tue Apr 2 13:55:13 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 2 Apr 2019 09:55:13 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> Message-ID: <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> Hi Sean, Typically, fixed serialization streams are encoded in the source as byte arrays. That keeps binary content out of the repo and provides a place for the comments. Roger On 04/02/2019 09:50 AM, Sean Mullan wrote: > On 4/2/19 9:44 AM, Weijun Wang wrote: >> >> >>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>> >>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>> I can understand the change in Permissions, but is there any >>>> difference in PermissionsHash? >>> >>> The key and value in the PermissionsHash map is always the same >>> object. This fix ensures that is respected, otherwise after >>> deserialization you could have a SocketPermission mapped to a >>> FilePermission, for example. Would it be better if I added a test >>> for that? >> >> Yes, you are right. I thought the old code can also enforce this >> relation. >> >> Now for the test, perms.ser is binary and you haven't described how >> it is generated. > > I just hacked Permissions.writeObject to switch the mappings. That was > a lot easier than trying to write my own serialization code. I will > add some comments in the test explaining how I did that and what is in > perms.ser. > > --Sean > > >> >> Thanks, >> Max >> >>> >>> --Sean >>> >>>> --Max >>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan >>>>> wrote: >>>>> >>>>> It is currently possible to change the mappings in a serialized >>>>> java.security.Permissions object such that they no longer map >>>>> correctly, and Permissions.readObject won't detect this. >>>>> >>>>> This change makes sure that for a deserialized Permissions object, >>>>> the permissions are mapped correctly to the class that they belong >>>>> to. It does this by calling add() again for each permission in the >>>>> deserialized Permissions object. The same technique was applied to >>>>> a serialized PermissionsHash object which is used to store >>>>> Permissions that don't implement their own PermissionCollection. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>> >>>>> Thanks, >>>>> Sean >>>>> >> From weijun.wang at oracle.com Tue Apr 2 14:03:10 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Apr 2019 22:03:10 +0800 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> Message-ID: <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> +1. --Max > On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote: > > Hi Sean, > > Typically, fixed serialization streams are encoded in the source > as byte arrays. That keeps binary content out of the repo > and provides a place for the comments. > > Roger > > > On 04/02/2019 09:50 AM, Sean Mullan wrote: >> On 4/2/19 9:44 AM, Weijun Wang wrote: >>> >>> >>>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>>> >>>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >>>> >>>> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? >>> >>> Yes, you are right. I thought the old code can also enforce this relation. >>> >>> Now for the test, perms.ser is binary and you haven't described how it is generated. >> >> I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. >> >> --Sean >> >> >>> >>> Thanks, >>> Max >>> >>>> >>>> --Sean >>>> >>>>> --Max >>>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>>>> >>>>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>>>> >>>>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Sean >>>>>> >>> > From vladimir.kozlov at oracle.com Tue Apr 2 16:04:50 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Apr 2019 09:04:50 -0700 Subject: [13] RFR(S) 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services In-Reply-To: <9c7d7965-fdb7-26b7-ff1c-8c0597592aea@oracle.com> References: <9c7d7965-fdb7-26b7-ff1c-8c0597592aea@oracle.com> Message-ID: <34696eba-53ca-a25e-ad26-48dedbd754ef@oracle.com> Thank you, Sean I added link to bug report as you suggested. Vladimir On 4/2/19 5:54 AM, Sean Mullan wrote: > Looks good. For future reference, can you add a link to the bug (8221341) that introduced this regression? > > --Sean > > On 4/1/19 5:44 PM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8221782 >> >> Recent 'Update Graal' JDK-8221341 added import jdk.vm.ci.services.Services class to HotSpotGraalRuntimeMBean.java. >> JVMCI module-info.java was updated accordingly [1] but src/java.base/share/lib/security/default.policy file was not. >> >> Ran failed java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java test. >> >> diff -r 18547cad9ec6 src/java.base/share/lib/security/default.policy >> --- a/src/java.base/share/lib/security/default.policy >> +++ b/src/java.base/share/lib/security/default.policy >> @@ -160,6 +160,7 @@ >> ??grant codeBase "jrt:/jdk.internal.vm.compiler.management" { >> ????? permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.vm.compiler.collections"; >> ????? permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.runtime"; >> +??? permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.services"; >> ????? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.core.common"; >> ????? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.debug"; >> ????? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"; >> From vladimir.kozlov at oracle.com Tue Apr 2 15:43:53 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Apr 2019 08:43:53 -0700 Subject: [13] RFR(S) 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services In-Reply-To: <52d17eea-d7f8-45f1-6277-05b97f9a4af3@oracle.com> References: <52d17eea-d7f8-45f1-6277-05b97f9a4af3@oracle.com> Message-ID: <9442be6a-0444-9aba-15f3-9a7d074d35d5@oracle.com> Thank you, Alan Vladimir On 4/1/19 11:56 PM, Alan Bateman wrote: > On 01/04/2019 22:44, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8221782 >> >> Recent 'Update Graal' JDK-8221341 added import jdk.vm.ci.services.Services class to HotSpotGraalRuntimeMBean.java. >> JVMCI module-info.java was updated accordingly [1] but src/java.base/share/lib/security/default.policy file was not. >> >> Ran failed java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java test. >> >> diff -r 18547cad9ec6 src/java.base/share/lib/security/default.policy >> --- a/src/java.base/share/lib/security/default.policy >> +++ b/src/java.base/share/lib/security/default.policy >> @@ -160,6 +160,7 @@ >> ?grant codeBase "jrt:/jdk.internal.vm.compiler.management" { >> ???? permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.vm.compiler.collections"; >> ???? permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.runtime"; >> +??? permission java.lang.RuntimePermission "accessClassInPackage.jdk.vm.ci.services"; >> ???? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.core.common"; >> ???? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.debug"; >> ???? permission java.lang.RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"; > This looks okay. > > -Alan > From valerie.peng at oracle.com Tue Apr 2 19:35:24 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 2 Apr 2019 12:35:24 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: References: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> Message-ID: Hmm, I didn't see the SignatureScheme.java in the webrev? The stacktrace in the bug record shows the casting being inside SignatureScheme class. Did I miss something? Valerie On 3/28/2019 7:52 AM, Xuelei Fan wrote: > 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 ivan.gerasimov at oracle.com Tue Apr 2 21:52:17 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 2 Apr 2019 14:52:17 -0700 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md Message-ID: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Hello! I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. The modification is straight-forward. WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ Would you please help review? -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Tue Apr 2 22:32:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Apr 2019 08:32:23 +1000 Subject: RFR (S): 8213233: [TESTBUG] re-evaluate test/hotspot/jtreg/runtime/JVMDoPrivileged tests following JDK-8212605 In-Reply-To: <25928787-325d-53f9-c66c-783ced225f04@oracle.com> References: <8e69d454-8739-0178-bb24-3c5e945b2519@oracle.com> <25928787-325d-53f9-c66c-783ced225f04@oracle.com> Message-ID: Hi Sean, On 2/04/2019 10:47 pm, Sean Mullan wrote: > Hi David, > > These tests still seem somewhat VM-specific to me. We don't have any > *.jasm files in our tests area. Are these tests even relevant anymore > now that doPriv is all-Java? The previous bug fix that introduced these > tests was entirely in the hotspot code and had to do with default > methods not being called in a PrivilegedAction instance. The existence of the bug shows that there were no existing functional tests for that particular usage scenario (else we'd have encountered it much sooner). But the bug was in VM functionality that would only be used in that one usage context. Now the code is in Java we're using the regular VM method lookup and selection processes which are of course being exercised by every test. In essence we're now relying on composition of two features (AccessController API and default methods) working correctly by virtue of each feature working correctly on its own. > I would be more > inclined to just remove these tests unless there is some possibility > this could be an issue in Java code, but it seems like that would be a > more general issue then and not specific to doPriv because the Java code > just invokes PrivilegedAction.run() now. Okay. I'll either delete it or keep it, but won't move it. Thanks, David > --Sean > > On 4/2/19 1:03 AM, David Holmes wrote: >> Hi Security-libs team, >> >> webrev: http://cr.openjdk.java.net/~dholmes/8213233/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8213233 >> >> Now that doPrivileged is Java-based these older runtime regression >> tests don't really belong in runtime any longer. I'd like to hg move >> them to test/jdk/java/security/AccessController >> >> Thanks, >> David From weijun.wang at oracle.com Wed Apr 3 00:46:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Apr 2019 08:46:02 +0800 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md In-Reply-To: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> References: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Message-ID: Hi Ivan, Code change looks fine to me. The system property is also new to me and it saved a lot of "../../..". Thanks, Max > On Apr 3, 2019, at 5:52 AM, Ivan Gerasimov wrote: > > Hello! > > I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. > > Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. > > The modification is straight-forward. > > WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ > > Would you please help review? > > -- > With kind regards, > Ivan Gerasimov > From ivan.gerasimov at oracle.com Wed Apr 3 00:53:29 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 2 Apr 2019 17:53:29 -0700 Subject: [12u] RFR 8221801 : Update src/java.base/share/legal/public_suffix.md In-Reply-To: References: <51ef833a-e67b-1c77-6064-262e53828dc6@oracle.com> Message-ID: <6db5e007-13c5-7ac4-63b1-c9428edf2b1d@oracle.com> Thank you Weijun! On 4/2/19 5:46 PM, Weijun Wang wrote: > Hi Ivan, > > Code change looks fine to me. The system property is also new to me and it saved a lot of "../../..". > > Thanks, > Max > >> On Apr 3, 2019, at 5:52 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> I'm seeking to backport the fix to 12u, and the corresponding regression test had to be slightly edited. >> >> Turns out that Mach5 runs jtreg4.2-b13 for 12u builds, and that version does not support "test.root" system property. >> >> The modification is straight-forward. >> >> WEBREV: http://cr.openjdk.java.net/~igerasim/8221801/00/webrev/ >> >> Would you please help review? >> >> -- >> With kind regards, >> Ivan Gerasimov >> > -- With kind regards, Ivan Gerasimov From xuelei.fan at oracle.com Wed Apr 3 03:12:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 2 Apr 2019 20:12:00 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE Message-ID: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ To benefits from with Fibers [1], there is a need to use explicit locks, java.util.concurrent.locks, for synchronization in JSSE and the SunJSSE provider. Most of the update is replacing synchronized blocks with java.util.concurrent.locks.ReentrantLock locking/unlocking. Thanks, Xuelei [1]: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html From xuelei.fan at oracle.com Wed Apr 3 03:45:02 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 2 Apr 2019 20:45:02 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: References: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> Message-ID: <62f9ffcc-9a64-a289-2be7-4b37e5a34978@oracle.com> Good catch! I missed the update for SignatureScheme. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/ Thanks, Xuelei On 4/2/2019 12:35 PM, Valerie Peng wrote: > > Hmm, I didn't see the SignatureScheme.java in the webrev? The stacktrace > in the bug record shows the casting being inside SignatureScheme class. > Did I miss something? > > Valerie > > On 3/28/2019 7:52 AM, Xuelei Fan wrote: >> 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 Alan.Bateman at oracle.com Wed Apr 3 08:03:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Apr 2019 09:03:43 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Message-ID: On 03/04/2019 04:12, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ > > To benefits from with Fibers [1], there is a need to use explicit > locks, java.util.concurrent.locks, for synchronization in JSSE and the > SunJSSE provider. > > Most of the update is replacing synchronized blocks with > java.util.concurrent.locks.ReentrantLock locking/unlocking. I looked through the changes and don't see anything obviously wrong. When you say "Most of the updates ..." then does it mean they are some changes that aren't equivalent? It would be useful to call those out. One other about switching from monitors to explicit locks is calling out any classes that extend classes that use synchronization and assume that sub-classes do the same. In passed I see a few places where the locking might be excessive, e.g. I assume SSLContext.defaultContext could be a volatile so that getDefault just needs to return it when it's not null. I'm not suggesting you do those changes now but looking at the locking suggests there may be a few places that could be improved. -Alan From ecki at zusammenkunft.net Wed Apr 3 09:32:38 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 3 Apr 2019 09:32:38 +0000 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Message-ID: Hello, There are a few places where a synchronized method is freed up w/o new lock, which is generally a good thing but I wonder if there is a justification available why it is no problem (DTLSInputRecord vs. DTLSOutputRecord). Is the DCL In EphemeralKepair Safe, I am not sure how arrays and not beeing volatile mixes? Is there an undesired spacing change in a SSlEngineImpl.java and SSLSocketOutputRecord.java (or is this a webrev artifact)? The additional use of the SSLEngineOutputRecord lock in close, is this fine? (It could block the close() if the lock is held) >From a commit description point of few removing of unneeded Synchronisation or replacing them with a holder pattern and introducing DCL is a very positive thing which should be mentioned in the description I think? And an aside, is this a general direction the JCL has to go for loom to remove synchronized methods and blocks? Those ex synchronized methods look a lot more ugly with the try/final (especially since there is no TWR autoclose) and the additional locks also increase the footprint. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Mittwoch, April 3, 2019 6:48 AM An: security-dev at openjdk.java.net; Alan Bateman Betreff: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ To benefits from with Fibers [1], there is a need to use explicit locks, java.util.concurrent.locks, for synchronization in JSSE and the SunJSSE provider. Most of the update is replacing synchronized blocks with java.util.concurrent.locks.ReentrantLock locking/unlocking. Thanks, Xuelei [1]: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Apr 3 18:40:27 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 3 Apr 2019 11:40:27 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Message-ID: Updated webrev (updated SSLContext.java, HttpsClient, HttpsURLConnectionImpl): http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/ On 4/3/2019 1:03 AM, Alan Bateman wrote: > On 03/04/2019 04:12, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ >> >> To benefits from with Fibers [1], there is a need to use explicit >> locks, java.util.concurrent.locks, for synchronization in JSSE and the >> SunJSSE provider. >> >> Most of the update is replacing synchronized blocks with >> java.util.concurrent.locks.ReentrantLock locking/unlocking. > I looked through the changes and don't see anything obviously wrong. > When you say "Most of the updates ..." then does it mean they are some > changes that aren't equivalent? It would be useful to call those out. Other than the straightforward replacing 'synchronized' with explicit lock, there are some code clean-up: 1. Replacing 'synchronized' blocks with lazy initialization holder for static fields, for SSLServerSocketFactory.getDefault() and SSLSocketFactory.getDefault(). 2. Removing the 'synchronized' modifier that is not really necessary, for BaseSSLSocketImpl.setSoTimeout(), DTLSInputRecord.close(), HttpsURLConnectionImpl.getIn/OutputStream(). 3. Removing the 'synchronized' modifier by re-org to use final filed, for SunX509KeyManagerImpl#X509Credentials.getIssuerX500Principals(). 4. Removing the the 'synchronized' modifier by re-org to use volatile field, for SSLContext.s/getDefault(). > One other about switching from monitors to explicit locks is calling out > any classes that extend classes that use synchronization and assume that > sub-classes do the same. > > In passed I see a few places where the locking might be excessive, e.g. > I assume SSLContext.defaultContext could be a volatile so that > getDefault just needs to return it when it's not null. I'm not > suggesting you do those changes now but looking at the locking suggests > there may be a few places that could be improved. > As we are already here, I would like to make the improvement for SSLContext. I believe there are also some other improvement we could do. I make more evaluation later. Thanks, Xuelei From xuelei.fan at oracle.com Wed Apr 3 18:57:50 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 3 Apr 2019 11:57:50 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Message-ID: <06d31fc6-e85e-f544-6070-4cae4753c9bf@oracle.com> On 4/3/2019 2:32 AM, Bernd Eckenfels wrote: > Hello, > > There are a few places where a synchronized method is freed up w/o new > lock, which is generally a good thing but I wonder if there is a > justification available why it is no problem (DTLSInputRecord vs. > DTLSOutputRecord). > For DTLSInputRecord.close(), the isClosed variable cannot be reset from true to false, so it is safe to use the lock in super.close(); For DTLSOutputRecord, the close() method may set the "isCloseWaiting" filed, so additional lock is required here. > Is the DCL In EphemeralKepair Safe, I am not sure how arrays and not > beeing volatile mixes? > I think it is safe as once the array items get set, it won't change. As the set process is locked and double checked, it is not necessary to use volatile modifier for the array items. > Is there an undesired spacing change in a ?SSlEngineImpl.java and > SSLSocketOutputRecord.java (or is this a webrev artifact)? > Would you mind tell me the line numbers? I did not catch them. Might be a webrev artifact. > The additional use of the SSLEngineOutputRecord lock in close, is this > fine? (It could block the close() if the lock is held) > Good catch. It could be a potential issue. I'm working on it in anther bug. I will not touch the issue as the update is not as straightforward as I can see now. > From a commit description point of few removing of unneeded > Synchronisation or replacing them with a holder pattern and introducing > DCL is a very positive thing which should be mentioned in the > description I think? > Good point! I added more description in another reply in the thread. > And an aside, is this a general direction the JCL has to go for loom to > remove synchronized methods and blocks? Those ex synchronized methods > look a lot more ugly with the try/final (especially since there is no > TWR autoclose) and the additional locks also increase the footprint. > Loom is still in progress. I'm not sure of the final spec yet. Thanks for review! Xuelei > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Xuelei Fan > *Gesendet:* Mittwoch, April 3, 2019 6:48 AM > *An:* security-dev at openjdk.java.net; Alan Bateman > *Betreff:* RFR [13] JDK-8221882: Use fiber-friendly > java.util.concurrent.locks in JSSE > Hi, > > Could I get the following update reviewed? > http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/ > > To benefits from with Fibers [1], there is a need to use explicit locks, > java.util.concurrent.locks, for synchronization in JSSE and the SunJSSE > provider. > > Most of the update is replacing synchronized blocks with > java.util.concurrent.locks.ReentrantLock locking/unlocking. > > Thanks, > Xuelei > [1]: http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html From Alan.Bateman at oracle.com Wed Apr 3 19:06:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Apr 2019 20:06:52 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> Message-ID: <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> On 03/04/2019 19:40, Xuelei Fan wrote: > Updated webrev (updated SSLContext.java, HttpsClient, > HttpsURLConnectionImpl): > ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/ > This looks good to me, the only change that I'm not 100% sure on is in HttpsClient where the locking will not be consistent with the locking in the HttpClient super class. Would you mind doubling checking that one? We do need to change the HTTP protocol handler so I expect HttpClient will change but it may have to add a protected lock that HttpsClient uses to ensure that they are using the same lock. > As we are already here, I would like to make the improvement for > SSLContext. I believe there are also some other improvement we could > do. ?I make more evaluation later. Thanks. -Alan From xuelei.fan at oracle.com Wed Apr 3 19:33:41 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 3 Apr 2019 12:33:41 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> Message-ID: <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> On 4/3/2019 12:06 PM, Alan Bateman wrote: > On 03/04/2019 19:40, Xuelei Fan wrote: >> Updated webrev (updated SSLContext.java, HttpsClient, >> HttpsURLConnectionImpl): >> ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/ >> > This looks good to me, the only change that I'm not 100% sure on is in > HttpsClient where the locking will not be consistent with the locking in > the HttpClient super class. Would you mind doubling checking that one? > We do need to change the HTTP protocol handler so I expect HttpClient > will change but it may have to add a protected lock that HttpsClient > uses to ensure that they are using the same lock. > Hm, the update is problematic. Thanks for the catching! It might be better to make the update together with other http code in another enhancement. I'd like not update the HttpsClient update this time. new webrev (remove update for HttpsClient.java): http://cr.openjdk.java.net/~xuelei/8221882/webrev.02/ Thanks, Xuelei From valerie.peng at oracle.com Wed Apr 3 19:58:00 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Apr 2019 12:58:00 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: <62f9ffcc-9a64-a289-2be7-4b37e5a34978@oracle.com> References: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com> <62f9ffcc-9a64-a289-2be7-4b37e5a34978@oracle.com> Message-ID: Changes look fine~ Thanks, Valerie On 4/2/2019 8:45 PM, Xuelei Fan wrote: > Good catch!? I missed the update for SignatureScheme. > > Here is the new webrev: > ?? http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/ > > Thanks, > Xuelei > > On 4/2/2019 12:35 PM, Valerie Peng wrote: >> >> Hmm, I didn't see the SignatureScheme.java in the webrev? The >> stacktrace in the bug record shows the casting being inside >> SignatureScheme class. Did I miss something? >> >> Valerie >> >> On 3/28/2019 7:52 AM, Xuelei Fan wrote: >>> 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 Wed Apr 3 20:25:22 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Apr 2019 16:25:22 -0400 Subject: 8219861: Add new keytool -tls command for displaying TLS configuration information In-Reply-To: References: Message-ID: <31d4ec4b-72f9-b61c-8688-d3f35dadd781@oracle.com> On 3/28/19 8:20 AM, Weijun Wang wrote: > 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? Seems ok, unless you want to add a test which adds or removes a suite from the enabled list and then make sure that they are displayed correctly. 36 static void tls(boolean verbose) throws Exception { verbose is never used. 41 ArrayList enabled = new ArrayList( Missing "<>". Same comment on lines 44, 61, 64. Also, you don't need to create the ArrayList for enabled since you are not removing from those lists. You can just do: List enabled = Arrays.asList(ssls.getEnabledProtocols()); 48 System.out.println("Enabled by Default protocols"); I would capitalize "protocols" ("Protocols"). --Sean > > Thanks, > Max > > [1] https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 > From weijun.wang at oracle.com Thu Apr 4 03:15:43 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Apr 2019 11:15:43 +0800 Subject: 8219861: Add new keytool -tls command for displaying TLS configuration information In-Reply-To: <31d4ec4b-72f9-b61c-8688-d3f35dadd781@oracle.com> References: <31d4ec4b-72f9-b61c-8688-d3f35dadd781@oracle.com> Message-ID: <14E7DABA-43B4-45B4-B976-11F722531B16@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8219861/webrev.02 The "Disabled by Default" lists are removed. They could be a little confused. Thanks, Max > On Apr 4, 2019, at 4:25 AM, Sean Mullan wrote: > > On 3/28/19 8:20 AM, Weijun Wang wrote: >> 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? > > Seems ok, unless you want to add a test which adds or removes a suite from the enabled list and then make sure that they are displayed correctly. > > 36 static void tls(boolean verbose) throws Exception { > > verbose is never used. > > 41 ArrayList enabled = new ArrayList( > > Missing "<>". Same comment on lines 44, 61, 64. > > Also, you don't need to create the ArrayList for enabled since you are not removing from those lists. You can just do: > > List enabled = Arrays.asList(ssls.getEnabledProtocols()); > > 48 System.out.println("Enabled by Default protocols"); > > I would capitalize "protocols" ("Protocols"). > > --Sean > >> Thanks, >> Max >> [1] https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 From Alan.Bateman at oracle.com Thu Apr 4 07:36:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Apr 2019 08:36:27 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> Message-ID: <185fbcef-7d66-2625-322c-b72eed7074e5@oracle.com> On 03/04/2019 20:33, Xuelei Fan wrote: > : > > new webrev (remove update for HttpsClient.java): > ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.02/ In HttpsURLConnectionImpl it would be nice if delegate could be final - can the protected constructor marked "for plugin" be removed so this cleanup can be done? Does SSLContext.getInstance("Default") always return the same object? If not then SSLContext.getDefault() may need further work to guarantee that it returns the same default SSLContext object (you can use a var handle to CAS the default instance). The rest looks okay to me. -Alan From daniel.fuchs at oracle.com Thu Apr 4 10:01:48 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 4 Apr 2019 11:01:48 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> Message-ID: Hi Xuelei, I second Alan's suggestion to use VarHandle CAS for getDefault(). Otherwise you will have a race between getDefault() and setDefault() which will be problematic (and could make tests/app fail randomly). WRT default factories I like the new holder class. I wonder if you should bite the bullet and take this opportunity to get rid of the @SuppressWarnings("deprecation") by replacing calls to Class::newInstance by calls to Class::getConstructor, as was done elsewhere in the JDK? HttpsURLConnectionImpl.java: If delegate is not final it should now be volatile. I am not seeing any subclasses of HttpsURLConnectionImpl in JDK 13. I guess 'plugin' meant 'plugin for applets'? InputRecord.java Given that isClosed can only transition from `false` to `true` you could add a fastpath to isClosed(): if (isClosed) return true; // otherwise lock and look at the value again OutputRecord.java and SSLEngineOutputRecord.java: I was wondering why you didn't use the lock in isClosed(), and noticed that OutputRecord declares isClosed as volatile. Which makes me wonder if InputRecord should do the same, and just forget the lock in InputRecord::isClosed? Otherwise it looks all reasonable to me. best regards, -- daniel On 03/04/2019 20:33, Xuelei Fan wrote: > On 4/3/2019 12:06 PM, Alan Bateman wrote: >> On 03/04/2019 19:40, Xuelei Fan wrote: >>> Updated webrev (updated SSLContext.java, HttpsClient, >>> HttpsURLConnectionImpl): >>> ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/ >>> >> This looks good to me, the only change that I'm not 100% sure on is in >> HttpsClient where the locking will not be consistent with the locking >> in the HttpClient super class. Would you mind doubling checking that >> one? We do need to change the HTTP protocol handler so I expect >> HttpClient will change but it may have to add a protected lock that >> HttpsClient uses to ensure that they are using the same lock. >> > Hm, the update is problematic.? Thanks for the catching! > > It might be better to make the update together with other http code in > another enhancement.? I'd like not update the HttpsClient update this time. > > new webrev (remove update for HttpsClient.java): > ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.02/ > > Thanks, > Xuelei From sean.mullan at oracle.com Thu Apr 4 11:49:32 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Apr 2019 07:49:32 -0400 Subject: 8219861: Add new keytool -tls command for displaying TLS configuration information In-Reply-To: <14E7DABA-43B4-45B4-B976-11F722531B16@oracle.com> References: <31d4ec4b-72f9-b61c-8688-d3f35dadd781@oracle.com> <14E7DABA-43B4-45B4-B976-11F722531B16@oracle.com> Message-ID: Looks good. --Sean On 4/3/19 11:15 PM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8219861/webrev.02 > > The "Disabled by Default" lists are removed. They could be a little confused. > > Thanks, > Max > >> On Apr 4, 2019, at 4:25 AM, Sean Mullan wrote: >> >> On 3/28/19 8:20 AM, Weijun Wang wrote: >>> 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? >> >> Seems ok, unless you want to add a test which adds or removes a suite from the enabled list and then make sure that they are displayed correctly. >> >> 36 static void tls(boolean verbose) throws Exception { >> >> verbose is never used. >> >> 41 ArrayList enabled = new ArrayList( >> >> Missing "<>". Same comment on lines 44, 61, 64. >> >> Also, you don't need to create the ArrayList for enabled since you are not removing from those lists. You can just do: >> >> List enabled = Arrays.asList(ssls.getEnabledProtocols()); >> >> 48 System.out.println("Enabled by Default protocols"); >> >> I would capitalize "protocols" ("Protocols"). >> >> --Sean >> >>> Thanks, >>> Max >>> [1] https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 > From weijun.wang at oracle.com Thu Apr 4 12:18:32 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Apr 2019 20:18:32 +0800 Subject: 8219861: Add new keytool -tls command for displaying TLS configuration information In-Reply-To: References: <31d4ec4b-72f9-b61c-8688-d3f35dadd781@oracle.com> <14E7DABA-43B4-45B4-B976-11F722531B16@oracle.com> Message-ID: <34E63805-3D21-4CCF-8A5E-978D962305F2@oracle.com> Thanks. Please also take a review at the release note at https://bugs.openjdk.java.net/browse/JDK-8221983. --Max > On Apr 4, 2019, at 7:49 PM, Sean Mullan wrote: > > Looks good. > > --Sean > > On 4/3/19 11:15 PM, Weijun Wang wrote: >> Webrev updated at >> https://cr.openjdk.java.net/~weijun/8219861/webrev.02 >> The "Disabled by Default" lists are removed. They could be a little confused. >> Thanks, >> Max From jamil.j.nimeh at oracle.com Thu Apr 4 13:08:45 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 4 Apr 2019 06:08:45 -0700 Subject: RFR: [CSR] JDK-8221936: Improvements to SunJCE implementation of PBES2 Parameters Message-ID: Hello all, This CSR covers some improvements and behavioral changes specifically to the SunJCE implementation of PBES2-based AlgorithmParameters.? The original bug, JDK-8076999, was partially fixed by JDK-8202837 and the remaining issue to fix involves expanding the accepted PRFs and encryption schemes when initializing using DER-encoding.? Working on that issue brought about some additional behavioral improvements which are documented in the CSR below. https://bugs.openjdk.java.net/browse/JDK-8221936 Thank you, --Jamil From adam.farley at uk.ibm.com Thu Apr 4 16:03:50 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 4 Apr 2019 16:03:50 +0000 Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when using JDK addressed by UNC path and using Security Manager" Message-ID: Hi All, It's been pointed out that the issue in 8218618 affects JDK11 as well. Is there any concern over backporting the fix? Reviews and thoughts are appreciated. Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 Webrev: http://cr.openjdk.java.net/~afarley/8221990/webrev/ Note: The jtreg tests for PolicyFile have been executed, and the pass/fail rate is the same before and after the fix. Best Regards Adam Farley IBM Runtimes 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 sean.mullan at oracle.com Thu Apr 4 18:05:49 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Apr 2019 14:05:49 -0400 Subject: RFR [13] JDK-8163326: Update the default enabled cipher suites preference In-Reply-To: <23208a33-0b70-4f25-2c8e-61b36f112e5f@oracle.com> References: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com> <23208a33-0b70-4f25-2c8e-61b36f112e5f@oracle.com> Message-ID: <383defc1-1077-06ba-9328-ba4b7c83cdd9@oracle.com> Looks good. --Sean On 3/28/19 10:50 AM, Xuelei Fan wrote: > 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 Apr 4 21:32:55 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Apr 2019 14:32:55 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> Message-ID: <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> Hi Daniel & Alan, All good catches! I updated accordingly: http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/ On 4/4/2019 3:01 AM, Daniel Fuchs wrote: > Hi Xuelei, > > I second Alan's suggestion to use VarHandle CAS for getDefault(). > Otherwise you will have a race between getDefault() and setDefault() > which will be problematic (and could make tests/app fail randomly). > Updated to use var handler. > WRT default factories I like the new holder class. > I wonder if you should bite the bullet and take this opportunity > to get rid of the @SuppressWarnings("deprecation") by replacing > calls to Class::newInstance by calls to Class::getConstructor, > as was done elsewhere in the JDK? > > HttpsURLConnectionImpl.java: > > If delegate is not final it should now be volatile. > I am not seeing any subclasses of HttpsURLConnectionImpl in JDK 13. > I guess 'plugin' meant 'plugin for applets'? > Yes. I removed 'plugin' stuffs in the update. BTW, it is not necessary to use delegate mode of the HttpsURLConnection impl since the code clean-up in JDK-8215430. We may want an additional HttpsURLConnectionImpl clean-up later in a new bug. > InputRecord.java > > Given that isClosed can only transition from `false` to `true` > you could add a fastpath to isClosed(): > > ?? if (isClosed) return true; > ?? // otherwise lock and look at the value again > Good point. > OutputRecord.java and SSLEngineOutputRecord.java: > > I was wondering why you didn't use the lock in isClosed(), and > noticed that OutputRecord declares isClosed as volatile. > Which makes me wonder if InputRecord should do the same, and > just forget the lock in InputRecord::isClosed? > Good catch. I updated to use violate isClosed in InputRecord as well. Thanks, Xuelei > Otherwise it looks all reasonable to me. > > best regards, > > -- daniel > > > > On 03/04/2019 20:33, Xuelei Fan wrote: >> On 4/3/2019 12:06 PM, Alan Bateman wrote: >>> On 03/04/2019 19:40, Xuelei Fan wrote: >>>> Updated webrev (updated SSLContext.java, HttpsClient, >>>> HttpsURLConnectionImpl): >>>> ?? http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/ >>>> >>> This looks good to me, the only change that I'm not 100% sure on is >>> in HttpsClient where the locking will not be consistent with the >>> locking in the HttpClient super class. Would you mind doubling >>> checking that one? We do need to change the HTTP protocol handler so >>> I expect HttpClient will change but it may have to add a protected >>> lock that HttpsClient uses to ensure that they are using the same lock. >>> >> Hm, the update is problematic.? Thanks for the catching! >> >> It might be better to make the update together with other http code in >> another enhancement.? I'd like not update the HttpsClient update this >> time. >> >> new webrev (remove update for HttpsClient.java): >> ??? http://cr.openjdk.java.net/~xuelei/8221882/webrev.02/ >> >> Thanks, >> Xuelei > From valerie.peng at oracle.com Thu Apr 4 22:31:33 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Apr 2019 15:31:33 -0700 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com> References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com> Message-ID: <16ddfd22-ad0c-0aa6-cde6-643496db745b@oracle.com> Hi Martin, Alright, as long as this mutable-key-id approach works as expected, I can live with it. The refList field inside the SessionKeyRef is changed to use LinkedList. When there is a large number of P11Key objects, the refList.remove(this) call (line1415) may takes a long long time. Have you considered some other data structure like HashSet? Lastly, on a somewhat relevant note, I noticed that line 311 in p11_keymgmt.c, the if-check of jWrappingKeyHandle is against -1, it should be against value 0? Also, the else method of this if-check? should throw an exception? Would be good to address them as well. Thanks, Valerie On 3/29/2019 9:05 AM, Martin Balao wrote: > 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 Alan.Bateman at oracle.com Fri Apr 5 07:35:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Apr 2019 08:35:37 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> Message-ID: <7ad1a80b-d58f-3227-8faf-9a0ee59f9724@oracle.com> On 04/04/2019 22:32, Xuelei Fan wrote: > Hi Daniel & Alan, > > All good catches!? I updated accordingly: > ? http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/ The updates to SSLContext and HttpsURLConnectionImpl look good. The additional cleanup you mention is fine for another follow-on issue. -Alan. From adam.farley at uk.ibm.com Fri Apr 5 09:54:10 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 5 Apr 2019 09:54:10 +0000 Subject: RFR: JDK-8221990: JDK11 Backport for PolicyFile.java fix In-Reply-To: References: Message-ID: Hi All, Reviews and committer requested for JDK-8221990 Forgot to add that part in my initial email. :) Best Regards Adam Farley IBM Runtimes "security-dev" wrote on 04/04/2019 17:03:50: > From: Adam Farley8 > To: security-dev at openjdk.java.net > Date: 04/04/2019 17:05 > Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when > using JDK addressed by UNC path and using Security Manager" > Sent by: "security-dev" > > Hi All, > > It's been pointed out that the issue in 8218618 affects JDK11 as well. > > Is there any concern over backporting the fix? > > Reviews and thoughts are appreciated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 > > Webrev: http://cr.openjdk.java.net/~afarley/8221990/webrev/ > > Note: The jtreg tests for PolicyFile have been executed, and the > pass/fail rate is the same before and after the fix. > > Best Regards > > Adam Farley > IBM Runtimes > > 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 daniel.fuchs at oracle.com Fri Apr 5 11:11:53 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 5 Apr 2019 12:11:53 +0100 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> Message-ID: <9c5ad2c4-f002-e60e-b72e-0cc0b3f469f3@oracle.com> Hi Xuelei, Looks good to me. SSLContext.java 72 throw new InternalError(e); Why not `new ExceptionInInitializerError(e)` ? SSLSocketImpl.java: In `duplexCloseOutput()` I wonder if you should nest two `try { } finally { }` statements to make really sure that the lock is actually released. I mean is there a risk that something like `super.shutdownOutput()` might throw? In which case something like: lock() try { try { // do some stuff } finally { // do more stuff } } finally { unlock(); } might make it more clearly right. No real need for new review if you decide to fix these... cheers, -- daniel On 04/04/2019 22:32, Xuelei Fan wrote: > Hi Daniel & Alan, > > All good catches!? I updated accordingly: > http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/ From sean.mullan at oracle.com Fri Apr 5 13:48:14 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Apr 2019 09:48:14 -0400 Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when using JDK addressed by UNC path and using Security Manager" In-Reply-To: References: Message-ID: <96eaf3b7-795b-788c-0741-57a4e6ad2153@oracle.com> On 4/4/19 12:03 PM, Adam Farley8 wrote: > Hi All, > > It's been pointed out that the issue in 8218618 affects JDK11 as well. > > Is there any concern over backporting the fix? No, if it is a straight backport and you haven't changed the fix, it should be safe. --Sean > > Reviews and thoughts are appreciated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 > > Webrev: _http://cr.openjdk.java.net/~afarley/8221990/webrev/_ > > Note: The jtreg tests for PolicyFile have been executed, and the > pass/fail rate is the same before and after the fix. > > Best Regards > > Adam Farley > IBM Runtimes > > 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 adam.farley at uk.ibm.com Fri Apr 5 13:56:51 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 5 Apr 2019 13:56:51 +0000 Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when using JDK addressed by UNC path and using Security Manager" In-Reply-To: <96eaf3b7-795b-788c-0741-57a4e6ad2153@oracle.com> References: <96eaf3b7-795b-788c-0741-57a4e6ad2153@oracle.com> Message-ID: Hi Sean, Sean Mullan wrote on 05/04/2019 14:48:14: > From: Sean Mullan > To: Adam Farley8 , security-dev at openjdk.java.net > Date: 05/04/2019 14:47 > Subject: Re: RFR: JDK-8221990: JDK11 Backport for "Program fails > when using JDK addressed by UNC path and using Security Manager" > > On 4/4/19 12:03 PM, Adam Farley8 wrote: > > Hi All, > > > > It's been pointed out that the issue in 8218618 affects JDK11 as well. > > > > Is there any concern over backporting the fix? > > No, if it is a straight backport and you haven't changed the fix, it > should be safe. > > --Sean It is a straight backport of the change, however the file the change is being applied to differs slightly between 11 and 12. Not in a way that seems to affect us today, but still worth mentioning. Would you mind sponsoring this change? Best Regards Adam Farley IBM Runtimes > > > > > Reviews and thoughts are appreciated. > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221990&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=1Bn_F993CxYkTmg_LTUMVQMWbcQpksz5QHcK6LWGDKQ&s=2_MaBtbGJHgTTf6Ctq_PXYtO6WIihcWl2Mcto9npoMU&e= > > > > Webrev: _https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8221990_webrev_-5F&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=1Bn_F993CxYkTmg_LTUMVQMWbcQpksz5QHcK6LWGDKQ&s=aFGLrsdqioi9MOwsHNF7HEDi0Mn0pn59LmwJE3WZWDs&e= > > > > Note: The jtreg tests for PolicyFile have been executed, and the > > pass/fail rate is the same before and after the fix. > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > 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 sean.mullan at oracle.com Fri Apr 5 14:19:57 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Apr 2019 10:19:57 -0400 Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when using JDK addressed by UNC path and using Security Manager" In-Reply-To: References: <96eaf3b7-795b-788c-0741-57a4e6ad2153@oracle.com> Message-ID: <7953f72f-ac0d-81ac-07c8-593fb46875e0@oracle.com> On 4/5/19 9:56 AM, Adam Farley8 wrote: > Hi Sean, > > Sean Mullan wrote on 05/04/2019 14:48:14: > >> From: Sean Mullan >> To: Adam Farley8 , security-dev at openjdk.java.net >> Date: 05/04/2019 14:47 >> Subject: Re: RFR: JDK-8221990: JDK11 Backport for "Program fails >> when using JDK addressed by UNC path and using Security Manager" >> >> On 4/4/19 12:03 PM, Adam Farley8 wrote: >> > Hi All, >> > >> > It's been pointed out that the issue in 8218618 affects JDK11 as well. >> > >> > Is there any concern over backporting the fix? >> >> No, if it is a straight backport and you haven't changed the fix, it >> should be safe. >> >> --Sean > > It is a straight backport of the change, however the file the change > is being applied to differs slightly between 11 and 12. > > Not in a way that seems to affect us today, but still worth mentioning. > > Would you mind sponsoring this change? I am not actively working on OpenJDK11u right now. Is there another Committer from IBM or maybe RedHat that can sponsor this for you? Thanks, Sean > > Best Regards > > Adam Farley > IBM Runtimes > >> >> > >> > Reviews and thoughts are appreciated. >> > >> > Bug: https://urldefense.proofpoint.com/v2/url? >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8221990&d=DwIC- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=1Bn_F993CxYkTmg_LTUMVQMWbcQpksz5QHcK6LWGDKQ&s=2_MaBtbGJHgTTf6Ctq_PXYtO6WIihcWl2Mcto9npoMU&e= >> > >> > Webrev: _https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8221990_webrev_-5F&d=DwIC- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=1Bn_F993CxYkTmg_LTUMVQMWbcQpksz5QHcK6LWGDKQ&s=aFGLrsdqioi9MOwsHNF7HEDi0Mn0pn59LmwJE3WZWDs&e= >> > >> > Note: The jtreg tests for PolicyFile have been executed, and the >> > pass/fail rate is the same before and after the fix. >> > >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> > >> > 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 xuelei.fan at oracle.com Fri Apr 5 14:42:09 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 5 Apr 2019 07:42:09 -0700 Subject: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE In-Reply-To: <9c5ad2c4-f002-e60e-b72e-0cc0b3f469f3@oracle.com> References: <86e14fd8-cdb9-bcbf-0309-ccf9d9a820a2@oracle.com> <03180a30-64ff-e201-5abf-b27114941e0f@oracle.com> <1d306293-7ae4-605c-d54f-93ff6b4a4cca@oracle.com> <435e675e-2429-58a7-297b-a707ca00bdf4@oracle.com> <9c5ad2c4-f002-e60e-b72e-0cc0b3f469f3@oracle.com> Message-ID: <6fa2e13f-1f11-0e4d-75be-15dd11c65194@oracle.com> All good catches! I will make the update. No new code review. Thanks, Xuelei On 4/5/2019 4:11 AM, Daniel Fuchs wrote: > Hi Xuelei, > > Looks good to me. > > SSLContext.java > > ? 72???????????? throw new InternalError(e); > > Why not `new ExceptionInInitializerError(e)` ? > > SSLSocketImpl.java: > > In `duplexCloseOutput()` I wonder if you should nest two > `try { } finally { }` statements to make really sure that the lock > is actually released. I mean is there a risk that something > like `super.shutdownOutput()` might throw? > > In which case something like: > ? lock() > ? try { > ????? try { > ????????? // do some stuff > ????? } finally { > ????????? // do more stuff > ????? } > ?? } finally { > ?????? unlock(); > ?? } > might make it more clearly right. > > No real need for new review if you decide to fix these... > > cheers, > > -- daniel > > On 04/04/2019 22:32, Xuelei Fan wrote: >> Hi Daniel & Alan, >> >> All good catches!? I updated accordingly: >> http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/ > From adam.farley at uk.ibm.com Fri Apr 5 14:46:09 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 5 Apr 2019 14:46:09 +0000 Subject: RFR: JDK-8221990: JDK11 Backport for "Program fails when using JDK addressed by UNC path and using Security Manager" In-Reply-To: <7953f72f-ac0d-81ac-07c8-593fb46875e0@oracle.com> References: <96eaf3b7-795b-788c-0741-57a4e6ad2153@oracle.com> <7953f72f-ac0d-81ac-07c8-593fb46875e0@oracle.com> Message-ID: Hi All, Are any OpenJDK11u committers willing to sponsor this backport? - Adam ... > From: Sean Mullan > I am not actively working on OpenJDK11u right now. Is there another > Committer from IBM or maybe RedHat that can sponsor this for you? > > Thanks, > Sean ... Bug: https://bugs.openjdk.java.net/browse/JDK-8221990 Webrev: http://cr.openjdk.java.net/~afarley/8221990/webrev/ 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 sean.mullan at oracle.com Fri Apr 5 17:30:04 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Apr 2019 13:30:04 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> Message-ID: <236b52c1-797c-d0ed-c113-1c226cab1cb2@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.01/ The serialized streams are now encoded within the test code itself. I also added a test case for an PermissionsHash object with invalid mappings. I also modified the fix. Instead of trying to fix the mappings in the encoded serialized form, readObject simply throws an InvalidObjectException. I believe that is the more correct behavior, as the deserialized form no longer adheres to the invariants of the serialized structures of the corresponding classes. Thanks, Sean On 4/2/19 10:03 AM, Weijun Wang wrote: > +1. > > --Max > >> On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote: >> >> Hi Sean, >> >> Typically, fixed serialization streams are encoded in the source >> as byte arrays. That keeps binary content out of the repo >> and provides a place for the comments. >> >> Roger >> >> >> On 04/02/2019 09:50 AM, Sean Mullan wrote: >>> On 4/2/19 9:44 AM, Weijun Wang wrote: >>>> >>>> >>>>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>>>> >>>>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>>>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >>>>> >>>>> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? >>>> >>>> Yes, you are right. I thought the old code can also enforce this relation. >>>> >>>> Now for the test, perms.ser is binary and you haven't described how it is generated. >>> >>> I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. >>> >>> --Sean >>> >>> >>>> >>>> Thanks, >>>> Max >>>> >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>>>>> >>>>>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>>>>> >>>>>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Sean >>>>>>> >>>> >> > From valerie.peng at oracle.com Fri Apr 5 23:12:39 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 5 Apr 2019 16:12:39 -0700 Subject: RFR: [CSR] JDK-8221936: Improvements to SunJCE implementation of PBES2 Parameters In-Reply-To: References: Message-ID: <2f765771-02a9-1984-2090-e1db392f98fc@oracle.com> Hi Jamil, Do you have a webrev ready? For this particular case, I feel it's probably better to review the webrev first and agree on the changes/approach and then file csr to document the impact/incompatibility. Thanks, Valerie On 4/4/2019 6:08 AM, Jamil Nimeh wrote: > Hello all, > > This CSR covers some improvements and behavioral changes specifically > to the SunJCE implementation of PBES2-based AlgorithmParameters.? The > original bug, JDK-8076999, was partially fixed by JDK-8202837 and the > remaining issue to fix involves expanding the accepted PRFs and > encryption schemes when initializing using DER-encoding.? Working on > that issue brought about some additional behavioral improvements which > are documented in the CSR below. > > https://bugs.openjdk.java.net/browse/JDK-8221936 > > Thank you, > --Jamil From valerie.peng at oracle.com Fri Apr 5 23:17:53 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 5 Apr 2019 16:17:53 -0700 Subject: [13] RFR JDK-8216039 "TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange" In-Reply-To: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> References: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> Message-ID: Ping, anyone has spare cycle? Thanks, Valerie On 3/25/2019 1:58 PM, Valerie Peng wrote: > > 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 jamil.j.nimeh at oracle.com Fri Apr 5 23:43:33 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 5 Apr 2019 16:43:33 -0700 Subject: RFR: [CSR] JDK-8221936: Improvements to SunJCE implementation of PBES2 Parameters In-Reply-To: <2f765771-02a9-1984-2090-e1db392f98fc@oracle.com> References: <2f765771-02a9-1984-2090-e1db392f98fc@oracle.com> Message-ID: <12c38b2b-c1bb-d2a8-ea98-c3520300e192@oracle.com> I'm pretty close to a webrev, but I need to write up the tests still.? I've made a lot of changes in PBES2Parameters to make the internal state of the object more consistent as it leaves the init state.? The other major change is how the KDFs and encryption schemes are modeled in PBES2Parameters.? The way I've done it I think will make it more extensible if we want to support other PBES2 parameter encodings in the future.? It is all contained within that one file though. --Jamil On 4/5/2019 4:12 PM, Valerie Peng wrote: > Hi Jamil, > > Do you have a webrev ready? For this particular case, I feel it's > probably better to review the webrev first and agree on the > changes/approach and then file csr to document the > impact/incompatibility. > > Thanks, > > Valerie > > On 4/4/2019 6:08 AM, Jamil Nimeh wrote: >> Hello all, >> >> This CSR covers some improvements and behavioral changes specifically >> to the SunJCE implementation of PBES2-based AlgorithmParameters.? The >> original bug, JDK-8076999, was partially fixed by JDK-8202837 and the >> remaining issue to fix involves expanding the accepted PRFs and >> encryption schemes when initializing using DER-encoding.? Working on >> that issue brought about some additional behavioral improvements >> which are documented in the CSR below. >> >> https://bugs.openjdk.java.net/browse/JDK-8221936 >> >> Thank you, >> --Jamil From weijun.wang at oracle.com Sat Apr 6 14:33:39 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Apr 2019 22:33:39 +0800 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <236b52c1-797c-d0ed-c113-1c226cab1cb2@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> <236b52c1-797c-d0ed-c113-1c226cab1cb2@oracle.com> Message-ID: <42A697D5-3A79-4725-BE46-B9A5DAF46F59@oracle.com> 603 // check that the Class of the Permission key and value are the same 604 for (Map.Entry e : perms.entrySet()) { 605 Permission k = e.getKey(); 606 Permission v = e.getValue(); 607 if (!(k.getClass().equals(v.getClass()))) { 608 throw new InvalidObjectException("Permission with " + 609 k.getClass() + " incorrectly mapped to Permission with " + 610 v.getClass()); 611 } 612 } Why not check k == v? If they were the same object at serialization, then the deserialization process should be able to assign the same object to them. --Max > On Apr 6, 2019, at 1:30 AM, Sean Mullan wrote: > > Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.01/ > > The serialized streams are now encoded within the test code itself. I also added a test case for an PermissionsHash object with invalid mappings. > > I also modified the fix. Instead of trying to fix the mappings in the encoded serialized form, readObject simply throws an InvalidObjectException. I believe that is the more correct behavior, as the deserialized form no longer adheres to the invariants of the serialized structures of the corresponding classes. > > Thanks, > Sean > > On 4/2/19 10:03 AM, Weijun Wang wrote: >> +1. >> --Max >>> On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote: >>> >>> Hi Sean, >>> >>> Typically, fixed serialization streams are encoded in the source >>> as byte arrays. That keeps binary content out of the repo >>> and provides a place for the comments. >>> >>> Roger >>> >>> >>> On 04/02/2019 09:50 AM, Sean Mullan wrote: >>>> On 4/2/19 9:44 AM, Weijun Wang wrote: >>>>> >>>>> >>>>>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>>>>> >>>>>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>>>>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >>>>>> >>>>>> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? >>>>> >>>>> Yes, you are right. I thought the old code can also enforce this relation. >>>>> >>>>> Now for the test, perms.ser is binary and you haven't described how it is generated. >>>> >>>> I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. >>>> >>>> --Sean >>>> >>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> >>>>>> --Sean >>>>>> >>>>>>> --Max >>>>>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>>>>>> >>>>>>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>>>>>> >>>>>>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sean >>>>>>>> >>>>> >>> From djelinski1 at gmail.com Sat Apr 6 18:36:16 2019 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Sat, 6 Apr 2019 20:36:16 +0200 Subject: JDK-8219568 extended master secret performance problems Message-ID: Hi all, Ever since upgrading to Java 8u161 we are running into performance problems that were caused by the implementation of extended master secret. First problem was described in 8219568; server does not allow resuming legacy sessions even when jdk.tls.allowLegacyResumption is set to true. Based on the mail archives of the original discussion [1] and the release notes [2] I think this was not what was intended. Should the setting (jdk.tls.allowLegacyResumption) on the server side work like this instead? allow = true -> proceed with abbreviated handshake allow = false -> proceed with full handshake Documentation is ambiguous enough that we would probably not even need to change it. Today it states that setting allowLegacyResumption to false rejects abbreviated handshakes, without clarifying what the default does. Second problem is that while the server rejects the abbreviated handshake, it generates and caches a new session ID on every client reconnect, effectively thrashing the session cache. These IDs are never used. Should we stop generating session IDs when legacy resumption is disabled? Regards, Daniel [1] http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html [2] https://bugs.openjdk.java.net/browse/JDK-8192045 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Apr 8 13:38:51 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Apr 2019 09:38:51 -0400 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: <42A697D5-3A79-4725-BE46-B9A5DAF46F59@oracle.com> References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> <236b52c1-797c-d0ed-c113-1c226cab1cb2@oracle.com> <42A697D5-3A79-4725-BE46-B9A5DAF46F59@oracle.com> Message-ID: On 4/6/19 10:33 AM, Weijun Wang wrote: > 603 // check that the Class of the Permission key and value are the same > 604 for (Map.Entry e : perms.entrySet()) { > 605 Permission k = e.getKey(); > 606 Permission v = e.getValue(); > 607 if (!(k.getClass().equals(v.getClass()))) { > 608 throw new InvalidObjectException("Permission with " + > 609 k.getClass() + " incorrectly mapped to Permission with " + > 610 v.getClass()); > 611 } > 612 } > > Why not check k == v? If they were the same object at serialization, then the deserialization process should be able to assign the same object to them. I agree, good catch. I have changed the above block of code to: 603 // check that the Permission key and value are the same object 604 for (Map.Entry e : perms.entrySet()) { 605 Permission k = e.getKey(); 606 Permission v = e.getValue(); 607 if (k != v) { 608 throw new InvalidObjectException("Permission (" + k + 609 ") incorrectly mapped to Permission (" + v + ")"); 610 } 611 } If you are ok with that, I will push the fix. --Sean > > --Max > > > >> On Apr 6, 2019, at 1:30 AM, Sean Mullan wrote: >> >> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.01/ >> >> The serialized streams are now encoded within the test code itself. I also added a test case for an PermissionsHash object with invalid mappings. >> >> I also modified the fix. Instead of trying to fix the mappings in the encoded serialized form, readObject simply throws an InvalidObjectException. I believe that is the more correct behavior, as the deserialized form no longer adheres to the invariants of the serialized structures of the corresponding classes. >> >> Thanks, >> Sean >> >> On 4/2/19 10:03 AM, Weijun Wang wrote: >>> +1. >>> --Max >>>> On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote: >>>> >>>> Hi Sean, >>>> >>>> Typically, fixed serialization streams are encoded in the source >>>> as byte arrays. That keeps binary content out of the repo >>>> and provides a place for the comments. >>>> >>>> Roger >>>> >>>> >>>> On 04/02/2019 09:50 AM, Sean Mullan wrote: >>>>> On 4/2/19 9:44 AM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>>>>>> >>>>>>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>>>>>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >>>>>>> >>>>>>> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? >>>>>> >>>>>> Yes, you are right. I thought the old code can also enforce this relation. >>>>>> >>>>>> Now for the test, perms.ser is binary and you haven't described how it is generated. >>>>> >>>>> I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. >>>>> >>>>> --Sean >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> --Max >>>>>>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>>>>>>> >>>>>>>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>>>>>>> >>>>>>>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sean >>>>>>>>> >>>>>> >>>> > From sean.mullan at oracle.com Mon Apr 8 14:24:31 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Apr 2019 10:24:31 -0400 Subject: RFR [13]: 8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java fails due to cert within 90-day expiry window Message-ID: <725262be-112b-cf8f-c0ec-a7351dea88c8@oracle.com> Two DocuSign root CA certificates will expire in 90 days. This is causing failures in mach5 tier 2 and tier 4. For now, I have modified the test to exclude these certificates until we can contact the CA vendor to determine if we should remove or replace them, and filed a follow-on issue to track that: https://bugs.openjdk.java.net/browse/JDK-8222121 bug: https://bugs.openjdk.java.net/browse/JDK-8222089 diffs: diff -r 7b5e2bc79e68 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Mon Apr 08 15:54:47 2019 +0300 +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Mon Apr 08 10:15:29 2019 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2019, 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 @@ -25,7 +25,7 @@ /** * @test * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 8195774 8199779 - * 8209452 8209506 8210432 8195793 + * 8209452 8209506 8210432 8195793 8222089 * @summary Check root CA entries in cacerts file */ import java.io.File; @@ -237,7 +237,12 @@ // Exception list to 90 days expiry policy // No error will be reported if certificate in this list expires - private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet<>(); + private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet<>() { + { + add("certplusclass2primaryca [jdk]"); + add("certplusclass3pprimaryca [jdk]"); + } + }; // Ninety days in milliseconds private static final long NINETY_DAYS = 7776000000L; Thanks, Sean From xuelei.fan at oracle.com Mon Apr 8 15:37:54 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Apr 2019 08:37:54 -0700 Subject: JDK-8219568 extended master secret performance problems In-Reply-To: References: Message-ID: Hi Daniel, Was extended master secret extension used when legacy resumption is expected? I did not get the point from JDK-8219568 and this description. It would be helpful if there is a test code to reproduce the behavior. Thanks, Xuelei On 4/6/2019 11:36 AM, Daniel Jeli?ski wrote: > Hi all, > Ever since upgrading to Java 8u161 we are running into performance > problems that were caused by the implementation of extended master secret. > > First problem was described in 8219568; server does not allow resuming > legacy sessions even when jdk.tls.allowLegacyResumption is set to true. > Based on the mail archives of the original discussion [1] and the > release notes [2] I think this was not what was intended. Should the > setting (jdk.tls.allowLegacyResumption) on the server side work like > this instead? > allow = true -> proceed with abbreviated handshake > allow = false -> proceed with full handshake > > Documentation is ambiguous enough that we would probably not even need > to change it. Today it states that setting allowLegacyResumption to > false rejects abbreviated handshakes, without clarifying what the > default does. > > Second problem is that while the server rejects the abbreviated > handshake, it generates and caches a new session ID on every client > reconnect, effectively thrashing the session cache. These IDs are never > used. Should we stop generating session IDs when legacy resumption is > disabled? > > Regards, > Daniel > > > [1] > http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html > [2] https://bugs.openjdk.java.net/browse/JDK-8192045 From xuelei.fan at oracle.com Mon Apr 8 15:42:04 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Apr 2019 08:42:04 -0700 Subject: RFR [13]: 8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java fails due to cert within 90-day expiry window In-Reply-To: <725262be-112b-cf8f-c0ec-a7351dea88c8@oracle.com> References: <725262be-112b-cf8f-c0ec-a7351dea88c8@oracle.com> Message-ID: <2223140e-3847-6893-285b-09ab6f68793e@oracle.com> Looks good to me. Xuelei On 4/8/2019 7:24 AM, Sean Mullan wrote: > Two DocuSign root CA certificates will expire in 90 days. This is > causing failures in mach5 tier 2 and tier 4. > > For now, I have modified the test to exclude these certificates until we > can contact the CA vendor to determine if we should remove or replace > them, and filed a follow-on issue to track that: > https://bugs.openjdk.java.net/browse/JDK-8222121 > > bug: https://bugs.openjdk.java.net/browse/JDK-8222089 > > diffs: > > diff -r 7b5e2bc79e68 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java > --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java????? Mon Apr > 08 15:54:47 2019 +0300 > +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java????? Mon Apr > 08 10:15:29 2019 -0400 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2017, 2019, 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 > @@ -25,7 +25,7 @@ > ?/** > ? * @test > ? * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 > 8195774 8199779 > - *????? 8209452 8209506 8210432 8195793 > + *????? 8209452 8209506 8210432 8195793 8222089 > ? * @summary Check root CA entries in cacerts file > ? */ > ?import java.io.File; > @@ -237,7 +237,12 @@ > > ???? // Exception list to 90 days expiry policy > ???? // No error will be reported if certificate in this list expires > -??? private static final HashSet EXPIRY_EXC_ENTRIES = new > HashSet<>(); > +??? private static final HashSet EXPIRY_EXC_ENTRIES = new > HashSet<>() { > +??????? { > +??????????? add("certplusclass2primaryca [jdk]"); > +??????????? add("certplusclass3pprimaryca [jdk]"); > +??????? } > +??? }; > > ???? // Ninety days in milliseconds > ???? private static final long NINETY_DAYS = 7776000000L; > > Thanks, > Sean From djelinski1 at gmail.com Mon Apr 8 16:59:14 2019 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Mon, 8 Apr 2019 18:59:14 +0200 Subject: JDK-8219568 extended master secret performance problems In-Reply-To: References: Message-ID: Hi Xuelei, Thanks for your response! My understanding is that legacy resumption = resumption of a session that was established without extended master secret extension. Our Java application is a web server that is communicating with a large number of clients, majority of which are built on top of OpenSSL 1.0.2, which does not implement extended master secret. The clients send data to server using frequent short-lived connections. When we use Java pre-8u161 or disable extended master secret (*jdk*.*tls* .useExtendedMasterSecret=false), the usual workflow is as follows: - client connects to server for the first time - Full handshake happens, server creates a session ID and caches it - session is established, data is transferred, connection is closed. Later: - subsequent client connection sends the cached session ID - server resumes session using abbreviated handshake - data is transferred, connection is closed. The same workflow with extended master secret enabled is as follows: - client connects to server for the first time - Full handshake happens, server creates a session ID and caches it - session is established, data is transferred, connection is closed. Later: - subsequent client connection sends the cached session ID - server checks that the session ID was established without extended master secret and rejects it. Full handshake happens, server creates a session ID and caches it - session is established, data is transferred, connection is closed. Full handshake is much more expensive than abbreviated handshake, and caching thousands of session IDs that are never reused creates a burden on GC. My understanding of RFC 7627 is that rejecting abbreviated handshake when extended master secret is not used makes sense only when we are using client certificates for authentication. We are not using client certificates in our communication, so we would prefer to resume sessions whether extended master secret is used or not. TLS specification does not require the server to assign a session ID when it knows it will not allow the client to resume session. We should take advantage of that and not assign a session ID when the user does not want to resume legacy sessions. Let me know if that makes sense now. Thanks, Daniel pon., 8 kwi 2019 o 17:43 Xuelei Fan napisa?(a): > Hi Daniel, > > Was extended master secret extension used when legacy resumption is > expected? I did not get the point from JDK-8219568 and this > description. It would be helpful if there is a test code to reproduce > the behavior. > > Thanks, > Xuelei > > On 4/6/2019 11:36 AM, Daniel Jeli?ski wrote: > > Hi all, > > Ever since upgrading to Java 8u161 we are running into performance > > problems that were caused by the implementation of extended master > secret. > > > > First problem was described in 8219568; server does not allow resuming > > legacy sessions even when jdk.tls.allowLegacyResumption is set to true. > > Based on the mail archives of the original discussion [1] and the > > release notes [2] I think this was not what was intended. Should the > > setting (jdk.tls.allowLegacyResumption) on the server side work like > > this instead? > > allow = true -> proceed with abbreviated handshake > > allow = false -> proceed with full handshake > > > > Documentation is ambiguous enough that we would probably not even need > > to change it. Today it states that setting allowLegacyResumption to > > false rejects abbreviated handshakes, without clarifying what the > > default does. > > > > Second problem is that while the server rejects the abbreviated > > handshake, it generates and caches a new session ID on every client > > reconnect, effectively thrashing the session cache. These IDs are never > > used. Should we stop generating session IDs when legacy resumption is > > disabled? > > > > Regards, > > Daniel > > > > > > [1] > > > http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8192045 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Apr 8 17:02:43 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Apr 2019 13:02:43 -0400 Subject: RFR[13]: 8222133: Add temporary exceptions for root certs that are due to expire soon Message-ID: <538132f3-3bb6-5d46-cfca-d7aaab047a34@oracle.com> Please review this fix to add temporary test exceptions for 4 more root CA certificates that are due to expire soon and will start causing test failures in the next couple of days. bug: https://bugs.openjdk.java.net/browse/JDK-8222133 diffs: $ hg diff diff -r 0608ef3a7740 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Mon Apr 08 18:42:29 2019 +0200 +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Mon Apr 08 13:01:36 2019 -0400 @@ -25,7 +25,7 @@ /** * @test * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 8195774 8199779 - * 8209452 8209506 8210432 8195793 8222089 + * 8209452 8209506 8210432 8195793 8222089 8222133 * @summary Check root CA entries in cacerts file */ import java.io.File; @@ -239,8 +239,18 @@ // No error will be reported if certificate in this list expires private static final HashSet EXPIRY_EXC_ENTRIES = new HashSet<>() { { + // Valid until: Sat Jul 06 19:59:59 EDT 2019 add("certplusclass2primaryca [jdk]"); + // Valid until: Sat Jul 06 19:59:59 EDT 2019 add("certplusclass3pprimaryca [jdk]"); + // Valid until: Tue Jul 09 14:40:36 EDT 2019 + add("utnuserfirstobjectca [jdk]"); + // Valid until: Tue Jul 09 19:59:00 EDT 2019 + add("deutschetelekomrootca2 [jdk]"); + // Valid until: Tue Jul 09 13:36:58 EDT 2019 + add("utnuserfirstclientauthemailca [jdk]"); + // Valid until: Tue Jul 09 14:19:22 EDT 2019 + add("utnuserfirsthardwareca [jdk]"); } }; --Sean From xuelei.fan at oracle.com Mon Apr 8 17:12:12 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Apr 2019 10:12:12 -0700 Subject: RFR[13]: 8222133: Add temporary exceptions for root certs that are due to expire soon In-Reply-To: <538132f3-3bb6-5d46-cfca-d7aaab047a34@oracle.com> References: <538132f3-3bb6-5d46-cfca-d7aaab047a34@oracle.com> Message-ID: Looks fine to me. Xuelei On 4/8/2019 10:02 AM, Sean Mullan wrote: > Please review this fix to add temporary test exceptions for 4 more root > CA certificates that are due to expire soon and will start causing test > failures in the next couple of days. > > bug: https://bugs.openjdk.java.net/browse/JDK-8222133 > > diffs: > > $ hg diff > diff -r 0608ef3a7740 test/jdk/sun/security/lib/cacerts/VerifyCACerts.java > --- a/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java????? Mon Apr > 08 18:42:29 2019 +0200 > +++ b/test/jdk/sun/security/lib/cacerts/VerifyCACerts.java????? Mon Apr > 08 13:01:36 2019 -0400 > @@ -25,7 +25,7 @@ > ?/** > ? * @test > ? * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 > 8195774 8199779 > - *????? 8209452 8209506 8210432 8195793 8222089 > + *????? 8209452 8209506 8210432 8195793 8222089 8222133 > ? * @summary Check root CA entries in cacerts file > ? */ > ?import java.io.File; > @@ -239,8 +239,18 @@ > ???? // No error will be reported if certificate in this list expires > ???? private static final HashSet EXPIRY_EXC_ENTRIES = new > HashSet<>() { > ???????? { > +??????????? // Valid until: Sat Jul 06 19:59:59 EDT 2019 > ???????????? add("certplusclass2primaryca [jdk]"); > +??????????? // Valid until: Sat Jul 06 19:59:59 EDT 2019 > ???????????? add("certplusclass3pprimaryca [jdk]"); > +??????????? // Valid until: Tue Jul 09 14:40:36 EDT 2019 > +??????????? add("utnuserfirstobjectca [jdk]"); > +??????????? // Valid until: Tue Jul 09 19:59:00 EDT 2019 > +??????????? add("deutschetelekomrootca2 [jdk]"); > +??????????? // Valid until: Tue Jul 09 13:36:58 EDT 2019 > +??????????? add("utnuserfirstclientauthemailca [jdk]"); > +??????????? // Valid until: Tue Jul 09 14:19:22 EDT 2019 > +??????????? add("utnuserfirsthardwareca [jdk]"); > ???????? } > ???? }; > > --Sean From xuelei.fan at oracle.com Mon Apr 8 17:35:47 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Apr 2019 10:35:47 -0700 Subject: [13] RFR JDK-8216039 "TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange" In-Reply-To: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> References: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> Message-ID: The update is clear and straightforward to me. Signature.java:542: - 542 if (cert instanceof java.security.cert.X509Certificate) { + 542 if (cert instanceof X509Certificate) { 546 X509Certificate c = (X509Certificate)cert; To keep the two lines consistent, I would prefer to remove the package, and use X509Certificate directly. Minor update, no real need for another code review to me. I might have one or two concerns of the co-existing of two types of init methods, if making the APIs public in the future. But so far so good. let's talk about them later when filing the CSR. Thanks, Xuelei On 3/25/2019 1:58 PM, Valerie Peng wrote: > > 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 xuelei.fan at oracle.com Mon Apr 8 19:00:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Apr 2019 12:00:00 -0700 Subject: JDK-8219568 extended master secret performance problems In-Reply-To: References: Message-ID: Hi Daniel, Thanks for the quick feedback. It helps me a lot. On 4/8/2019 9:59 AM, Daniel Jeli?ski wrote: > Hi Xuelei, > Thanks for your response! > My understanding is that legacy resumption = resumption of a session > that was established without extended master secret extension. > > Our Java application is a web server that is communicating with a large > number of clients, majority of which are built on top of OpenSSL 1.0.2, > which does not implement extended master secret. The clients send data > to server using frequent short-lived connections. > > When we use Java pre-8u161 or disable extended master secret > (/jdk/./tls/.useExtendedMasterSecret=false), the usual workflow is as > follows: > - client connects to server for the first time > - Full handshake happens, server creates a session ID and caches it > - session is established, data is transferred, connection is closed. > Later: > - subsequent client connection sends the cached session ID > - server resumes session using abbreviated handshake > - data is transferred, connection is closed. > > The same workflow with extended master secret enabled is as follows: > - client connects to server for the first time > - Full handshake happens, server creates a session ID and caches it > - session is established, data is transferred, connection is closed. > Later: > - subsequent client connection sends the cached session ID > - server checks that the session ID was established without extended > master secret and rejects it. Full handshake happens, server creates a > session ID and caches it > - session is established, data is transferred, connection is closed. > It sounds like a reasonable use case if applications want to take the risks. I will think more about if we can make an enhancement to allow legacy resumption again if the extended master secret extension is not used. > Full handshake is much more expensive than abbreviated handshake, and > caching thousands of session IDs that are never reused creates a burden > on GC. > > My understanding of RFC 7627 is that rejecting abbreviated handshake > when extended master secret is not used makes sense only when we are > using client certificates for authentication. We are not using client > certificates in our communication, so we would prefer to resume sessions > whether extended master secret is used or not. > > TLS specification does not require the server to assign a session ID > when it knows it will not allow the client to resume session. We should > take advantage of that and not assign a session ID when the user does > not want to resume legacy sessions. > Good idea! Thanks, Xuelei > Let me know if that makes sense now. > Thanks, > Daniel > > > pon., 8 kwi 2019 o 17:43?Xuelei Fan > napisa?(a): > > Hi Daniel, > > Was extended master secret extension used when legacy resumption is > expected?? I did not get the point from JDK-8219568 and this > description.? It would be helpful if there is a test code to reproduce > the behavior. > > Thanks, > Xuelei > > On 4/6/2019 11:36 AM, Daniel Jeli?ski wrote: > > Hi all, > > Ever since upgrading to Java 8u161 we are running into performance > > problems that were caused by the implementation of extended > master secret. > > > > First problem was described in 8219568; server does not allow > resuming > > legacy sessions even when jdk.tls.allowLegacyResumption is set to > true. > > Based on the mail archives of the original discussion [1] and the > > release notes [2] I think this was not what was intended. Should the > > setting (jdk.tls.allowLegacyResumption) on the server side work like > > this instead? > > allow = true -> proceed with abbreviated handshake > > allow = false -> proceed with full handshake > > > > Documentation is ambiguous enough that we would probably not even > need > > to change it. Today it states that setting allowLegacyResumption to > > false rejects abbreviated handshakes, without clarifying what the > > default does. > > > > Second problem is that while the server rejects the abbreviated > > handshake, it generates and caches a new session ID on every client > > reconnect, effectively thrashing the session cache. These IDs are > never > > used. Should we stop generating session IDs when legacy > resumption is > > disabled? > > > > Regards, > > Daniel > > > > > > [1] > > > http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8192045 > From valerie.peng at oracle.com Mon Apr 8 23:12:09 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Apr 2019 16:12:09 -0700 Subject: [13] RFR JDK-8216039 "TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange" In-Reply-To: References: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com> Message-ID: Hi Xuelei, Thanks for your review~ I will incorporate your feedback and re-test before integrating it. As for making the new init methods public, I can see both pros and cons. On one hand, I think it'd be nice have the new init methods being public as PKCS11 API passes both key and parameters in one init call. To support PKCS11 PSS signature with existing Signature APIs would implicitly require the parameter be set before init() is called. This may not work well with apps as we don't have such restriction specified in current Signature class javadoc. On the other hand, I also see the potential confusion of having too much APIs doing essentially the same thing. With current changes integrated, at least existing JDK code can work with BC FIPS provider. Probably good enough for now. Valerie On 4/8/2019 10:35 AM, Xuelei Fan wrote: > The update is clear and straightforward to me. > > Signature.java:542: > - 542? if (cert instanceof java.security.cert.X509Certificate) { > + 542? if (cert instanceof X509Certificate) { > ? 546? X509Certificate c = (X509Certificate)cert; > > To keep the two lines consistent, I would prefer to remove the > package, and use X509Certificate directly.? Minor update, no real need > for another code review to me. > > I might have one or two concerns of the co-existing of two types of > init methods, if making the APIs public in the future.? But so far so > good. let's talk about them later when filing the CSR. > > Thanks, > Xuelei > > On 3/25/2019 1:58 PM, Valerie Peng wrote: >> >> 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 weijun.wang at oracle.com Tue Apr 9 00:26:30 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Apr 2019 08:26:30 +0800 Subject: [13] RFR: 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings In-Reply-To: References: <63CF0D18-C950-42B1-A39B-E2876CDE881D@oracle.com> <560deb5f-e927-9238-4236-a909b91cf7bd@oracle.com> <8eff22ca-d792-cfba-35ef-9d6ee6a4df3c@oracle.com> <38A2A146-E2C0-47DC-AD78-1611323F79EE@oracle.com> <236b52c1-797c-d0ed-c113-1c226cab1cb2@oracle.com> <42A697D5-3A79-4725-BE46-B9A5DAF46F59@oracle.com> Message-ID: <3F5D3446-6504-4116-928A-EE34B7E58962@oracle.com> > On Apr 8, 2019, at 9:38 PM, Sean Mullan wrote: > > On 4/6/19 10:33 AM, Weijun Wang wrote: >> 603 // check that the Class of the Permission key and value are the same >> 604 for (Map.Entry e : perms.entrySet()) { >> 605 Permission k = e.getKey(); >> 606 Permission v = e.getValue(); >> 607 if (!(k.getClass().equals(v.getClass()))) { >> 608 throw new InvalidObjectException("Permission with " + >> 609 k.getClass() + " incorrectly mapped to Permission with " + >> 610 v.getClass()); >> 611 } >> 612 } >> Why not check k == v? If they were the same object at serialization, then the deserialization process should be able to assign the same object to them. > > I agree, good catch. I have changed the above block of code to: > > 603 // check that the Permission key and value are the same object > 604 for (Map.Entry e : perms.entrySet()) { > 605 Permission k = e.getKey(); > 606 Permission v = e.getValue(); > 607 if (k != v) { > 608 throw new InvalidObjectException("Permission (" + k + > 609 ") incorrectly mapped to Permission (" + v + ")"); > 610 } > 611 } > > If you are ok with that, I will push the fix. I have no other comment. Please go on. Thanks, Max > > --Sean > >> --Max >>> On Apr 6, 2019, at 1:30 AM, Sean Mullan wrote: >>> >>> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.01/ >>> >>> The serialized streams are now encoded within the test code itself. I also added a test case for an PermissionsHash object with invalid mappings. >>> >>> I also modified the fix. Instead of trying to fix the mappings in the encoded serialized form, readObject simply throws an InvalidObjectException. I believe that is the more correct behavior, as the deserialized form no longer adheres to the invariants of the serialized structures of the corresponding classes. >>> >>> Thanks, >>> Sean >>> >>> On 4/2/19 10:03 AM, Weijun Wang wrote: >>>> +1. >>>> --Max >>>>> On Apr 2, 2019, at 9:55 PM, Roger Riggs wrote: >>>>> >>>>> Hi Sean, >>>>> >>>>> Typically, fixed serialization streams are encoded in the source >>>>> as byte arrays. That keeps binary content out of the repo >>>>> and provides a place for the comments. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 04/02/2019 09:50 AM, Sean Mullan wrote: >>>>>> On 4/2/19 9:44 AM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 2, 2019, at 9:33 PM, Sean Mullan wrote: >>>>>>>> >>>>>>>> On 4/1/19 11:12 PM, Weijun Wang wrote: >>>>>>>>> I can understand the change in Permissions, but is there any difference in PermissionsHash? >>>>>>>> >>>>>>>> The key and value in the PermissionsHash map is always the same object. This fix ensures that is respected, otherwise after deserialization you could have a SocketPermission mapped to a FilePermission, for example. Would it be better if I added a test for that? >>>>>>> >>>>>>> Yes, you are right. I thought the old code can also enforce this relation. >>>>>>> >>>>>>> Now for the test, perms.ser is binary and you haven't described how it is generated. >>>>>> >>>>>> I just hacked Permissions.writeObject to switch the mappings. That was a lot easier than trying to write my own serialization code. I will add some comments in the test explaining how I did that and what is in perms.ser. >>>>>> >>>>>> --Sean >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>>> >>>>>>>> --Sean >>>>>>>> >>>>>>>>> --Max >>>>>>>>>> On Apr 2, 2019, at 1:10 AM, Sean Mullan wrote: >>>>>>>>>> >>>>>>>>>> It is currently possible to change the mappings in a serialized java.security.Permissions object such that they no longer map correctly, and Permissions.readObject won't detect this. >>>>>>>>>> >>>>>>>>>> This change makes sure that for a deserialized Permissions object, the permissions are mapped correctly to the class that they belong to. It does this by calling add() again for each permission in the deserialized Permissions object. The same technique was applied to a serialized PermissionsHash object which is used to store Permissions that don't implement their own PermissionCollection. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020637 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8020637/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sean >>>>>>>>>> >>>>>>> >>>>> From rajan.halade at oracle.com Tue Apr 9 01:13:00 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 8 Apr 2019 18:13:00 -0700 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: Review took longer than I planned. Your fix looks good. In addition to conversion to java, fix has good enhancements needed to tests. For instance - changing non-default digest algorithm to SHA-1 from SHA-256 for AlgOptions.sh. Thanks for these changes. Thanks, Rajan On 3/25/19 8:20 PM, Weijun Wang wrote: > 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 djelinski1 at gmail.com Tue Apr 9 20:04:23 2019 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Tue, 9 Apr 2019 22:04:23 +0200 Subject: JDK-8219568 extended master secret performance problems In-Reply-To: References: Message-ID: Hi Xuelei, What's the verdict on allowing legacy resumption on server even when EMS is enabled? I was thinking of repurposing the current allowLegacyResumption flag for this; its name looks appropriate. However, it would be a change of behavior: currently we do not allow legacy resumption, and default value of allowLegacyResumption is true; we would either need to change the default, or change the default behavior. Would that be acceptable? Regards, Daniel pon., 8 kwi 2019 o 21:00 Xuelei Fan napisa?(a): > Hi Daniel, > > Thanks for the quick feedback. It helps me a lot. > > On 4/8/2019 9:59 AM, Daniel Jeli?ski wrote: > > Hi Xuelei, > > Thanks for your response! > > My understanding is that legacy resumption = resumption of a session > > that was established without extended master secret extension. > > > > Our Java application is a web server that is communicating with a large > > number of clients, majority of which are built on top of OpenSSL 1.0.2, > > which does not implement extended master secret. The clients send data > > to server using frequent short-lived connections. > > > > When we use Java pre-8u161 or disable extended master secret > > (/jdk/./tls/.useExtendedMasterSecret=false), the usual workflow is as > > follows: > > - client connects to server for the first time > > - Full handshake happens, server creates a session ID and caches it > > - session is established, data is transferred, connection is closed. > > Later: > > - subsequent client connection sends the cached session ID > > - server resumes session using abbreviated handshake > > - data is transferred, connection is closed. > > > > The same workflow with extended master secret enabled is as follows: > > - client connects to server for the first time > > - Full handshake happens, server creates a session ID and caches it > > - session is established, data is transferred, connection is closed. > > Later: > > - subsequent client connection sends the cached session ID > > - server checks that the session ID was established without extended > > master secret and rejects it. Full handshake happens, server creates a > > session ID and caches it > > - session is established, data is transferred, connection is closed. > > > It sounds like a reasonable use case if applications want to take the > risks. I will think more about if we can make an enhancement to allow > legacy resumption again if the extended master secret extension is not > used. > > > Full handshake is much more expensive than abbreviated handshake, and > > caching thousands of session IDs that are never reused creates a burden > > on GC. > > > > My understanding of RFC 7627 is that rejecting abbreviated handshake > > when extended master secret is not used makes sense only when we are > > using client certificates for authentication. We are not using client > > certificates in our communication, so we would prefer to resume sessions > > whether extended master secret is used or not. > > > > TLS specification does not require the server to assign a session ID > > when it knows it will not allow the client to resume session. We should > > take advantage of that and not assign a session ID when the user does > > not want to resume legacy sessions. > > > Good idea! > > Thanks, > Xuelei > > > Let me know if that makes sense now. > > Thanks, > > Daniel > > > > > > pon., 8 kwi 2019 o 17:43 Xuelei Fan > > napisa?(a): > > > > Hi Daniel, > > > > Was extended master secret extension used when legacy resumption is > > expected? I did not get the point from JDK-8219568 and this > > description. It would be helpful if there is a test code to > reproduce > > the behavior. > > > > Thanks, > > Xuelei > > > > On 4/6/2019 11:36 AM, Daniel Jeli?ski wrote: > > > Hi all, > > > Ever since upgrading to Java 8u161 we are running into performance > > > problems that were caused by the implementation of extended > > master secret. > > > > > > First problem was described in 8219568; server does not allow > > resuming > > > legacy sessions even when jdk.tls.allowLegacyResumption is set to > > true. > > > Based on the mail archives of the original discussion [1] and the > > > release notes [2] I think this was not what was intended. Should > the > > > setting (jdk.tls.allowLegacyResumption) on the server side work > like > > > this instead? > > > allow = true -> proceed with abbreviated handshake > > > allow = false -> proceed with full handshake > > > > > > Documentation is ambiguous enough that we would probably not even > > need > > > to change it. Today it states that setting allowLegacyResumption > to > > > false rejects abbreviated handshakes, without clarifying what the > > > default does. > > > > > > Second problem is that while the server rejects the abbreviated > > > handshake, it generates and caches a new session ID on every > client > > > reconnect, effectively thrashing the session cache. These IDs are > > never > > > used. Should we stop generating session IDs when legacy > > resumption is > > > disabled? > > > > > > Regards, > > > Daniel > > > > > > > > > [1] > > > > > > http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html > > > [2] https://bugs.openjdk.java.net/browse/JDK-8192045 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Apr 9 21:43:16 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Apr 2019 14:43:16 -0700 Subject: JDK-8219568 extended master secret performance problems In-Reply-To: References: Message-ID: <48a09568-05d1-2c77-4734-3a4ddd0984c8@oracle.com> On 4/9/2019 1:04 PM, Daniel Jeli?ski wrote: > Hi Xuelei, > What's the verdict on allowing legacy resumption on server even when EMS > is enabled? > If EMS is used, no legacy resumption any more. Otherwise, the problem of the legacy resumption comes. > I was thinking of repurposing the current allowLegacyResumption flag for > this; its name looks appropriate. However, it would be a change of > behavior: currently we do not allow legacy resumption, and default value > of allowLegacyResumption is true; we would either need to change the > default, or change the default behavior. Would that be acceptable? Currently, if no EMS, the behavior in server side may look like: 1. close the connection if allowLegacyResumption is false; 2. perform full handshake if allowLegacyResumption true; Default allowLegacyResumption is true for compatibility reasons. Does it sound reasonable to you? Xuelei > Regards, > Daniel > > pon., 8 kwi 2019 o 21:00?Xuelei Fan > napisa?(a): > > Hi Daniel, > > Thanks for the quick feedback.? It helps me a lot. > > On 4/8/2019 9:59 AM, Daniel Jeli?ski wrote: > > Hi Xuelei, > > Thanks for your response! > > My understanding is that legacy resumption = resumption of a session > > that was established without extended master secret extension. > > > > Our Java application is a web server that is communicating with a > large > > number of clients, majority of which are built on top of OpenSSL > 1.0.2, > > which does not implement extended master secret. The clients send > data > > to server using frequent short-lived connections. > > > > When we use Java pre-8u161 or disable extended master secret > > (/jdk/./tls/.useExtendedMasterSecret=false), the usual workflow > is as > > follows: > > - client connects to server for the first time > > - Full handshake happens, server creates a session ID and caches it > > - session is established, data is transferred, connection is closed. > > Later: > > - subsequent client connection sends the cached session ID > > - server resumes session using abbreviated handshake > > - data is transferred, connection is closed. > > > > The same workflow with extended master secret enabled is as follows: > > - client connects to server for the first time > > - Full handshake happens, server creates a session ID and caches it > > - session is established, data is transferred, connection is closed. > > Later: > > - subsequent client connection sends the cached session ID > > - server checks that the session ID was established without extended > > master secret and rejects it. Full handshake happens, server > creates a > > session ID and caches it > > - session is established, data is transferred, connection is closed. > > > It sounds like a reasonable use case if applications want to take the > risks.? I will think more about if we can make an enhancement to allow > legacy resumption again if the extended master secret extension is > not used. > > > Full handshake is much more expensive than abbreviated handshake, > and > > caching thousands of session IDs that are never reused creates a > burden > > on GC. > > > > My understanding of RFC 7627 is that rejecting abbreviated handshake > > when extended master secret is not used makes sense only when we are > > using client certificates for authentication. We are not using > client > > certificates in our communication, so we would prefer to resume > sessions > > whether extended master secret is used or not. > > > > TLS specification does not require the server to assign a session ID > > when it knows it will not allow the client to resume session. We > should > > take advantage of that and not assign a session ID when the user > does > > not want to resume legacy sessions. > > > Good idea! > > Thanks, > Xuelei > > > Let me know if that makes sense now. > > Thanks, > > Daniel > > > > > > pon., 8 kwi 2019 o 17:43?Xuelei Fan > > >> > napisa?(a): > > > >? ? ?Hi Daniel, > > > >? ? ?Was extended master secret extension used when legacy > resumption is > >? ? ?expected?? I did not get the point from JDK-8219568 and this > >? ? ?description.? It would be helpful if there is a test code to > reproduce > >? ? ?the behavior. > > > >? ? ?Thanks, > >? ? ?Xuelei > > > >? ? ?On 4/6/2019 11:36 AM, Daniel Jeli?ski wrote: > >? ? ? > Hi all, > >? ? ? > Ever since upgrading to Java 8u161 we are running into > performance > >? ? ? > problems that were caused by the implementation of extended > >? ? ?master secret. > >? ? ? > > >? ? ? > First problem was described in 8219568; server does not allow > >? ? ?resuming > >? ? ? > legacy sessions even when jdk.tls.allowLegacyResumption is > set to > >? ? ?true. > >? ? ? > Based on the mail archives of the original discussion [1] > and the > >? ? ? > release notes [2] I think this was not what was intended. > Should the > >? ? ? > setting (jdk.tls.allowLegacyResumption) on the server side > work like > >? ? ? > this instead? > >? ? ? > allow = true -> proceed with abbreviated handshake > >? ? ? > allow = false -> proceed with full handshake > >? ? ? > > >? ? ? > Documentation is ambiguous enough that we would probably > not even > >? ? ?need > >? ? ? > to change it. Today it states that setting > allowLegacyResumption to > >? ? ? > false rejects abbreviated handshakes, without clarifying > what the > >? ? ? > default does. > >? ? ? > > >? ? ? > Second problem is that while the server rejects the > abbreviated > >? ? ? > handshake, it generates and caches a new session ID on > every client > >? ? ? > reconnect, effectively thrashing the session cache. These > IDs are > >? ? ?never > >? ? ? > used. Should we stop generating session IDs when legacy > >? ? ?resumption is > >? ? ? > disabled? > >? ? ? > > >? ? ? > Regards, > >? ? ? > Daniel > >? ? ? > > >? ? ? > > >? ? ? > [1] > >? ? ? > > > > http://openjdk.5641.n7.nabble.com/Code-Review-Request-JDK-8148421-Extended-Master-Secret-TLS-extension-td311192.html > >? ? ? > [2] https://bugs.openjdk.java.net/browse/JDK-8192045 > > > From valerie.peng at oracle.com Wed Apr 10 21:29:51 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Apr 2019 14:29:51 -0700 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: <206d26a8-9318-c5ec-4b6d-7814250659db@oracle.com> Hi Max, Here are some comments/questions: General question, some of the tests use same name for keystore file, i.e. ks. Will these tests interfere with each other at runtime? The shell scripts often do some cleanup before starting the real test. I assume we don't have to concern ourselves with this anymore? what does this test trying to test? I don't quite understand its value... Do we still need it? line 41 uses 1024 as key size, but shell script has 2048. We should check the three commands completed successfully as well? shell script has additional "-sigalg SHA512withRSA" options for the last test. line 67, 68, check for non-null return value? nit: 2nd copyright year should be 2019, line 47 check for 0 exit value? line 27: typo, should be "containing" line 48: check for 0 exit value? line 216 seems redundant as it should be covered by line 220 Nice to have java files instead of scripts. :) Valerie On 3/4/2019 4:26 PM, 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 John.Gray at entrustdatacard.com Wed Apr 10 22:02:02 2019 From: John.Gray at entrustdatacard.com (John Gray) Date: Wed, 10 Apr 2019 22:02:02 +0000 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 Message-ID: Hello, It looks like we hit this issue with our Entrust Java toolkit using TLS 1.2 ( not just TLS 1.3): We get this error, which is almost identical. java.lang.ClassCastException: class com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable cannot be cast to class java.security.interfaces.ECPrivateKey (com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable is in unnamed module of loader 'app'; java.security.interfaces.ECPrivateKey is in module java.base of loader 'bootstrap') at java.base/sun.security.ssl.SignatureScheme.getPreferableAlgorithm(SignatureScheme.java:436) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:566) at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:740) at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:173) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) It looks like you recently fixed this error, which is great! I was wondering where I can download a build that contains this fix, or when would such a build be available? Thanks, John Gray Entrust Datacard -----Original Message----- From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Xuelei Fan Sent: Tuesday, April 2, 2019 11:45 PM To: Valerie Peng ; security-dev at openjdk.java.net Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Good catch! I missed the update for SignatureScheme. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/ Thanks, Xuelei On 4/2/2019 12:35 PM, Valerie Peng wrote: > > Hmm, I didn't see the SignatureScheme.java in the webrev? The > stacktrace in the bug record shows the casting being inside SignatureScheme class. > Did I miss something? > > Valerie > > On 3/28/2019 7:52 AM, Xuelei Fan wrote: >> 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 weijun.wang at oracle.com Thu Apr 11 03:31:07 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Apr 2019 11:31:07 +0800 Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain java tests In-Reply-To: <206d26a8-9318-c5ec-4b6d-7814250659db@oracle.com> References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com> <1550223285.2497.12.camel@paratix.ch> <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com> <206d26a8-9318-c5ec-4b6d-7814250659db@oracle.com> Message-ID: <9881B29D-6B4B-40CC-8DAE-37D3F7ECE4A5@oracle.com> Hi Valerie, Thanks for the review. Webrev updated at https://cr.openjdk.java.net/~weijun/8180573/webrev.02/ You can look at the interdiff only. > On Apr 11, 2019, at 5:29 AM, Valerie Peng wrote: > > Hi Max, > > Here are some comments/questions: > > General question, some of the tests use same name for keystore file, i.e. ks. Will these tests interfere with each other at runtime? The shell scripts often do some cleanup before starting the real test. I assume we don't have to concern ourselves with this anymore? Correct. jtreg will clean up (and retain if requested) the files, and when multiple tests run in parallel they have different working directories. > > what does this test trying to test? I don't quite understand its value... Do we still need it? This is a very manual test and I have seen bug reported on it not very long ago, so there are people running it. It's now just a rewrite of i18n.sh and both should always pass at no time. I assume the test just needs an entry with @test. I do realize I should remove the element in i18n.html. BTW, I think the most correct way should be i18n.java printing out the instructions, asking the user to try out all those command, and enter a Y or N as the result. Then if user type in N the test fails. :-) > > line 41 uses 1024 as key size, but shell script has 2048. We should check the three commands completed successfully as well? OK and OK. I didn't checked the exit code because the original test is checking for the result of grep. Now I think it's never a bad idea to check the keytool exit code since it's handy with OutputAnalyzer. > > shell script has additional "-sigalg SHA512withRSA" options for the last test. Good catch. > > line 67, 68, check for non-null return value? OK. > > nit: 2nd copyright year should be 2019, OK. > > line 47 check for 0 exit value? Yes I can. The shell test hadn't, although. > > line 27: typo, should be "containing" Fixed. > > line 48: check for 0 exit value? Yes. > Yes. Thanks, Max > line 216 seems redundant as it should be covered by line 220 > > Nice to have java files instead of scripts. :) > > Valerie > > On 3/4/2019 4:26 PM, 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 xuelei.fan at oracle.com Thu Apr 11 14:33:08 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Apr 2019 07:33:08 -0700 Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: References: Message-ID: The fix is available in OpenJDK repository: http://hg.openjdk.java.net/jdk/jdk/ You can build it from the source code or use the next Early-Access build: https://jdk.java.net/13/ Regards, Xuelei On 4/10/2019 3:02 PM, John Gray wrote: > Hello, > > It looks like we hit this issue with our Entrust Java toolkit using TLS 1.2 ( not just TLS 1.3): > > We get this error, which is almost identical. > > java.lang.ClassCastException: class com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable cannot be cast to class java.security.interfaces.ECPrivateKey (com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable is in unnamed module of loader 'app'; java.security.interfaces.ECPrivateKey is in module java.base of loader 'bootstrap') > at java.base/sun.security.ssl.SignatureScheme.getPreferableAlgorithm(SignatureScheme.java:436) > at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:566) > at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:740) > at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) > at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:173) > at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) > at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > > > It looks like you recently fixed this error, which is great! I was wondering where I can download a build that contains this fix, or when would such a build be available? > > Thanks, > > > John Gray > Entrust Datacard > > > -----Original Message----- > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Xuelei Fan > Sent: Tuesday, April 2, 2019 11:45 PM > To: Valerie Peng ; security-dev at openjdk.java.net > Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > > Good catch! I missed the update for SignatureScheme. > > Here is the new webrev: > http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/ > > Thanks, > Xuelei > > On 4/2/2019 12:35 PM, Valerie Peng wrote: >> >> Hmm, I didn't see the SignatureScheme.java in the webrev? The >> stacktrace in the bug record shows the casting being inside SignatureScheme class. >> Did I miss something? >> >> Valerie >> >> On 3/28/2019 7:52 AM, Xuelei Fan wrote: >>> 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 John.Gray at entrustdatacard.com Thu Apr 11 15:00:55 2019 From: John.Gray at entrustdatacard.com (John Gray) Date: Thu, 11 Apr 2019 15:00:55 +0000 Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 In-Reply-To: References: Message-ID: Thanks. I'll give it a try later today and let you know if it is working. Thanks for the prompt response! John Gray Entrust Datacard -----Original Message----- From: Xuelei Fan [mailto:xuelei.fan at oracle.com] Sent: Thursday, April 11, 2019 10:33 AM To: John Gray ; Valerie Peng ; security-dev at openjdk.java.net Cc: Greg Patel Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. The fix is available in OpenJDK repository: http://hg.openjdk.java.net/jdk/jdk/ You can build it from the source code or use the next Early-Access build: https://jdk.java.net/13/ Regards, Xuelei On 4/10/2019 3:02 PM, John Gray wrote: > Hello, > > It looks like we hit this issue with our Entrust Java toolkit using TLS 1.2 ( not just TLS 1.3): > > We get this error, which is almost identical. > > java.lang.ClassCastException: class com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable cannot be cast to class java.security.interfaces.ECPrivateKey (com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable is in unnamed module of loader 'app'; java.security.interfaces.ECPrivateKey is in module java.base of loader 'bootstrap') > at java.base/sun.security.ssl.SignatureScheme.getPreferableAlgorithm(SignatureScheme.java:436) > at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.(CertificateVerify.java:566) > at java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:740) > at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) > at java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:173) > at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) > at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl. > java:402) > > > It looks like you recently fixed this error, which is great! I was wondering where I can download a build that contains this fix, or when would such a build be available? > > Thanks, > > > John Gray > Entrust Datacard > > > -----Original Message----- > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On > Behalf Of Xuelei Fan > Sent: Tuesday, April 2, 2019 11:45 PM > To: Valerie Peng ; > security-dev at openjdk.java.net > Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with > ClassException when EC keys are stored in PKCS11 > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > > Good catch! I missed the update for SignatureScheme. > > Here is the new webrev: > http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/ > > Thanks, > Xuelei > > On 4/2/2019 12:35 PM, Valerie Peng wrote: >> >> Hmm, I didn't see the SignatureScheme.java in the webrev? The >> stacktrace in the bug record shows the casting being inside SignatureScheme class. >> Did I miss something? >> >> Valerie >> >> On 3/28/2019 7:52 AM, Xuelei Fan wrote: >>> 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 valerie.peng at oracle.com Thu Apr 11 22:59:10 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 11 Apr 2019 15:59:10 -0700 Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain java tests In-Reply-To: <9881B29D-6B4B-40CC-8DAE-37D3F7ECE4A5@oracle.com> References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com> <1550223285.2497.12.camel@paratix.ch> <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com> <206d26a8-9318-c5ec-4b6d-7814250659db@oracle.com> <9881B29D-6B4B-40CC-8DAE-37D3F7ECE4A5@oracle.com> Message-ID: <56439660-5ea0-3956-d186-77bc3fbf320d@oracle.com> The updated webrev looks good~ Yes, I like to explicitly check the return value - it's quite easy with OutputAnalyzer and doing so will mark first point of failure which saves debugging time. New test classes look very good thanks to those test library classes. Thanks, Valerie On 4/10/2019 8:31 PM, Weijun Wang wrote: > Hi Valerie, > > Thanks for the review. Webrev updated at > > https://cr.openjdk.java.net/~weijun/8180573/webrev.02/ > > You can look at the interdiff only. > >> On Apr 11, 2019, at 5:29 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Here are some comments/questions: >> >> General question, some of the tests use same name for keystore file, i.e. ks. Will these tests interfere with each other at runtime? The shell scripts often do some cleanup before starting the real test. I assume we don't have to concern ourselves with this anymore? > Correct. jtreg will clean up (and retain if requested) the files, and when multiple tests run in parallel they have different working directories. > >> what does this test trying to test? I don't quite understand its value... Do we still need it? > This is a very manual test and I have seen bug reported on it not very long ago, so there are people running it. It's now just a rewrite of i18n.sh and both should always pass at no time. I assume the test just needs an entry with @test. > > I do realize I should remove the element in i18n.html. > > BTW, I think the most correct way should be i18n.java printing out the instructions, asking the user to try out all those command, and enter a Y or N as the result. Then if user type in N the test fails. :-) > >> line 41 uses 1024 as key size, but shell script has 2048. We should check the three commands completed successfully as well? > OK and OK. > > I didn't checked the exit code because the original test is checking for the result of grep. Now I think it's never a bad idea to check the keytool exit code since it's handy with OutputAnalyzer. > >> shell script has additional "-sigalg SHA512withRSA" options for the last test. > Good catch. > >> line 67, 68, check for non-null return value? > OK. > >> nit: 2nd copyright year should be 2019, > OK. > >> line 47 check for 0 exit value? > Yes I can. The shell test hadn't, although. > >> line 27: typo, should be "containing" > Fixed. > >> line 48: check for 0 exit value? > Yes. > > Yes. > > Thanks, > Max > >> line 216 seems redundant as it should be covered by line 220 >> >> Nice to have java files instead of scripts. :) >> >> Valerie >> >> On 3/4/2019 4:26 PM, 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 hedwards at crawfordtech.com Thu Apr 11 20:45:51 2019 From: hedwards at crawfordtech.com (Hank Edwards) Date: Thu, 11 Apr 2019 20:45:51 +0000 Subject: JNI Signal Chaining and OWASP (Security) Message-ID: <520930d555904cfbb426bea5457e7629@crawfordtech.com> I work on a product that provides a JNI wrapper around a native API, we currently use LD_PRELOAD to enable signal chaining. We chose LD_PRELOAD as we do not force our customers to a specific Java vendor or version, nor do we want to complicate our build process by creating a unique build for each of the various Java vendor/versions our customers may be using. We've recently discovered that the use of LD_PRELOAD is considered a code injection risk by security analysis tools, such as ones that check for OWASP 2017. Is there anything we may not be considering to allow our JNI dependent product to be OWASP compliant? Or does anyone know if there are plans to address this in a new or alternate way in the future to allow a JNI application to be OWASP compliant? Builds linking against each supported JVM would work, but going from 1 to 9 builds (roughly 3 JDK vendors x 3 active JDK version levels) on 5 platforms will certainly add to our maintenance and testing cycles. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Apr 12 07:59:43 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 Apr 2019 15:59:43 +0800 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false Message-ID: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). And the test would succeed early if a 64 bit SN is found. Thanks, Max From xuelei.fan at oracle.com Fri Apr 12 14:59:39 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 12 Apr 2019 07:59:39 -0700 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false In-Reply-To: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> References: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> Message-ID: To test a 3% or 10% chance of 64-bits serial number, I don't think the test really make sense now. I would prefer to drop this test, or just keep the positive value checking (one cert only). If you want to keep it, the code looks good to me. Xuelei On 4/12/2019 12:59 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ > > Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). > > And the test would succeed early if a 64 bit SN is found. > > Thanks, > Max > From coderaptor at gmail.com Fri Apr 12 17:14:46 2019 From: coderaptor at gmail.com (coderaptor) Date: Fri, 12 Apr 2019 10:14:46 -0700 Subject: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: I may be off-mark here (since I did not go over the mail thread with a fine comb), but one possible use is to satisfy cases where FIPS 140-2 validated library is a requirement. Currently, there are very few options in the market (BouncyCastle is FIPS 140-2, RSA BSAFE has exited), so the ability to use OpenSSL as a JCE provided would be immensely beneficial. Thanks. -ag On Thu, Mar 21, 2019 at 8:43 AM Simone Bordet wrote: > > 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 Nico.Williams at twosigma.com Fri Apr 12 19:48:23 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 12 Apr 2019 19:48:23 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: <520930d555904cfbb426bea5457e7629@crawfordtech.com> References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> Message-ID: <20190412194823.GA6356@twosigma.com> On Thu, Apr 11, 2019 at 08:45:51PM +0000, Hank Edwards wrote: > I work on a product that provides a JNI wrapper around a native API, we > currently use LD_PRELOAD to enable signal chaining. We chose LD_PRELOAD as > we do not force our customers to a specific Java vendor or version, nor do we > want to complicate our build process by creating a unique build for each of > the various Java vendor/versions our customers may be using. We've recently > discovered that the use of LD_PRELOAD is considered a code injection risk by > security analysis tools, such as ones that check for OWASP 2017. I would raise the issue with the vendors of the security analysis tools. Code injection is a legitimate tool for integration. > Is there anything we may not be considering to allow our JNI dependent > product to be OWASP compliant? Or does anyone know if there are plans > to address this in a new or alternate way in the future to allow a JNI > application to be OWASP compliant? Builds linking against each > supported JVM would work, but going from 1 to 9 builds (roughly 3 JDK > vendors x 3 active JDK version levels) on 5 platforms will certainly > add to our maintenance and testing cycles. Any mechanism for code injection can cause false positives in security analysis tools, therefore changing how you inject code risks being nothing more than a waste of time and effort. Nico -- From Nico.Williams at twosigma.com Fri Apr 12 19:52:50 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 12 Apr 2019 19:52:50 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: <20190412194823.GA6356@twosigma.com> References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> <20190412194823.GA6356@twosigma.com> Message-ID: <20190412195250.GB6356@twosigma.com> You could simply move the original JNI DLL out of the way and replace it with a wrapper that does the signal handler setup in a .init section and otherwise has stubs for all entry points that simply call the real (now renamed) DLL. In Solaris/Illumos we'd call that wrapper a "filter", and Solaris/ Illumos has tools to make building a filter easier, but the concept is general enough and you can build the same sort of thing on Linux and Windows just as well. Again, this is still code injection. It's still likely to cause false alerts. Again, I recommend taking this up with the vendors of the relevant security analysis tools. Nico -- From hedwards at crawfordtech.com Fri Apr 12 20:24:06 2019 From: hedwards at crawfordtech.com (Hank Edwards) Date: Fri, 12 Apr 2019 20:24:06 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: <20190412195250.GB6356@twosigma.com> References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> <20190412194823.GA6356@twosigma.com> <20190412195250.GB6356@twosigma.com> Message-ID: Hi Nico; Thanks for the suggestion, I was not aware the libjsig.so could be loaded like that. I'm assuming you mean a loadlibrary("jsig"); in the .init. It would also work I suppose to just add the .init to the original shared library going forwards too, instead of putting a wrapper library in-between? I'll give that a try. Regards; Hank Hank Edwards Manager, Software Development +1.416.923.0080 hedwards at crawfordtech.com ? CRAWFORD TECHNOLOGIES INC. 60 St. Clair Avenue East, Suite 1002 Toronto, ON, Canada, M4T 1N5 http://www.crawfordtech.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Please consider our environment before printing this email. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. Devez-vous imprimer ce courriel? Pensons environnement. -----Original Message----- From: Nico Williams Sent: Friday, April 12, 2019 3:53 PM To: Hank Edwards Cc: security-dev at openjdk.java.net Subject: Re: JNI Signal Chaining and OWASP (Security) You could simply move the original JNI DLL out of the way and replace it with a wrapper that does the signal handler setup in a .init section and otherwise has stubs for all entry points that simply call the real (now renamed) DLL. In Solaris/Illumos we'd call that wrapper a "filter", and Solaris/ Illumos has tools to make building a filter easier, but the concept is general enough and you can build the same sort of thing on Linux and Windows just as well. Again, this is still code injection. It's still likely to cause false alerts. Again, I recommend taking this up with the vendors of the relevant security analysis tools. Nico -- From Nico.Williams at twosigma.com Fri Apr 12 21:04:52 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Fri, 12 Apr 2019 21:04:52 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> <20190412194823.GA6356@twosigma.com> <20190412195250.GB6356@twosigma.com> Message-ID: <20190412210452.GC6356@twosigma.com> On Fri, Apr 12, 2019 at 08:24:06PM +0000, Hank Edwards wrote: > Thanks for the suggestion, I was not aware the libjsig.so could be loaded > like that. I'm assuming you mean a loadlibrary("jsig"); in the .init. It > would also work I suppose to just add the .init to the original shared > library going forwards too, instead of putting a wrapper library in-between? Yes, of course, if you're willing to modify/replace some such shared object, you can do that. > I'll give that a try. From valerie.peng at oracle.com Sat Apr 13 00:05:48 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 12 Apr 2019 17:05:48 -0700 Subject: [13] RFR JDK-8080462: Update SunPKCS11 provider with PKCS11 v2.40 support Message-ID: <1de69fb8-6679-ca1e-3a1e-ef6f37f52ea6@oracle.com> Anyone has time to review this? Besides the header files update, I added support for AES/GCM/NoPadding support. Ran into some strange NSS error with RSASSA-PSS signature mechanism, so I have not included the PSS signature impl here. RFE: https://bugs.openjdk.java.net/browse/JDK-8080462 Webrev: http://cr.openjdk.java.net/~valeriep/8080462/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8221442 Thanks, Valerie From weijun.wang at oracle.com Sat Apr 13 14:35:34 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 13 Apr 2019 22:35:34 +0800 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false In-Reply-To: References: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> Message-ID: <0D2CDE71-B10D-464C-BF1D-5C45088459CE@oracle.com> > On Apr 12, 2019, at 10:59 PM, Xuelei Fan wrote: > > To test a 3% or 10% chance of 64-bits serial number, Can you explain what 3% or 10% you mean here? > I don't think the test really make sense now. I would prefer to drop this test, or just keep the positive value checking (one cert only). ...if it fails again. :-) Thanks, Max > > If you want to keep it, the code looks good to me. > > Xuelei > > On 4/12/2019 12:59 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ >> Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). >> And the test would succeed early if a 64 bit SN is found. >> Thanks, >> Max From Xuelei.Fan at Oracle.Com Sat Apr 13 17:54:56 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Sat, 13 Apr 2019 10:54:56 -0700 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false In-Reply-To: <0D2CDE71-B10D-464C-BF1D-5C45088459CE@oracle.com> References: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> <0D2CDE71-B10D-464C-BF1D-5C45088459CE@oracle.com> Message-ID: > On Apr 13, 2019, at 7:35 AM, Weijun Wang wrote: > > > >> On Apr 12, 2019, at 10:59 PM, Xuelei Fan wrote: >> >> To test a 3% or 10% chance of 64-bits serial number, > > Can you explain what 3% or 10% you mean here? > I think the code is checking one 64 bits SN out of 10 or 30 SNs? Xuelei >> I don't think the test really make sense now. I would prefer to drop this test, or just keep the positive value checking (one cert only). > > ...if it fails again. :-) > > Thanks, > Max > >> >> If you want to keep it, the code looks good to me. >> >> Xuelei >> >>> On 4/12/2019 12:59 AM, Weijun Wang wrote: >>> Please take a review at >>> https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ >>> Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). >>> And the test would succeed early if a 64 bit SN is found. >>> Thanks, >>> Max > From weijun.wang at oracle.com Sun Apr 14 02:17:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 14 Apr 2019 10:17:04 +0800 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false In-Reply-To: References: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> <0D2CDE71-B10D-464C-BF1D-5C45088459CE@oracle.com> Message-ID: <23FB72C0-88BE-4A1A-939D-91BDA1FD653D@oracle.com> > On Apr 14, 2019, at 1:54 AM, Xuelei Fan wrote: > > > >> On Apr 13, 2019, at 7:35 AM, Weijun Wang wrote: >> >> >> >>> On Apr 12, 2019, at 10:59 PM, Xuelei Fan wrote: >>> >>> To test a 3% or 10% chance of 64-bits serial number, >> >> Can you explain what 3% or 10% you mean here? >> > I think the code is checking one 64 bits SN out of 10 or 30 SNs? Yes, it's similar to before. I just check while generating so I can succeed early. I think what you mean if no matter if the probability is high or low, it's still random and could fail. But this time the difference is not 3 folds it's 1000000. So I think it's worth a rewrite. I'll push it. --Max > > Xuelei > >>> I don't think the test really make sense now. I would prefer to drop this test, or just keep the positive value checking (one cert only). >> >> ...if it fails again. :-) >> >> Thanks, >> Max >> >>> >>> If you want to keep it, the code looks good to me. >>> >>> Xuelei >>> >>>> On 4/12/2019 12:59 AM, Weijun Wang wrote: >>>> Please take a review at >>>> https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ >>>> Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). >>>> And the test would succeed early if a 64 bit SN is found. >>>> Thanks, >>>> Max >> > From xuelei.fan at oracle.com Sun Apr 14 04:10:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 13 Apr 2019 21:10:19 -0700 Subject: RFR 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false In-Reply-To: <23FB72C0-88BE-4A1A-939D-91BDA1FD653D@oracle.com> References: <1D7CDB76-9FB1-4FE9-8831-FC06326674AD@oracle.com> <0D2CDE71-B10D-464C-BF1D-5C45088459CE@oracle.com> <23FB72C0-88BE-4A1A-939D-91BDA1FD653D@oracle.com> Message-ID: <8e2bb6f1-6b71-7f8e-5947-fd84e7f1b69d@oracle.com> On 4/13/2019 7:17 PM, Weijun Wang wrote: > > >> On Apr 14, 2019, at 1:54 AM, Xuelei Fan wrote: >> >> >> >>> On Apr 13, 2019, at 7:35 AM, Weijun Wang wrote: >>> >>> >>> >>>> On Apr 12, 2019, at 10:59 PM, Xuelei Fan wrote: >>>> >>>> To test a 3% or 10% chance of 64-bits serial number, >>> >>> Can you explain what 3% or 10% you mean here? >>> >> I think the code is checking one 64 bits SN out of 10 or 30 SNs? > > Yes, it's similar to before. I just check while generating so I can succeed early. > > I think what you mean if no matter if the probability is high or low, it's still random and could fail. I meant that no matter the test success or fail, you don't really know if there is a regression. > But this time the difference is not 3 folds it's 1000000. So I think it's worth a rewrite. > > I'll push it. > Okay. Xuelei > --Max > >> >> Xuelei >> >>>> I don't think the test really make sense now. I would prefer to drop this test, or just keep the positive value checking (one cert only). >>> >>> ...if it fails again. :-) >>> >>> Thanks, >>> Max >>> >>>> >>>> If you want to keep it, the code looks good to me. >>>> >>>> Xuelei >>>> >>>>> On 4/12/2019 12:59 AM, Weijun Wang wrote: >>>>> Please take a review at >>>>> https://cr.openjdk.java.net/~weijun/8222275/webrev.00/ >>>>> Now the test would generate 10 to 30 certs. It could still fail, but the probably is extremely small now (2^-30 is 10^-9). >>>>> And the test would succeed early if a 64 bit SN is found. >>>>> Thanks, >>>>> Max >>> >> > From hedwards at crawfordtech.com Mon Apr 15 18:03:33 2019 From: hedwards at crawfordtech.com (Hank Edwards) Date: Mon, 15 Apr 2019 18:03:33 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: <20190412210452.GC6356@twosigma.com> References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> <20190412194823.GA6356@twosigma.com> <20190412195250.GB6356@twosigma.com> <20190412210452.GC6356@twosigma.com> Message-ID: <047bb75c75d74dc383c21e5665e62c7b@crawfordtech.com> After considering this I decided on an attempting an alternate approach. I coded the Java part of our API to perform a System.loadlibrary("jsig"); prior to the call for our JNI library to be loaded. This gave the desired effect when testing; the native code handled the signals and the Java program completed successfully. On Fri, Apr 12, 2019 at 08:24:06PM +0000, Hank Edwards wrote: > Thanks for the suggestion, I was not aware the libjsig.so could be > loaded like that. I'm assuming you mean a loadlibrary("jsig"); in the > .init. It would also work I suppose to just add the .init to the > original shared library going forwards too, instead of putting a wrapper library in-between? Yes, of course, if you're willing to modify/replace some such shared object, you can do that. > I'll give that a try. From John.Gray at entrustdatacard.com Mon Apr 15 18:12:34 2019 From: John.Gray at entrustdatacard.com (John Gray) Date: Mon, 15 Apr 2019 18:12:34 +0000 Subject: [EXTERNAL]Re: Use of OpenSSL as JCE security provider if available on system In-Reply-To: References: Message-ID: <7faeab91c164493693adce9bb500978b@PMSPEX03.corporate.datacard.com> Our Entrust Authority Security Toolkit for the Java platform also contains a FIPS 140-2 certified provider, and we add pluggable crypto ability to provide FIPS 140-2 crypto using the TLS protocol available in the JVM (when our FIPS 140-2 certified provider is being used). Cheers, John Gray Entrust Datacard -----Original Message----- From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of coderaptor Sent: Friday, April 12, 2019 1:15 PM To: Simone Bordet Cc: OpenJDK Dev list Subject: [EXTERNAL]Re: Use of OpenSSL as JCE security provider if available on system WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. I may be off-mark here (since I did not go over the mail thread with a fine comb), but one possible use is to satisfy cases where FIPS 140-2 validated library is a requirement. Currently, there are very few options in the market (BouncyCastle is FIPS 140-2, RSA BSAFE has exited), so the ability to use OpenSSL as a JCE provided would be immensely beneficial. Thanks. -ag On Thu, Mar 21, 2019 at 8:43 AM Simone Bordet wrote: > > 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-improveme > nts > > 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 christian.heinrich at cmlh.id.au Tue Apr 16 00:43:36 2019 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Tue, 16 Apr 2019 10:43:36 +1000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: <520930d555904cfbb426bea5457e7629@crawfordtech.com> References: <520930d555904cfbb426bea5457e7629@crawfordtech.com> Message-ID: Hank, On Fri, 12 Apr 2019 at 09:41, Hank Edwards wrote: >We've recently discovered that the use of C is considered a code injection risk by security analysis tools, such as ones that check for OWASP 2017. I contribute to https://github.com/OWASP/Top10/pull/450 Can you please disclose the specific candidate[s] your security analysis tool has cited within the OWASP Top Ten 2017 release? -- Regards, Christian Heinrich http://cmlh.id.au/contact From ecki at zusammenkunft.net Tue Apr 16 01:04:45 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 16 Apr 2019 01:04:45 +0000 Subject: JNI Signal Chaining and OWASP (Security) In-Reply-To: References: <520930d555904cfbb426bea5457e7629@crawfordtech.com>, Message-ID: Just to state the obvious, the LD_PRELOAD risk does not go away when you don?t use the feature. I think this scan result should be ignored (at best). It is more a weakness of the Linux bintools/ld and not your extension. (In normal usage there is no risk as an attacker who can modify the environment variable of a user also can execute malicious code directly, however there have been problems with environment variable handling in su, cgi and sshd in the past, so it might be worth not forgetting about it) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Christian Heinrich Gesendet: Dienstag, April 16, 2019 2:55 AM An: Hank Edwards Cc: security-dev at openjdk.java.net Betreff: Re: JNI Signal Chaining and OWASP (Security) Hank, On Fri, 12 Apr 2019 at 09:41, Hank Edwards wrote: >We've recently discovered that the use of C is considered a code injection risk by security analysis tools, such as ones that check for OWASP 2017. I contribute to https://github.com/OWASP/Top10/pull/450 Can you please disclose the specific candidate[s] your security analysis tool has cited within the OWASP Top Ten 2017 release? -- Regards, Christian Heinrich http://cmlh.id.au/contact -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Apr 16 01:20:20 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Apr 2019 18:20:20 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" Message-ID: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> Anyone has time to review this performance rfe? The fix is based on Sergey's suggested patch. RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ Mach5 run is clean. Thanks, Valerie From weijun.wang at oracle.com Tue Apr 16 07:43:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Apr 2019 15:43:50 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <07ec0ae4-c5e6-266a-e149-faa5868b4b45@gmx.net> References: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com> <07ec0ae4-c5e6-266a-e149-faa5868b4b45@gmx.net> Message-ID: <71AA2B25-3C9A-4F0C-A5D5-F5673664EEAF@oracle.com> Hi Michael, Sorry about the late reply. I've just posted a new webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.06 Below are my replies to some of your questions. > >>> * 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? My redefinition is almost the same, it also set the minor status to be the error number. > >>> * 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? I'll implement it, using the fopen/fprintf functions I learnt 30 years ago. > >>> * 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. I'll remove this function and finally it will be GSSCredential.INDEFINITE_LIFETIME. > >>> ** 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. No, there will be no krb5.conf here. The new library is meant to work with no other additional settings. This function is used by export(). In MIT krb5, WELLKNOWN:ORG.H5L.REFERALS-REALM is added, but Java does not like the ":" there. Thanks, Max From weijun.wang at oracle.com Tue Apr 16 07:56:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Apr 2019 15:56:02 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20190320161023.GD9177@twosigma.com> 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> <20190320161023.GD9177@twosigma.com> Message-ID: There is been some time but I've uploaded a new webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.06 Major changes: 1. No more get expiration time from TGT, accept the one from AcquireCredentialsHandle, which makes GSS_C_INDEFINITE. 2. KRB5_TRACE can be set to any file name. /dev/stderr and stderr are recognized. Thanks, Max > On Mar 21, 2019, at 12:10 AM, Nico Williams wrote: > > 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. From xuelei.fan at oracle.com Tue Apr 16 15:58:54 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Apr 2019 08:58:54 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> Message-ID: <69d32064-a129-9809-d861-7c00237ab000@oracle.com> 213-217: Previously, the set/get of both verificationResults and verifyingProviders are synchronized. With this update, the get of verificationResults is not out of the set synchronized block, so there is a competition introduced. I think it would be nice to double check the verificationResults in the synchronized block. synchronized (JceSecurity.class) { + // double check if the provider has been verified ... } I did not get the idea to use verifyingProviders. In line 219, a provider was inserted into the map, and in the final block, line 235, the provider was removed from the map. There is no other update of the map, so the map should always be empty and not really used. Am I missing something? Could the verifyingProviders field get removed? 406-426: I may add a blank line between two different blocks (methods, field and methods). - 416 if (o instanceof IdentityWrapper == false) { + 416 if (!(o instanceof IdentityWrapper)) { I prefer to use "!" operator. Xuelei On 4/15/2019 6:20 PM, Valerie Peng wrote: > > Anyone has time to review this performance rfe? The fix is based on > Sergey's suggested patch. > > RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 > > Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie From mbalao at redhat.com Tue Apr 16 16:10:23 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 16 Apr 2019 13:10:23 -0300 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <16ddfd22-ad0c-0aa6-cde6-643496db745b@oracle.com> References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com> <16ddfd22-ad0c-0aa6-cde6-643496db745b@oracle.com> Message-ID: <742cfe99-eabc-a34a-23c3-9320b2191983@redhat.com> Hi Valerie, Thanks for your feedback. Here it is Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.02/ On 4/4/19 7:31 PM, Valerie Peng wrote: > The refList field inside the SessionKeyRef is changed to use LinkedList. > When there is a large number of P11Key objects, the refList.remove(this) > call (line1415) may takes a long long time. Have you considered some > other data structure like HashSet? > Yes, makes sense. Addressed in Webrev.02. > Lastly, on a somewhat relevant note, I noticed that line 311 in > p11_keymgmt.c, the if-check of jWrappingKeyHandle is against -1, it > should be against value 0? Also, the else method of this if-check? > should throw an exception? Would be good to address them as well. Yes, makes sense. Addressed in Webrev.02. I've run jdk-tier1 and jdk-tier2 test suites with and without the fix. I've found some failures but none of them was introduced by this fix and none of them seems related. JDK - Tier 1 Error jdk/tools/pack200/Pack200Props.java JDK - Tier 2 Error jdk/java/nio/channels/AsyncCloseAndInterrupt.java jdk/java/security/KeyPairGenerator/FinalizeHalf.java jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java jdk/tools/jar/multiRelease/Basic.java Failure jdk/java/net/MulticastSocket/Promiscuous.java jdk/java/net/MulticastSocket/SetLoopbackMode.java jdk/java/net/MulticastSocket/SetOutgoingIf.java jdk/java/net/MulticastSocket/Test.java jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java jdk/java/nio/channels/DatagramChannel/Promiscuous.java jdk/sun/security/util/RegisteredDomain/Versions.java Are we good to go? Kind regards, Martin.- From valerie.peng at oracle.com Tue Apr 16 21:16:21 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 16 Apr 2019 14:16:21 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <69d32064-a129-9809-d861-7c00237ab000@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> Message-ID: <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> Hi Xuelei, Thanks for the comments. On 4/16/2019 8:58 AM, Xuelei Fan wrote: > 213-217: > Previously, the set/get of both verificationResults and > verifyingProviders are synchronized.? With this update, the get of > verificationResults is not out of the set synchronized block, so there > is a competition introduced.? I think it would be nice to double check > the verificationResults in the synchronized block. > ? synchronized (JceSecurity.class) { > +???? //? double check if the provider has been verified > ????? ... > ? } > Hmm, are you talking about the verificationResults.get(pKey) call (line 206) and move it inside the block of synchronized (JceSecurity.class) (line 212)? If that's what you suggest, I think that'd take away the key idea of this performance rfe fix. My understanding of the patch is to use a ConcurrentHashMap for "verificationResult" so accesses to this "verificationResult" cache are controlled by the finer-grained model of ConcurrentHashMap. On the other hand, verifyingProviders map and the time consuming/potentially complex verifyProvider(...) call are still inside the synchronized (JceSecurity.class) block. Maybe it'd be clearer if I had re-written the code and move the verificationResults.put(...) calls outside of the synchronized (JceSecurity.class) block. The way I look at it, this change? separates out the "verificationResult" cache from the rest of the provider verification logic and uses ConcurrentHashMap instead of JceSecurity.class in order to improve performance. > I did not get the idea to use verifyingProviders.? In line 219, a > provider was inserted into the map, and in the final block, line 235, > the provider was removed from the map.? There is no other update of > the map, so the map should always be empty and not really used.? Am I > missing something?? Could the verifyingProviders field get removed? > The verifyingProviders field is for detecting potential recursions during the provider verification. the verifyProvider(URL, Provider) call will call ProviderVerifier.verify(). This will trigger provider jar file verification. Depending on runtime provider verification, this may trigger another provider being loaded/verified. As getVerificationResult(Provider) is being called by the pkg private static method JceSecurity.getInstance(...) which is used internally by other JCA classes, it's possible for getVerificationResult(...) to be recursively called and thus the verifyingProviders field will help detect if somehow verifying the current provider will require loading another JCA service from the current provider. > > 406-426: > I may add a blank line between two different blocks (methods, field > and methods). > Sure, added. > - 416 if (o instanceof IdentityWrapper == false) { > + 416? if (!(o instanceof IdentityWrapper)) { > > I prefer to use "!" operator. Sure. Webrev updated at: http://cr.openjdk.java.net/~valeriep/7107615/webrev.01/ Thanks, Valerie > > Xuelei > > On 4/15/2019 6:20 PM, Valerie Peng wrote: >> >> Anyone has time to review this performance rfe? The fix is based on >> Sergey's suggested patch. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Apr 16 22:43:02 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Apr 2019 15:43:02 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> Message-ID: <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> On 4/16/2019 2:16 PM, Valerie Peng wrote: > Hi Xuelei, > > Thanks for the comments. > > On 4/16/2019 8:58 AM, Xuelei Fan wrote: >> 213-217: >> Previously, the set/get of both verificationResults and >> verifyingProviders are synchronized.? With this update, the get of >> verificationResults is not out of the set synchronized block, so there >> is a competition introduced.? I think it would be nice to double check >> the verificationResults in the synchronized block. >> ? synchronized (JceSecurity.class) { >> +???? //? double check if the provider has been verified >> ????? ... >> ? } >> > Hmm, are you talking about the verificationResults.get(pKey) call (line > 206) and move it inside the block of synchronized (JceSecurity.class) > (line 212)? I meant to get/check twice. ... getVerificationResult(Provider p) { ... // get/check block Object o = verificationResults.get(pKey); if ( o == ...) { ... } else if (o != null) { ... } synchronized (JceSecurity.class) { // double check if the provider has been verified. // use the get/check block again Object o = verificationResults.get(pKey); if ( o == ...) { ... } else if (o != null) { ... } // further operation is the provider has not been verified. .... } } > If that's what you suggest, I think that'd take away the key > idea of this performance rfe fix. My understanding of the patch is to > use a ConcurrentHashMap for "verificationResult" so accesses to this > "verificationResult" cache are controlled by the finer-grained model of > ConcurrentHashMap. On the other hand, verifyingProviders map and the > time consuming/potentially complex verifyProvider(...) call are still > inside the synchronized (JceSecurity.class) block. Maybe it'd be clearer > if I had re-written the code and move the verificationResults.put(...) > calls outside of the synchronized (JceSecurity.class) block. The way I > look at it, this change? separates out the "verificationResult" cache > from the rest of the provider verification logic and uses > ConcurrentHashMap instead of JceSecurity.class in order to improve > performance. > I think there is a competition. If two threads try to get the lock, line 212-227 get executed in both thread. The double checking scheme could avoid it as when the 2nd thread get the lock, it will use the result of the 1st thread. >> I did not get the idea to use verifyingProviders.? In line 219, a >> provider was inserted into the map, and in the final block, line 235, >> the provider was removed from the map.? There is no other update of >> the map, so the map should always be empty and not really used.? Am I >> missing something?? Could the verifyingProviders field get removed? >> > The verifyingProviders field is for detecting potential recursions > during the provider verification. the verifyProvider(URL, Provider) call > will call ProviderVerifier.verify(). This will trigger provider jar file > verification. Depending on runtime provider verification, this may > trigger another provider being loaded/verified. As > getVerificationResult(Provider) is being called by the pkg private > static method JceSecurity.getInstance(...) which is used internally by > other JCA classes, it's possible for getVerificationResult(...) to be > recursively called and thus the verifyingProviders field will help > detect if somehow verifying the current provider will require loading > another JCA service from the current provider. > I see the point now. Thanks! >> >> 406-426: >> I may add a blank line between two different blocks (methods, field >> and methods). >> > Sure, added. > > >> - 416 if (o instanceof IdentityWrapper == false) { >> + 416? if (!(o instanceof IdentityWrapper)) { >> >> I prefer to use "!" operator. > > Sure. > Thanks! Xuelei > Webrev updated at: http://cr.openjdk.java.net/~valeriep/7107615/webrev.01/ > > Thanks, > Valerie >> >> Xuelei >> >> On 4/15/2019 6:20 PM, Valerie Peng wrote: >>> >>> Anyone has time to review this performance rfe? The fix is based on >>> Sergey's suggested patch. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie From xuelei.fan at oracle.com Tue Apr 16 23:37:08 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Apr 2019 16:37:08 -0700 Subject: RFR [13] JDK-8216326: SSLSocket stream close() does not close the associated socket Message-ID: <473d8782-1f21-bc31-b989-60b688850024@oracle.com> Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8216326/webrev.00/ Per the Socket specification, the close of the inputstream/outputstream should close the associated socket. The SSLSocketImpl is a sub-class of Socket and does not follow the spec. That's where the update come from. Thanks, Xuelei From jamil.j.nimeh at oracle.com Tue Apr 16 23:51:10 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 16 Apr 2019 16:51:10 -0700 Subject: RFR [13] JDK-8216326: SSLSocket stream close() does not close the associated socket In-Reply-To: <473d8782-1f21-bc31-b989-60b688850024@oracle.com> References: <473d8782-1f21-bc31-b989-60b688850024@oracle.com> Message-ID: Hi Xuelei, Besides the double semicolons on 983 and 1149, I think it looks fine. --Jamil On 4/16/2019 4:37 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8216326/webrev.00/ > > Per the Socket specification, the close of the > inputstream/outputstream should close the associated socket.? The > SSLSocketImpl is a sub-class of Socket and does not follow the spec.? > That's where the update come from. > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue Apr 16 23:57:04 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Apr 2019 16:57:04 -0700 Subject: RFR [13] JDK-8216326: SSLSocket stream close() does not close the associated socket In-Reply-To: References: <473d8782-1f21-bc31-b989-60b688850024@oracle.com> Message-ID: <1c4f0f5e-76dc-7843-65d3-87ecc7b29233@oracle.com> On 4/16/2019 4:51 PM, Jamil Nimeh wrote: > Hi Xuelei, > > Besides the double semicolons on 983 and 1149, I think it looks fine. > I will update accordingly. Thanks for the quick review! Xuelei > --Jamil > > On 4/16/2019 4:37 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> ?? http://cr.openjdk.java.net/~xuelei/8216326/webrev.00/ >> >> Per the Socket specification, the close of the >> inputstream/outputstream should close the associated socket.? The >> SSLSocketImpl is a sub-class of Socket and does not follow the spec. >> That's where the update come from. >> >> Thanks, >> Xuelei > From valerie.peng at oracle.com Wed Apr 17 21:09:51 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 17 Apr 2019 14:09:51 -0700 Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <742cfe99-eabc-a34a-23c3-9320b2191983@redhat.com> References: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com> <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com> <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com> <16ddfd22-ad0c-0aa6-cde6-643496db745b@oracle.com> <742cfe99-eabc-a34a-23c3-9320b2191983@redhat.com> Message-ID: <9a4e9966-1b72-a822-8ca5-7598671c72a7@oracle.com> Sure, I have no more comments. Thanks, Valerie On 4/16/2019 9:10 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your feedback. > > Here it is Webrev.02: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.02/ > > On 4/4/19 7:31 PM, Valerie Peng wrote: >> The refList field inside the SessionKeyRef is changed to use LinkedList. >> When there is a large number of P11Key objects, the refList.remove(this) >> call (line1415) may takes a long long time. Have you considered some >> other data structure like HashSet? >> > Yes, makes sense. Addressed in Webrev.02. > >> Lastly, on a somewhat relevant note, I noticed that line 311 in >> p11_keymgmt.c, the if-check of jWrappingKeyHandle is against -1, it >> should be against value 0? Also, the else method of this if-check >> should throw an exception? Would be good to address them as well. > Yes, makes sense. Addressed in Webrev.02. > > I've run jdk-tier1 and jdk-tier2 test suites with and without the fix. > I've found some failures but none of them was introduced by this fix and > none of them seems related. > > JDK - Tier 1 > > Error > > jdk/tools/pack200/Pack200Props.java > > JDK - Tier 2 > > Error > > jdk/java/nio/channels/AsyncCloseAndInterrupt.java > jdk/java/security/KeyPairGenerator/FinalizeHalf.java > jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java > jdk/tools/jar/multiRelease/Basic.java > > Failure > > jdk/java/net/MulticastSocket/Promiscuous.java > jdk/java/net/MulticastSocket/SetLoopbackMode.java > jdk/java/net/MulticastSocket/SetOutgoingIf.java > jdk/java/net/MulticastSocket/Test.java > jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java > jdk/java/nio/channels/DatagramChannel/Promiscuous.java > jdk/sun/security/util/RegisteredDomain/Versions.java > > Are we good to go? > > Kind regards, > Martin.- From ecki at zusammenkunft.net Wed Apr 17 22:43:16 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 17 Apr 2019 22:43:16 +0000 Subject: Refresh cacert File? In-Reply-To: References: Message-ID: hello, I think it was discussed on security-dev before but did not result in some action as far as I understand it. Currently the ?cacert? file shipped with 8u upstream builds is a bit outdated. It contains multiple expired certificates and misses latest additions. Also I noted there are multiple vendors struggling with this file. Since the later Java releases have a canonical source for that file with vetted licensing it totally would make sense to refresh I.e. backport the changes. Is there anything planned in that direction? (An Alternative would be to synchronize it with the Oracle SE version, this allows easier migration between the two packages, however I am not sure if this is an option from the licensing side) Greetings Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Apr 18 02:19:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Apr 2019 10:19:38 +0800 Subject: RFR CSR for 8200400 Restrict Sasl mechanisms In-Reply-To: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> References: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> Message-ID: <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> Pinga again for JDK 13. > On Nov 27, 2018, at 10:27 AM, Weijun Wang wrote: > > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8214331 > > One concern: > > When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly. > > Thanks > Max From sgehwolf at redhat.com Thu Apr 18 08:34:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 10:34:16 +0200 Subject: Refresh cacert File? In-Reply-To: References: Message-ID: <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> Hi, On Wed, 2019-04-17 at 22:43 +0000, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result in > some action as far as I understand it. Currently the ?cacert? file > shipped with 8u upstream builds is a bit outdated. It contains > multiple expired certificates and misses latest additions. Are you referring to these builds? https://adoptopenjdk.net/upstream.html The reason for this is that for OpenJDK 8u upstream builds the cacerts file will be empty unless the --with-cacerts-file configure option is being used. That's the case for the above 8u builds[1]. > Also I noted there are multiple vendors struggling with this file. There is bound to be divergence as no cacerts file is included upstream in OpenJDK 8u. > Since the later Java releases have a canonical source for that file > with vetted licensing it totally would make sense to refresh I.e. > backport the changes. Is there anything planned in that direction? There has been a proposal and IMO it would make sense to backport JEP319 to JDK 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008975.html Thanks, Severin [1] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/master/build-openjdk8.sh#L36 From ecki at zusammenkunft.net Thu Apr 18 08:52:48 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 18 Apr 2019 08:52:48 +0000 Subject: Refresh cacert File? In-Reply-To: <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> References: , <73f19aa62ddfb725c4e9f2a974103e597dbfd8f6.camel@redhat.com> Message-ID: Hello, Yes I would have expected the RH ?upstream? builds to have an empty cacerts file as they are described to be ?pristine?. However thanks for the pointer that this is not entirely the case. So 8u cacerts is still empty, which is I guess better than outdated. I would consider the content of the cacert file to be somewhat related to the security baseline version of Java and backporting the JEP (or actually refreshing the file before each release) would help a lot. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Severin Gehwolf Gesendet: Donnerstag, April 18, 2019 10:34 AM An: Bernd Eckenfels; jdk8u-dev at openjdk.java.net Cc: security-dev at openjdk.java.net Betreff: Re: Refresh cacert File? Hi, On Wed, 2019-04-17 at 22:43 +0000, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result in > some action as far as I understand it. Currently the ?cacert? file > shipped with 8u upstream builds is a bit outdated. It contains > multiple expired certificates and misses latest additions. Are you referring to these builds? https://adoptopenjdk.net/upstream.html The reason for this is that for OpenJDK 8u upstream builds the cacerts file will be empty unless the --with-cacerts-file configure option is being used. That's the case for the above 8u builds[1]. > Also I noted there are multiple vendors struggling with this file. There is bound to be divergence as no cacerts file is included upstream in OpenJDK 8u. > Since the later Java releases have a canonical source for that file > with vetted licensing it totally would make sense to refresh I.e. > backport the changes. Is there anything planned in that direction? There has been a proposal and IMO it would make sense to backport JEP319 to JDK 8u: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008975.html Thanks, Severin [1] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/master/build-openjdk8.sh#L36 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Thu Apr 18 17:13:07 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 18 Apr 2019 14:13:07 -0300 Subject: RFR 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed Message-ID: <1c18aba4-edcd-f829-0099-8b9109af1194@redhat.com> Hi Xuelei, Can I have a review for 8221271 [1]? Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.00/ I'm proposing the following changes: * RSACipher.java * Minor bug that is triggered only when "key" is not a RSAPublicKey or a RSAPrivateKey (i.e.: it can be a PKCS8Key). The whole point of having "rsaKey" variable is converting the key. * TestTLS12 triggered this bug in my Windows setup * TestTLS12.java * jdk.tls.useExtendedMasterSecret is read by SSLConfiguration only in initialization time and has to be false because the mechanism is currently not supported by SunPKCS11 crypto provider. Setting it in run time may have no effect (depending on when SSLConfiguration is initialized). That's why the test was failing on some environments. * Keys must be of PrivateKey and PublicKey types. Depending on the JKS keystore implementation, their subtype might be RSAPrivateKey, RSAPublicKey, PKCS8Key or a different one. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8221271 From xuelei.fan at oracle.com Thu Apr 18 22:42:32 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 18 Apr 2019 15:42:32 -0700 Subject: RFR 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed In-Reply-To: <1c18aba4-edcd-f829-0099-8b9109af1194@redhat.com> References: <1c18aba4-edcd-f829-0099-8b9109af1194@redhat.com> Message-ID: Hi Martin, Good catch of the bug! Looks fine to me. Thanks, Xuelei On 4/18/2019 10:13 AM, Martin Balao wrote: > Hi Xuelei, > > Can I have a review for 8221271 [1]? > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.00/ > > I'm proposing the following changes: > > * RSACipher.java > * Minor bug that is triggered only when "key" is not a RSAPublicKey or > a RSAPrivateKey (i.e.: it can be a PKCS8Key). The whole point of having > "rsaKey" variable is converting the key. > * TestTLS12 triggered this bug in my Windows setup > > * TestTLS12.java > * jdk.tls.useExtendedMasterSecret is read by SSLConfiguration only in > initialization time and has to be false because the mechanism is > currently not supported by SunPKCS11 crypto provider. Setting it in run > time may have no effect (depending on when SSLConfiguration is > initialized). That's why the test was failing on some environments. > * Keys must be of PrivateKey and PublicKey types. Depending on the JKS > keystore implementation, their subtype might be RSAPrivateKey, > RSAPublicKey, PKCS8Key or a different one. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8221271 > From valerie.peng at oracle.com Fri Apr 19 00:40:07 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 18 Apr 2019 17:40:07 -0700 Subject: RFR CSR for 8200400 Restrict Sasl mechanisms In-Reply-To: <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> References: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> Message-ID: <1b3e1e93-b18e-7d20-4fd7-b0fdd5266111@oracle.com> The CSR looks fine but some text got truncated and does not show up completely which may be confusing. Should the lines be made shorter so no truncation happen? As for returning null silently, at least the current javadoc did state that null is being returned if none can be produced with the supplied parameters. Do you have more friendly solutions, i.e. do you want to throw SaslException? I added myself as reviewer. Thanks, Valerie On 4/17/2019 7:19 PM, Weijun Wang wrote: > Pinga again for JDK 13. > >> On Nov 27, 2018, at 10:27 AM, Weijun Wang wrote: >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8214331 >> >> One concern: >> >> When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly. >> >> Thanks >> Max From weijun.wang at oracle.com Fri Apr 19 02:10:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Apr 2019 10:10:50 +0800 Subject: RFR CSR for 8200400 Restrict Sasl mechanisms In-Reply-To: <1b3e1e93-b18e-7d20-4fd7-b0fdd5266111@oracle.com> References: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> <1b3e1e93-b18e-7d20-4fd7-b0fdd5266111@oracle.com> Message-ID: > On Apr 19, 2019, at 8:40 AM, Valerie Peng wrote: > > > The CSR looks fine but some text got truncated and does not show up completely which may be confusing. Should the lines be made shorter so no truncation happen? I'll wrap the @systemProperty line in the src. New lines java.security are at most 79 chars. > > As for returning null silently, at least the current javadoc did state that null is being returned if none can be produced with the supplied parameters. Do you have more friendly solutions, i.e. do you want to throw SaslException? I dare not. I don't think there is an error here, I just pretend I don't recognize the name at all. Thanks, Max > > I added myself as reviewer. > > Thanks, > Valerie > On 4/17/2019 7:19 PM, Weijun Wang wrote: >> Pinga again for JDK 13. >> >>> On Nov 27, 2018, at 10:27 AM, Weijun Wang wrote: >>> >>> Please review the CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214331 >>> >>> One concern: >>> >>> When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly. >>> >>> Thanks >>> Max From mbalao at redhat.com Fri Apr 19 16:42:36 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 19 Apr 2019 13:42:36 -0300 Subject: RFR 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed In-Reply-To: References: <1c18aba4-edcd-f829-0099-8b9109af1194@redhat.com> Message-ID: <47b4fc7e-8c89-fee1-d60c-5d74718c5ddb@redhat.com> Hi Xuelei, Thanks for your review. Can we remove this test from the "test/jdk/ProblemList.txt" blacklist? Webrev.01 does so: * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.01/ I've tested this on jdk-submit and all tests pass. Thanks, Martin.- On 4/18/19 7:42 PM, Xuelei Fan wrote: > Hi Martin, > > Good catch of the bug!? Looks fine to me. > > Thanks, > Xuelei > > On 4/18/2019 10:13 AM, Martin Balao wrote: >> Hi Xuelei, >> >> Can I have a review for 8221271 [1]? >> >> Webrev.00: >> >> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.00/ >> >> I'm proposing the following changes: >> >> ? * RSACipher.java >> ?? * Minor bug that is triggered only when "key" is not a RSAPublicKey or >> a RSAPrivateKey (i.e.: it can be a PKCS8Key). The whole point of having >> "rsaKey" variable is converting the key. >> ??? * TestTLS12 triggered this bug in my Windows setup >> >> ? * TestTLS12.java >> ?? * jdk.tls.useExtendedMasterSecret is read by SSLConfiguration only in >> initialization time and has to be false because the mechanism is >> currently not supported by SunPKCS11 crypto provider. Setting it in run >> time may have no effect (depending on when SSLConfiguration is >> initialized). That's why the test was failing on some environments. >> ?? * Keys must be of PrivateKey and PublicKey types. Depending on the JKS >> keystore implementation, their subtype might be RSAPrivateKey, >> RSAPublicKey, PKCS8Key or a different one. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8221271 >> From xuelei.fan at oracle.com Fri Apr 19 19:33:57 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 19 Apr 2019 12:33:57 -0700 Subject: RFR 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed In-Reply-To: <47b4fc7e-8c89-fee1-d60c-5d74718c5ddb@redhat.com> References: <1c18aba4-edcd-f829-0099-8b9109af1194@redhat.com> <47b4fc7e-8c89-fee1-d60c-5d74718c5ddb@redhat.com> Message-ID: On 4/19/2019 9:42 AM, Martin Balao wrote: > Hi Xuelei, > > Thanks for your review. > > Can we remove this test from the "test/jdk/ProblemList.txt" blacklist? > Sure. Xuelei > Webrev.01 does so: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.01/ > > I've tested this on jdk-submit and all tests pass. > > Thanks, > Martin.- > > > > On 4/18/19 7:42 PM, Xuelei Fan wrote: >> Hi Martin, >> >> Good catch of the bug!? Looks fine to me. >> >> Thanks, >> Xuelei >> >> On 4/18/2019 10:13 AM, Martin Balao wrote: >>> Hi Xuelei, >>> >>> Can I have a review for 8221271 [1]? >>> >>> Webrev.00: >>> >>> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8221271/8221271.webrev.00/ >>> >>> I'm proposing the following changes: >>> >>> ? * RSACipher.java >>> ?? * Minor bug that is triggered only when "key" is not a RSAPublicKey or >>> a RSAPrivateKey (i.e.: it can be a PKCS8Key). The whole point of having >>> "rsaKey" variable is converting the key. >>> ??? * TestTLS12 triggered this bug in my Windows setup >>> >>> ? * TestTLS12.java >>> ?? * jdk.tls.useExtendedMasterSecret is read by SSLConfiguration only in >>> initialization time and has to be false because the mechanism is >>> currently not supported by SunPKCS11 crypto provider. Setting it in run >>> time may have no effect (depending on when SSLConfiguration is >>> initialized). That's why the test was failing on some environments. >>> ?? * Keys must be of PrivateKey and PublicKey types. Depending on the JKS >>> keystore implementation, their subtype might be RSAPrivateKey, >>> RSAPublicKey, PKCS8Key or a different one. >>> >>> Thanks, >>> Martin.- >>> >>> -- >>> [1] - https://bugs.openjdk.java.net/browse/JDK-8221271 >>> > From valerie.peng at oracle.com Fri Apr 19 22:58:37 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 19 Apr 2019 15:58:37 -0700 Subject: [13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity" In-Reply-To: <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> References: <8a98975a-5942-f430-b9ae-81b6a8d0b895@oracle.com> <69d32064-a129-9809-d861-7c00237ab000@oracle.com> <19cdf4e4-bb60-dc68-54db-a9f667eefb74@oracle.com> <0f2d9263-a5c8-bc56-33e0-deec113ce253@oracle.com> Message-ID: Ok, thanks for the double checking suggestion. Given the somewhat limited number of providers, I am exploring other data structures such as WeakHashMap. Will have to put this on hold during my upcoming week-long vacation and resume on 4/29. Thanks! Valerie On 4/16/2019 3:43 PM, Xuelei Fan wrote: > On 4/16/2019 2:16 PM, Valerie Peng wrote: >> Hi Xuelei, >> >> Thanks for the comments. >> >> On 4/16/2019 8:58 AM, Xuelei Fan wrote: >>> 213-217: >>> Previously, the set/get of both verificationResults and >>> verifyingProviders are synchronized.? With this update, the get of >>> verificationResults is not out of the set synchronized block, so >>> there is a competition introduced.? I think it would be nice to >>> double check the verificationResults in the synchronized block. >>> ? synchronized (JceSecurity.class) { >>> +???? //? double check if the provider has been verified >>> ????? ... >>> ? } >>> >> Hmm, are you talking about the verificationResults.get(pKey) call >> (line 206) and move it inside the block of synchronized >> (JceSecurity.class) (line 212)? > I meant to get/check twice. > ... getVerificationResult(Provider p) { > ??? ... > // get/check block > ??? Object o = verificationResults.get(pKey); > ??? if ( o == ...) { > ??????? ... > ??? } else if (o != null) { > ??????? ... > ??? } > > ??? synchronized (JceSecurity.class) { > ?????? // double check if the provider has been verified. > // use the get/check block again > ?????? Object o = verificationResults.get(pKey); > ?????? if ( o == ...) { > ?????????? ... > ?????? } else if (o != null) { > ?????????? ... > ?????? } > > ?????? // further operation is the provider has not been verified. > ?????? .... > ??? } > } > >> If that's what you suggest, I think that'd take away the key idea of >> this performance rfe fix. My understanding of the patch is to use a >> ConcurrentHashMap for "verificationResult" so accesses to this >> "verificationResult" cache are controlled by the finer-grained model >> of ConcurrentHashMap. On the other hand, verifyingProviders map and >> the time consuming/potentially complex verifyProvider(...) call are >> still inside the synchronized (JceSecurity.class) block. Maybe it'd >> be clearer if I had re-written the code and move the >> verificationResults.put(...) calls outside of the synchronized >> (JceSecurity.class) block. The way I look at it, this change >> separates out the "verificationResult" cache from the rest of the >> provider verification logic and uses ConcurrentHashMap instead of >> JceSecurity.class in order to improve performance. >> > I think there is a competition.? If two threads try to get the lock, > line 212-227 get executed in both thread.? The double checking scheme > could avoid it as when the 2nd thread get the lock, it will use the > result of the 1st thread. > >>> I did not get the idea to use verifyingProviders.? In line 219, a >>> provider was inserted into the map, and in the final block, line >>> 235, the provider was removed from the map.? There is no other >>> update of the map, so the map should always be empty and not really >>> used.? Am I missing something?? Could the verifyingProviders field >>> get removed? >>> >> The verifyingProviders field is for detecting potential recursions >> during the provider verification. the verifyProvider(URL, Provider) >> call will call ProviderVerifier.verify(). This will trigger provider >> jar file verification. Depending on runtime provider verification, >> this may trigger another provider being loaded/verified. As >> getVerificationResult(Provider) is being called by the pkg private >> static method JceSecurity.getInstance(...) which is used internally >> by other JCA classes, it's possible for getVerificationResult(...) to >> be recursively called and thus the verifyingProviders field will help >> detect if somehow verifying the current provider will require loading >> another JCA service from the current provider. >> > I see the point now.? Thanks! > >>> >>> 406-426: >>> I may add a blank line between two different blocks (methods, field >>> and methods). >>> >> Sure, added. >> >> >>> - 416 if (o instanceof IdentityWrapper == false) { >>> + 416? if (!(o instanceof IdentityWrapper)) { >>> >>> I prefer to use "!" operator. >> >> Sure. >> > Thanks! > > Xuelei > >> Webrev updated at: >> http://cr.openjdk.java.net/~valeriep/7107615/webrev.01/ >> >> Thanks, >> Valerie >>> >>> Xuelei >>> >>> On 4/15/2019 6:20 PM, Valerie Peng wrote: >>>> >>>> Anyone has time to review this performance rfe? The fix is based on >>>> Sergey's suggested patch. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-7107615 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/ >>>> >>>> Mach5 run is clean. >>>> >>>> Thanks, >>>> Valerie From sha.jiang at oracle.com Mon Apr 22 03:27:47 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 22 Apr 2019 11:27:47 +0800 Subject: RFR[13] JDK-8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible Message-ID: <29bf326b-3fe4-6035-bc96-5e871ea19d77@oracle.com> Hi, This fix just makes some improvements for the manual test javax/net/ssl/compatibility/Compatibility.java in the following points: 1. The test cases could be customized. 2. The current testing JDK (namely, the test.jdk) always be covered. 3. It allows to exclude the test cases if the JSSE server and client are from a same JDK build. 4. An alternative security properties file can be specified. These changes could be used by an auto test, which is derived from this manual test. Webrev: http://cr.openjdk.java.net/~jjiang/8222391/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8222391 Best regards, John Jiang From xuelei.fan at oracle.com Mon Apr 22 15:28:55 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Apr 2019 08:28:55 -0700 Subject: RFR[13] JDK-8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible In-Reply-To: <29bf326b-3fe4-6035-bc96-5e871ea19d77@oracle.com> References: <29bf326b-3fe4-6035-bc96-5e871ea19d77@oracle.com> Message-ID: Looks good to me. Xuelei On 4/21/2019 8:27 PM, sha.jiang at oracle.com wrote: > Hi, > This fix just makes some improvements for the manual test > javax/net/ssl/compatibility/Compatibility.java in the following points: > 1. The test cases could be customized. > 2. The current testing JDK (namely, the test.jdk) always be covered. > 3. It allows to exclude the test cases if the JSSE server and client are > from a same JDK build. > 4. An alternative security properties file can be specified. > > These changes could be used by an auto test, which is derived from this > manual test. > > Webrev: http://cr.openjdk.java.net/~jjiang/8222391/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8222391 > > Best regards, > John Jiang > From sean.mullan at oracle.com Mon Apr 22 17:19:09 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 22 Apr 2019 13:19:09 -0400 Subject: RFR CSR for 8200400 Restrict Sasl mechanisms In-Reply-To: <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> References: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> Message-ID: Hi Max, I would like to also review it but may need a couple more days as I'm catching up after being on vacation. Do you also have a webrev of the implementation? I would like to see how the check is implemented. Thanks, Sean On 4/17/19 10:19 PM, Weijun Wang wrote: > Pinga again for JDK 13. > >> On Nov 27, 2018, at 10:27 AM, Weijun Wang wrote: >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8214331 >> >> One concern: >> >> When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly. >> >> Thanks >> Max > From weijun.wang at oracle.com Mon Apr 22 23:17:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Apr 2019 07:17:18 +0800 Subject: RFR CSR for 8200400 Restrict Sasl mechanisms In-Reply-To: References: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com> <169BA5E2-C97F-47D6-9279-1B8404E6782E@oracle.com> Message-ID: https://cr.openjdk.java.net/~weijun/8200400/webrev.00/ Thanks, Max > On Apr 23, 2019, at 1:19 AM, Sean Mullan wrote: > > Hi Max, > > I would like to also review it but may need a couple more days as I'm catching up after being on vacation. Do you also have a webrev of the implementation? I would like to see how the check is implemented. > > Thanks, > Sean > > On 4/17/19 10:19 PM, Weijun Wang wrote: >> Pinga again for JDK 13. >>> On Nov 27, 2018, at 10:27 AM, Weijun Wang wrote: >>> >>> Please review the CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214331 >>> >>> One concern: >>> >>> When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly. >>> >>> Thanks >>> Max From weijun.wang at oracle.com Tue Apr 23 04:53:59 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Apr 2019 12:53:59 +0800 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> Message-ID: <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> Hi Martin, Sorry for the delay. I went through the changes and they are all in the correct place. Next, I'll read the RFC carefully and make sure all behaviors are correct. In the mean time, you can start preparing the CSR. BTW, what kinds of real world KDC have you tested against? Thanks, Max > >> On Dec 10, 2018, at 11:39 PM, Martin Balao wrote: >> >> Hi, >> >> I'd like to propose an implementation of Kerberos cross-realm referrals >> for OpenJDK's client, according to RFC 6806 [1]. >> >> Request for Enhancement: "JDK-8215032 - Support Kerberos cross-realm >> referrals (RFC 6806)" [2]. >> >> Related tickets: "JDK-6631053 - Support canonicalize in Kerberos >> configuration file" [3] and "JDK-8005819 - Support cross-realm MSSFU" [4]. >> >> Webrev.00: >> >> * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00/ >> * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.00.zip >> >> Implementation notes: >> >> * System properties introduced: >> * sun.security.krb5.disableReferrals: disable this feature >> * sun.security.krb5.maxReferrals: max referral hops for both client >> and server referrals (5 by default, as suggested by RFC 6806) >> * CSR will be needed >> >> * NT-ENTERPRISE principals >> * Supported >> * Krb5LoginModule has not been extended to use it. However, I'm open >> to discuss this API first and propose an implementation then -either in >> the context of this enhancement or in a new one-. >> >> * Client referrals >> * Supported >> * Client announces support setting CANONICALIZE flag >> * Fallback: if a failure occurs, client retries without CANONICALIZE flag >> >> * Server referrals >> * Supported >> * Client announces support setting CANONICALIZE flag >> * Fallback: if a failure occurs, client retries without CANONICALIZE flag >> >> * FAST >> * RFC 6806 - Section 11 FAST scheme supported >> * Complete FAST support (RFC 6113) is out of scope >> * RFC 6806 - Section 11 FAST is mandatory for AS-REQ, and optional for >> TGS-REQ. Client does not ask for it in TGS requests -sending >> PA-REQ-ENC-PA-REP PA data- for compatibility reasons. Some servers do >> not support PA-REQ-ENC-PA-REP in TGS requests and if no checksum is >> available in TGS responses (even though ENC_PA_REP flag is set), no >> enforcement is possible. >> * MIT's client does not send PA-REQ-ENC-PA-REP requests for TGS, only >> for TGTs [5] >> * MIT's client only verifies PA-REQ-ENC-PA-REP for TGTs [6] >> * MIT's KDC supports PA-REQ-ENC-PA-REP in TGT [7] and TGS [8] >> replies, but Microsoft's Active Directory 2016 does not apparently. >> >> * Cache >> * If a referral loop is introduced when adding a new entry to the >> cache, we break the loop by invalidating the "next" entry >> * Adding an entry to the cache may override a previous one >> * The assumption is that newer information is more accurate >> * For a given Principal Name, there can only be one "Realm -> Next >> Realm" referral entry (whose lifetime is given by the referral krbtgt >> ticket) >> >> * Security >> * Client name changes are allowed in AS-REPs only if: >> * Client sent CANONICALIZE >> * Server supports RFC 6806 - Section 11 FAST >> * Authenticated checksum is correct >> * Server name changes are allowed in TGS-REPs only if: >> * Client sent CANONICALIZE >> * It's for a referral (sname = krbtgt/TO-REALM.COM at FROM-REALM.COM) >> >> * Testing >> * KDC used for testing purposes was extended to include basic support >> of RFC 6806 server-side >> * NT-ENTERPRISE principals >> * Client referrals >> * Server referrlas >> * FAST - Section 11 scheme >> * ReferralsTest functional test added >> * Client referral with NT-ENTERPRISE principal >> * Server referral >> >> Regressing testing: >> >> * No regressions found in jdk/sun/security/krb5 category. >> * Test results: passed: 128 >> >> I'd be grateful if someone can have a look. >> >> Kind regards, >> Martin.- >> >> -- >> [1] - https://tools.ietf.org/html/rfc6806.html >> [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 >> [3] - https://bugs.openjdk.java.net/browse/JDK-6631053 >> [4] - https://bugs.openjdk.java.net/browse/JDK-8005819 >> [5] - >> https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1421 >> [6] - >> https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/lib/krb5/krb/get_in_tkt.c#L1665 >> [7] - >> https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_as_req.c#L326 >> [8] - >> https://github.com/krb5/krb5/blob/f0bcb86131e385b2603ccf0f3c7d65aa3891b220/src/kdc/do_tgs_req.c#L724 > From mbalao at redhat.com Tue Apr 23 19:26:04 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 23 Apr 2019 16:26:04 -0300 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 Message-ID: Hi, I'd like to propose a fix for 8222805 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.00/ This issue is similar to 8221271 [2]: jdk.tls.disabledAlgorithms property is only read when SSLAlgorithmConstraints class is initialized and if this happens before TestTLS12.initialize method is executed, RSASSA-PSS algorithm is not disabled. This only reproduces on some environments. There are no more properties used in TestTLS12 so I don't expect a similar failure to occur. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8222805 [2] - https://bugs.openjdk.java.net/browse/JDK-8221271 From xuelei.fan at oracle.com Tue Apr 23 20:02:06 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Apr 2019 13:02:06 -0700 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: References: Message-ID: <184c0ce9-2707-d852-3c5c-62668f16a3f0@oracle.com> I think "jdk.tls.disabledAlgorithms" is a Security Property, while "-Djdk.tls.disabledAlgorithms=..." is used to define System Property. I'm not sure if this update works. You could put the Security Property update code in the beginning of the main() method, or the initialize() method which is the 1st code executed in the main() method. Xuelei On 4/23/2019 12:26 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for 8222805 [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.00/ > > This issue is similar to 8221271 [2]: jdk.tls.disabledAlgorithms > property is only read when SSLAlgorithmConstraints class is initialized > and if this happens before TestTLS12.initialize method is executed, > RSASSA-PSS algorithm is not disabled. This only reproduces on some > environments. There are no more properties used in TestTLS12 so I don't > expect a similar failure to occur. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8222805 > [2] - https://bugs.openjdk.java.net/browse/JDK-8221271 > From sean.mullan at oracle.com Tue Apr 23 20:33:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Apr 2019 16:33:37 -0400 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: References: Message-ID: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> Hi Martin, On 4/23/19 3:26 PM, Martin Balao wrote: > Hi, > > I'd like to propose a fix for 8222805 [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.00/ > > This issue is similar to 8221271 [2]: jdk.tls.disabledAlgorithms > property is only read when SSLAlgorithmConstraints class is initialized > and if this happens before TestTLS12.initialize method is executed, > RSASSA-PSS algorithm is not disabled. This only reproduces on some > environments. There are no more properties used in TestTLS12 so I don't > expect a similar failure to occur. I don't think this will work the way you think. The reason is that there is no system property for jdk.tls.disabledAlgorithms. It is only a security property so java -Djdk.tls.disabledAlgorithms has no effect. (You could verify that by printing out the value of the jdk.tls.disabledAlgorithms security property in the test). A workaround is to specify -Djava.security.properties= where file contains the single line: jdk.tls.disabledAlgorithms=RSASSA-PSS This will override the value of the jdk.tls.disabledAlgorithms property in the java.security file. However, I think there may be a more subtle bug or configuration issue underlying this. It seems like this could come up in real scenarios. You should never disable a strong algorithm, even if it is unsupported, in order to establish a TLS session. It should be able to negotiate a session using a different algorithm. We have seen a similar issue with RSA-PSS like this with the SunMSCAPI provider but I think that was a bit different. Tony, or Xuelei, does this seem familiar? So, unless you have a good explanation for that, on the outset, I don't think the fix is appropriate and we should spend more time looking at this. In the interests of time, I would ProblemList this test and open a separate bug for this issue. Thanks, Sean > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8222805 > [2] - https://bugs.openjdk.java.net/browse/JDK-8221271 > From sean.mullan at oracle.com Tue Apr 23 20:41:21 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Apr 2019 16:41:21 -0400 Subject: RFR: 8036608: Key.getAlgorithm link to standard algorithm names needs to be updated Message-ID: Please review this javadoc only change to be more specific about the standard algorithm names that Key.getAlgorithm may return. The fix lists the specific sections of the Standard Algorithm Names specification that are relevant. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8036608/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8036608 Thanks, Sean From mbalao at redhat.com Tue Apr 23 20:52:04 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 23 Apr 2019 17:52:04 -0300 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> Message-ID: Hi Sean, Xuelei, Thanks for your feedback. You're both right, the security property value was not being considered (and my testing environments are not helping at all, as I could not reproduce the bug). Here it's Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.01/ @Xuelei, is that what you meant? Kind regards, Martin.- From sha.jiang at oracle.com Wed Apr 24 02:39:56 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 24 Apr 2019 10:39:56 +0800 Subject: RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Message-ID: Hi, NSS 3.41 has been approved, so just build this version for windows (with VS2017) and macosx. Webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8204203 Best regards, John Jiang From sean.mullan at oracle.com Wed Apr 24 10:12:25 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Apr 2019 06:12:25 -0400 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> Message-ID: <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> Hi Martin, I am still concerned about the odd workaround for this issue. Can you comment on my previous comment that I raised?: On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a more subtle bug or configuration issue > underlying this. It seems like this could come up in real scenarios. You > should never disable a strong algorithm, even if it is unsupported, in > order to establish a TLS session. It should be able to negotiate a > session using a different algorithm. > > We have seen a similar issue with RSA-PSS like this with the SunMSCAPI > provider but I think that was a bit different. Tony, or Xuelei, does > this seem familiar? > > So, unless you have a good explanation for that, on the outset, I don't > think the fix is appropriate and we should spend more time looking at > this. In the interests of time, I would ProblemList this test and open a > separate bug for this issue. Thanks, Sean On 4/23/19 4:52 PM, Martin Balao wrote: > Hi Sean, Xuelei, > > Thanks for your feedback. You're both right, the security property value > was not being considered (and my testing environments are not helping at > all, as I could not reproduce the bug). > > Here it's Webrev.01: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.01/ > > @Xuelei, is that what you meant? > > Kind regards, > Martin.- > From mbalao at redhat.com Wed Apr 24 14:38:56 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 24 Apr 2019 11:38:56 -0300 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> Message-ID: <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> Hi Sean, On 4/24/19 7:12 AM, Sean Mullan wrote: > > I am still concerned about the odd workaround for this issue. Can you > comment on my previous comment that I raised?: > > On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a > more subtle bug or configuration issue >> underlying this. It seems like this could come up in real scenarios. You >> should never disable a strong algorithm, even if it is unsupported, in >> order to establish a TLS session. It should be able to negotiate a >> session using a different algorithm. >> The reason why we disable the algorithm in the test is related to [1]. What happens is that we need to have SunPKCS11, SUN and JSSE crypto providers enabled for a successful TLS communication in FIPS mode. The reason we need SUN -which looks as the odd one out there- are X.509 certificates. However, having SUN enabled (after JSSE experimental FIPS changes) means that we support "RSAPSS" for the TLS communication. When this algorithm is applied by SUN provider to a SunPKCS11-sensitive key (keys are sensitive in FIPS mode and cannot be converted), it fails. As I said in [1], we need a good solution beyond the workaround of disabling concrete algorithms. I'd be happy to update the test when this is fixed. Kind regards, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html From xuelei.fan at oracle.com Wed Apr 24 15:25:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 24 Apr 2019 08:25:19 -0700 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> Message-ID: <197ed78b-0878-2a5d-9d0e-1c17588eef96@oracle.com> Hi Martin, Would you mind add some comments about the purpose of it? BTW, the file name, TestTLS12, is not as straightforward as to catch the purpose of the test. What do you think if using FipsModeTLS12? Xuelei On 4/24/2019 7:38 AM, Martin Balao wrote: > Hi Sean, > > On 4/24/19 7:12 AM, Sean Mullan wrote: >> >> I am still concerned about the odd workaround for this issue. Can you >> comment on my previous comment that I raised?: >> >> On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a >> more subtle bug or configuration issue >>> underlying this. It seems like this could come up in real scenarios. You >>> should never disable a strong algorithm, even if it is unsupported, in >>> order to establish a TLS session. It should be able to negotiate a >>> session using a different algorithm. >>> > > The reason why we disable the algorithm in the test is related to [1]. > What happens is that we need to have SunPKCS11, SUN and JSSE crypto > providers enabled for a successful TLS communication in FIPS mode. The > reason we need SUN -which looks as the odd one out there- are X.509 > certificates. However, having SUN enabled (after JSSE experimental FIPS > changes) means that we support "RSAPSS" for the TLS communication. When > this algorithm is applied by SUN provider to a SunPKCS11-sensitive key > (keys are sensitive in FIPS mode and cannot be converted), it fails. As > I said in [1], we need a good solution beyond the workaround of > disabling concrete algorithms. I'd be happy to update the test when this > is fixed. > > Kind regards, > Martin.- > > -- > [1] - > https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html > From sean.mullan at oracle.com Wed Apr 24 17:34:16 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Apr 2019 13:34:16 -0400 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> Message-ID: On 4/24/19 10:38 AM, Martin Balao wrote: > Hi Sean, > > On 4/24/19 7:12 AM, Sean Mullan wrote: >> >> I am still concerned about the odd workaround for this issue. Can you >> comment on my previous comment that I raised?: >> >> On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a >> more subtle bug or configuration issue >>> underlying this. It seems like this could come up in real scenarios. You >>> should never disable a strong algorithm, even if it is unsupported, in >>> order to establish a TLS session. It should be able to negotiate a >>> session using a different algorithm. >>> > > The reason why we disable the algorithm in the test is related to [1]. > What happens is that we need to have SunPKCS11, SUN and JSSE crypto > providers enabled for a successful TLS communication in FIPS mode. The > reason we need SUN -which looks as the odd one out there- are X.509 > certificates. However, having SUN enabled (after JSSE experimental FIPS > changes) means that we support "RSAPSS" for the TLS communication. When > this algorithm is applied by SUN provider to a SunPKCS11-sensitive key > (keys are sensitive in FIPS mode and cannot be converted), it fails. As > I said in [1], we need a good solution beyond the workaround of > disabling concrete algorithms. I'd be happy to update the test when this > is fixed. Ok, thanks for that link. We need to file another bug to track the underlying issue then as I don't see anything filed. It seems quite likely that this could come up in a real scenario and telling a customer to disable RSA-PSS is just not right in my opinion. Can you please file a bug for that and link it to this test bug? I'm ok with you pushing this test workaround fix for now since we need to get this resolved soon. I also agree with Xuelei that it would be helpful to add more comments in the test as to why the security property workaround is needed. Thanks, Sean > > Kind regards, > Martin.- > > -- > [1] - > https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html > From mbalao at redhat.com Wed Apr 24 19:38:43 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 24 Apr 2019 16:38:43 -0300 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> Message-ID: <370bdff2-41ff-9101-d79c-6902d014826b@redhat.com> On 4/24/19 2:34 PM, Sean Mullan wrote: > > Can you please file a bug for that and link it to this test bug? I'm ok > with you pushing this test workaround fix for now since we need to get > this resolved soon. I also agree with Xuelei that it would be helpful to > add more comments in the test as to why the security property workaround > is needed. > A bug has been filed. See "8222937: Cannot establish TLS connections in FIPS mode" [1]. Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8222937 From mbalao at redhat.com Wed Apr 24 19:39:25 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 24 Apr 2019 16:39:25 -0300 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <197ed78b-0878-2a5d-9d0e-1c17588eef96@oracle.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> <197ed78b-0878-2a5d-9d0e-1c17588eef96@oracle.com> Message-ID: <1211c663-d34d-1370-6248-064ee731b3c2@redhat.com> Hi Xuelei, Thanks for your review. On 4/24/19 12:25 PM, Xuelei Fan wrote> Would you mind add some comments about the purpose of it? Sure. > What do you think if using FipsModeTLS12? Yes, I'm happy to rename it. In fact, it used to be under a "fips" folder. Here it's Webrev.02 with the previous: * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.02/ Are we good to go? Thanks, Martin.- From xuelei.fan at oracle.com Wed Apr 24 21:07:54 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 24 Apr 2019 14:07:54 -0700 Subject: RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 In-Reply-To: <1211c663-d34d-1370-6248-064ee731b3c2@redhat.com> References: <31cdffe8-e39d-98b4-113a-f663d207f872@oracle.com> <6257c775-75f7-2d54-95b6-1aec05f31133@oracle.com> <02a72a34-ec67-d54d-d169-7fcee11d62c7@redhat.com> <197ed78b-0878-2a5d-9d0e-1c17588eef96@oracle.com> <1211c663-d34d-1370-6248-064ee731b3c2@redhat.com> Message-ID: Thanks for adding more comments. I'm fine to move ahead. Thanks, Xuelei On 4/24/2019 12:39 PM, Martin Balao wrote: > Hi Xuelei, > > Thanks for your review. > > On 4/24/19 12:25 PM, Xuelei Fan wrote> Would you mind add some comments > about the purpose of it? > Sure. > >> What do you think if using FipsModeTLS12? > > Yes, I'm happy to rename it. In fact, it used to be under a "fips" folder. > > Here it's Webrev.02 with the previous: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8222805/8222805.webrev.02/ > > Are we good to go? > > Thanks, > Martin.- > From weijun.wang at oracle.com Fri Apr 26 07:22:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Apr 2019 15:22:51 +0800 Subject: RFR 8223003: SunMSCAPI keys are not cleaned up Message-ID: <95ED6268-F1C9-45D4-9A5F-EB61A73CA006@oracle.com> Please take a look at https://cr.openjdk.java.net/~weijun/8223003/webrev.00/ Two errors are fixed: 1. CKey::cleanup is not implemented. 2. A re-fix of JDK-8163896 which was re-introduced by JDK-8213009. No new test, the existing java/security/KeyPairGenerator/FinalizeHalf.java is able to confirm #2. Unfortunately it didn't fail because of #1. Anyone knows what kind of noreg-* I can use? I can only think of noreg-other with a comment. Thanks, Max From ivan.gerasimov at oracle.com Fri Apr 26 08:14:31 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 26 Apr 2019 01:14:31 -0700 Subject: RFR 8223003: SunMSCAPI keys are not cleaned up In-Reply-To: <95ED6268-F1C9-45D4-9A5F-EB61A73CA006@oracle.com> References: <95ED6268-F1C9-45D4-9A5F-EB61A73CA006@oracle.com> Message-ID: <946d9906-ccea-6b58-4cf3-fc53e132d5d3@oracle.com> Hi Max! The fix looks good to me. A couple of minor comments: - the changes to CKeyStore.java seem unnecessary, since there is a variant of CPrivateKey.of() accepting two handles. - if you just add the bug number 8223003 to the @bug line of FinalizeHalf.java, you won't need to specify noreg- label :) I think, it makes sense to update the bug list because this test does verify the fix. With kind regards, Ivan On 4/26/19 12:22 AM, Weijun Wang wrote: > Please take a look at > > https://cr.openjdk.java.net/~weijun/8223003/webrev.00/ > > Two errors are fixed: > > 1. CKey::cleanup is not implemented. > > 2. A re-fix of JDK-8163896 which was re-introduced by JDK-8213009. > > No new test, the existing java/security/KeyPairGenerator/FinalizeHalf.java is able to confirm #2. Unfortunately it didn't fail because of #1. > > Anyone knows what kind of noreg-* I can use? I can only think of noreg-other with a comment. > > Thanks, > Max > > -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Fri Apr 26 09:25:32 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Apr 2019 17:25:32 +0800 Subject: RFR 8223003: SunMSCAPI keys are not cleaned up In-Reply-To: <946d9906-ccea-6b58-4cf3-fc53e132d5d3@oracle.com> References: <95ED6268-F1C9-45D4-9A5F-EB61A73CA006@oracle.com> <946d9906-ccea-6b58-4cf3-fc53e132d5d3@oracle.com> Message-ID: <9FA23F47-D169-42B9-B100-110894BC55F8@oracle.com> Thanks. I initially removed the static methods using 2 handles but later realized it?s used by native codes. I?ll revert the CKeyStore change. ?Max > ? 2019?4?26??16:14?Ivan Gerasimov ??? > > Hi Max! > > The fix looks good to me. > > A couple of minor comments: > - the changes to CKeyStore.java seem unnecessary, since there is a variant of CPrivateKey.of() accepting two handles. > - if you just add the bug number 8223003 to the @bug line of FinalizeHalf.java, you won't need to specify noreg- label :) > I think, it makes sense to update the bug list because this test does verify the fix. > > With kind regards, > Ivan > > >> On 4/26/19 12:22 AM, Weijun Wang wrote: >> Please take a look at >> >> https://cr.openjdk.java.net/~weijun/8223003/webrev.00/ >> >> Two errors are fixed: >> >> 1. CKey::cleanup is not implemented. >> >> 2. A re-fix of JDK-8163896 which was re-introduced by JDK-8213009. >> >> No new test, the existing java/security/KeyPairGenerator/FinalizeHalf.java is able to confirm #2. Unfortunately it didn't fail because of #1. >> >> Anyone knows what kind of noreg-* I can use? I can only think of noreg-other with a comment. >> >> Thanks, >> Max >> >> > > -- > With kind regards, > Ivan Gerasimov > From christoph.langer at sap.com Fri Apr 26 22:04:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 22:04:05 +0000 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate Message-ID: Hi, In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root certificate [0]. This change has gone into 12.0.1 and also 12.0.2 but it's not part of JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, 11.0.4-oracle). Could you please shed some light into this unusual proceeding? Usually such changes would happen in jdk/jdk first, and then be backported, I guess. Is there any reason why the certificate was only added to the jdk12 updates train? Will the certificate be brought to the other update versions later on? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8216577 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Apr 26 22:53:48 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Apr 2019 18:53:48 -0400 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: On 4/26/19 6:04 PM, Langer, Christoph wrote: > Hi, > > In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root > certificate [0]. > > This change has gone into 12.0.1 and also 12.0.2 but it?s not part of > JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, > 11.0.4-oracle). Could you please shed some light into this unusual > proceeding? Usually such changes would happen in jdk/jdk first, and then > be backported, I guess. > > Is there any reason why the certificate was only added to the jdk12 > updates train? It should be in 11.0.3-oracle. The backport issue is Confidential so maybe that is why you thought it wasn't. JDK 13 seems like an oversight. Rajan, any idea what happened? Can you push this to JDK 13? > Will the certificate be brought to the other update > versions later on? Which other updates? --Sean > > Thanks > > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8216577 > From christoph.langer at sap.com Sat Apr 27 06:10:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 27 Apr 2019 06:10:00 +0000 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: > -----Original Message----- > From: Sean Mullan > Sent: Samstag, 27. April 2019 00:54 > To: Langer, Christoph ; security- > dev at openjdk.java.net; Rajan Halade > Subject: Re: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate > > On 4/26/19 6:04 PM, Langer, Christoph wrote: > > Hi, > > > > In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root > > certificate [0]. > > > > This change has gone into 12.0.1 and also 12.0.2 but it's not part of > > JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, > > 11.0.4-oracle). Could you please shed some light into this unusual > > proceeding? Usually such changes would happen in jdk/jdk first, and then > > be backported, I guess. > > > > Is there any reason why the certificate was only added to the jdk12 > > updates train? > > It should be in 11.0.3-oracle. The backport issue is Confidential so > maybe that is why you thought it wasn't. Yep, that explains it. Any particular reason that the 11.0.3-oracle backport is confidential? Could you make it public? Just asking... > JDK 13 seems like an oversight. Rajan, any idea what happened? Can you > push this to JDK 13? Thanks in advance. Looking forward to see this in JDK 13. > > Will the certificate be brought to the other update > > versions later on? > > Which other updates? Ok, yes, that's all the Oracle updates. I'll bring the change to OpenJDK 11 updates then. Thanks Christoph From weijun.wang at oracle.com Sat Apr 27 10:24:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 27 Apr 2019 18:24:04 +0800 Subject: RFR 8223003: SunMSCAPI keys are not cleaned up In-Reply-To: <946d9906-ccea-6b58-4cf3-fc53e132d5d3@oracle.com> References: <95ED6268-F1C9-45D4-9A5F-EB61A73CA006@oracle.com> <946d9906-ccea-6b58-4cf3-fc53e132d5d3@oracle.com> Message-ID: <74BEC718-04D3-4998-8744-6A388322ED0B@oracle.com> Pushed at https://hg.openjdk.java.net/jdk/jdk/rev/2cac7d48db4c. Thanks, Max > On Apr 26, 2019, at 4:14 PM, Ivan Gerasimov wrote: > > Hi Max! > > The fix looks good to me. > > A couple of minor comments: > - the changes to CKeyStore.java seem unnecessary, since there is a variant of CPrivateKey.of() accepting two handles. > - if you just add the bug number 8223003 to the @bug line of FinalizeHalf.java, you won't need to specify noreg- label :) > I think, it makes sense to update the bug list because this test does verify the fix. > > With kind regards, > Ivan > > > On 4/26/19 12:22 AM, Weijun Wang wrote: >> Please take a look at >> >> https://cr.openjdk.java.net/~weijun/8223003/webrev.00/ >> >> Two errors are fixed: >> >> 1. CKey::cleanup is not implemented. >> >> 2. A re-fix of JDK-8163896 which was re-introduced by JDK-8213009. >> >> No new test, the existing java/security/KeyPairGenerator/FinalizeHalf.java is able to confirm #2. Unfortunately it didn't fail because of #1. >> >> Anyone knows what kind of noreg-* I can use? I can only think of noreg-other with a comment. >> >> Thanks, >> Max >> >> > > -- > With kind regards, > Ivan Gerasimov > From christoph.langer at sap.com Mon Apr 29 07:31:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 07:31:08 +0000 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate Message-ID: Hi, the change to add GlobalSign's R6 Root certificate has only been pushed to jdk12 updates (12.0.1) so far. According to [0], it was an oversight to not have it added to jdk/jdk. I also want to bring it to 11u. Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java fails to resolve because of changed license header and different bug ids in the @bug tag. So, please review the resolved change. It's the same for both repos. Webrev jdk/jdk: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ Webrev jdk11u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 Please review. @Rajan Halade: please let me know whether I shall push it to jdk/jdk or feel free to do it yourself. Thanks & Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1983-01-06 at gmx.net Mon Apr 29 12:35:28 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Mon, 29 Apr 2019 14:35:28 +0200 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> <20190320161023.GD9177@twosigma.com> Message-ID: Am 2019-04-16 um 09:56 schrieb Weijun Wang: > There is been some time but I've uploaded a new webrev at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.06 > > Major changes: > > 1. No more get expiration time from TGT, accept the one from AcquireCredentialsHandle, which makes GSS_C_INDEFINITE. > > 2. KRB5_TRACE can be set to any file name. /dev/stderr and stderr are recognized. Hi Max, here is my static review of the code. Some spots are still fishy to me and not resolved by my previous comments: gssapi.h: * Still has indentation issues sspi.cpp: * KRB5_TRACE moved to gss_indicate_mechs which is no where called in this file. ** How is this supposed to work then? ** FILE *trace seems to be global, can this lead to race conditions leaving open file descriptors? * 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 ** new_context minor_status is never written, remove it? * get_full_name()!!!: ** 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 ** I don't like the idea using Heimdal-internal identifiers. Shouldn't we define JGSS specific ones? At least create a define for. ** your concat fails if USERDNSDOMAIN is empty, you end up ith service/instance@ ** Why do you check for '\\' what can be escaped here? Requires a better comment ** Why do you do "!input[i]"? I know that we don't have host to realm mappings like in MIT Kerberos * gss_import_name(): ** BOOLEAN isNegotiate isn't really readable code ** " value[len] = 0;" rather '\0'? This idiom repeats over and over ** "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_init_sec_context(): ** Line 909, wrong case for package name I will try to setup a compile env after the next webrev and see how far I get. I have enough cross-realm stuff around here. Michael From sean.mullan at oracle.com Mon Apr 29 14:34:52 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Apr 2019 10:34:52 -0400 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> On 4/27/19 2:10 AM, Langer, Christoph wrote: >> On 4/26/19 6:04 PM, Langer, Christoph wrote: >>> Hi, >>> >>> In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root >>> certificate [0]. >>> >>> This change has gone into 12.0.1 and also 12.0.2 but it's not part of >>> JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, >>> 11.0.4-oracle). Could you please shed some light into this unusual >>> proceeding? Usually such changes would happen in jdk/jdk first, and then >>> be backported, I guess. >>> >>> Is there any reason why the certificate was only added to the jdk12 >>> updates train? >> It should be in 11.0.3-oracle. The backport issue is Confidential so >> maybe that is why you thought it wasn't. > Yep, that explains it. Any particular reason that the 11.0.3-oracle backport is confidential? Could you make it public? Just asking... Fixed. >> JDK 13 seems like an oversight. Rajan, any idea what happened? Can you >> push this to JDK 13? > Thanks in advance. Looking forward to see this in JDK 13. Sure, still looking into this. --Sean From christoph.langer at sap.com Mon Apr 29 14:55:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Apr 2019 14:55:35 +0000 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> References: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> Message-ID: > >> It should be in 11.0.3-oracle. The backport issue is Confidential so > >> maybe that is why you thought it wasn't. > > Yep, that explains it. Any particular reason that the 11.0.3-oracle backport is > confidential? Could you make it public? Just asking... > > Fixed. Thanks! > >> JDK 13 seems like an oversight. Rajan, any idea what happened? Can you > >> push this to JDK 13? > > Thanks in advance. Looking forward to see this in JDK 13. > > Sure, still looking into this. Ok, I guess you have seen the review mail that I've sent out this morning [0]. If this is sufficient, you can just review and I'll push it. But maybe there's other constraints on your end that I can't know of. Just let me know. In any case, it would be good if you can review my proposal for jdk11u. Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019769.html From sean.mullan at oracle.com Mon Apr 29 17:35:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Apr 2019 13:35:11 -0400 Subject: RFR: 8036608: Key.getAlgorithm link to standard algorithm names needs to be updated In-Reply-To: References: Message-ID: <0c065cb2-74f4-bfa7-c75e-4fa6c74d93b2@oracle.com> Ping ... does anyone have time to review this simple docs-only change? Thanks, Sean On 4/23/19 4:41 PM, Sean Mullan wrote: > Please review this javadoc only change to be more specific about the > standard algorithm names that Key.getAlgorithm may return. The fix lists > the specific sections of the Standard Algorithm Names specification that > are relevant. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8036608/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8036608 > > Thanks, > Sean From xuelei.fan at oracle.com Mon Apr 29 17:40:18 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 29 Apr 2019 10:40:18 -0700 (PDT) Subject: RFR: 8036608: Key.getAlgorithm link to standard algorithm names needs to be updated Message-ID: <16a4383a-24a6-4c40-92f9-c27d1b27f93c@default> Looks good to me. Xuelei ----- Original Message ----- From: sean.mullan at oracle.com To: security-dev at openjdk.java.net Sent: Monday, April 29, 2019 10:34:58 AM GMT -08:00 US/Canada Pacific Subject: Re: RFR: 8036608: Key.getAlgorithm link to standard algorithm names needs to be updated Ping ... does anyone have time to review this simple docs-only change? Thanks, Sean On 4/23/19 4:41 PM, Sean Mullan wrote: > Please review this javadoc only change to be more specific about the > standard algorithm names that Key.getAlgorithm may return. The fix lists > the specific sections of the Standard Algorithm Names specification that > are relevant. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8036608/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8036608 > > Thanks, > Sean From Nico.Williams at twosigma.com Mon Apr 29 19:52:14 2019 From: Nico.Williams at twosigma.com (Nico Williams) Date: Mon, 29 Apr 2019 19:52:14 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com> <20181212004054.GG22527@twosigma.com> <20190117190436.GD27060@twosigma.com> <20190215214502.GB4046@twosigma.com> <20190320161023.GD9177@twosigma.com> Message-ID: <20190429195214.GA6914@twosigma.com> On Mon, Apr 29, 2019 at 02:35:28PM +0200, Michael Osipov wrote: > Am 2019-04-16 um 09:56 schrieb Weijun Wang: > > There is been some time but I've uploaded a new webrev at > > > > https://cr.openjdk.java.net/~weijun/6722928/webrev.06 > > > > Major changes: > > > > 1. No more get expiration time from TGT, accept the one from AcquireCredentialsHandle, which makes GSS_C_INDEFINITE. > > > > 2. KRB5_TRACE can be set to any file name. /dev/stderr and stderr are recognized. KRB5_TRACE is also used by MIT Kerberos. I don't know if the KfW (Kerberos for Windows) builds of MIT Kerberos use this, but just in case I'd call it something else. > sspi.cpp: > * KRB5_TRACE moved to gss_indicate_mechs which is no where called in > this file. > ** How is this supposed to work then? See src/java.security.jgss/share/native/libj2gss/{NativeFunc.c, GSSLibStub.c}, and src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSLibStub.java where gss_indicate_mechs() is known as indicateMechs(). > ** FILE *trace seems to be global, can this lead to race conditions > leaving open file descriptors? Yes. There should be a lock or else this should be installed with an atomic CAS and never disabled. (I'd prefer for tracing to be possible to enable and disable at run-time, but here I think it's acceptable to have it not be possible to disable at run-time.) > * get_full_name()!!!: > ** 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 It's for "name canonicalization". > ** I don't like the idea using Heimdal-internal identifiers. Shouldn't > we define JGSS specific ones? At least create a define for. Well, that's commented out, and anyways, it's a "well-known" realm name, which the RFCs permit. Using a well-known realm name from Heimdal is safe, but Weijun could just allocate one from an OpenJDK namespace. > ** your concat fails if USERDNSDOMAIN is empty, you end up ith > service/instance@ That's solution #2, and intended. > ** Why do you check for '\\' what can be escaped here? Requires a better > comment Basically, Kerberos principal names consist of N "components" and a realm name. In RFC4120 (successor to RFC1510) there is no text representation given for principal names -- it's just ASN.1 types. RFC1964 (updated by RFC4121) defines the GSS-API mechanism based on Kerberos, and defines a textual representation of principal names using '/' to join/separate components, and '@ to join/separate the realm. Because '/' and '@' (and '\\') are not forbidden in principal name components and realm names, RFC1964 requires backslash-escaping of them. Thus, the principal name joe\@foo.example at FOO.EXAMPLE has 1 component ("joe at foo.example") and a realm name "FOO.EXAMPLE". joe\@@FOO.EXAMPLE is also a valid principal name. > ** Why do you do "!input[i]"? > I know that we don't have host to realm mappings like in MIT Kerberos These are C strings, thus NUL-terminated. In principle Kerberos principal names allow embedded NULs(!). I'm not sure it's wise to support that here. Passing in "foo\\" might cause this code to read past the end of the string! > * gss_import_name(): > ** BOOLEAN isNegotiate isn't really readable code It's BOOLEAN isSPNEGO in webrev.06. I think that's readable. > ** " value[len] = 0;" rather '\0'? This idiom repeats over and over I'm OK with that. I dunno what the OpenJDK style guides have to say about this. > ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function Good catch! Does the compiler coerce this automatically? > ** "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() +1 Nico -- From weijun.wang at oracle.com Tue Apr 30 00:35:30 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Apr 2019 08:35:30 +0800 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> <20190320161023.GD9177@twosigma.com> Message-ID: I'll reply to your other comment in a separate mail. > On Apr 29, 2019, at 8:35 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > I will try to setup a compile env after the next webrev and see how far > I get. I have enough cross-realm stuff around here. Please you can compile the current webrev. There is no need to compile OpenJDK if you find that part complicated. There is a command line at the beginning of sspi.cpp, you can just compile the single file and it also work with JDK 11 with these extra system properties -Dsun.security.jgss.lib=/path/to/the/dll -Dsun.security.jgss.native=true I haven't really used the DLL with a C program. Thanks, Max From henry.jen at oracle.com Tue Apr 30 02:09:36 2019 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 29 Apr 2019 19:09:36 -0700 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> References: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> Message-ID: <766FC86A-0106-4F68-AEAC-C65DCADECFBC@oracle.com> This seems should be pushed into jdk.jdk directly as it?s not a vulnerability issue. There is no doubt now this should be pushed directly as it?s already released. Because it was not pushed into jdk-cpu before(which IMHO is correct), naturally it won?t be in jdk.jdk without an explicit push. Cheers, Henry > On Apr 29, 2019, at 7:34 AM, Sean Mullan wrote: > > On 4/27/19 2:10 AM, Langer, Christoph wrote: >>> On 4/26/19 6:04 PM, Langer, Christoph wrote: >>>> Hi, >>>> >>>> In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root >>>> certificate [0]. >>>> >>>> This change has gone into 12.0.1 and also 12.0.2 but it's not part of >>>> JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, >>>> 11.0.4-oracle). Could you please shed some light into this unusual >>>> proceeding? Usually such changes would happen in jdk/jdk first, and then >>>> be backported, I guess. >>>> >>>> Is there any reason why the certificate was only added to the jdk12 >>>> updates train? >>> It should be in 11.0.3-oracle. The backport issue is Confidential so >>> maybe that is why you thought it wasn't. >> Yep, that explains it. Any particular reason that the 11.0.3-oracle backport is confidential? Could you make it public? Just asking... > > Fixed. > >>> JDK 13 seems like an oversight. Rajan, any idea what happened? Can you >>> push this to JDK 13? >> Thanks in advance. Looking forward to see this in JDK 13. > > Sure, still looking into this. > > --Sean > From philipp.kunz at paratix.ch Tue Apr 30 05:56:44 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Tue, 30 Apr 2019 07:56:44 +0200 Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> Message-ID: <1556603804.2432.11.camel@paratix.ch> Hi Max, I agree that the parentheses are superfluous, however, I would slightly prefer going small steps. Would the parentheses have to come from a resource bundle as well like SPACE or COMMA when removed from storeHash values?Now that with the patch, storeHash is not any longer useful to check whether it contains ckaliases in inKeyStoreForOneSigner (but currently still useful to save another call to store.getCertificateAlias in printCert lateron), would it be a worth a consideration to rearrange the code populating storeHash closer to printCert in some way or even just completely remove storeHash and replace it with store.getCertificateAlias in printCert or anything similar? Regards,Philipp On Sat, 2019-03-30 at 23:01 +0800, Weijun Wang wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Apr 30 06:45:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Apr 2019 14:45:18 +0800 Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case In-Reply-To: <1556603804.2432.11.camel@paratix.ch> References: <1550666474.2433.13.camel@paratix.ch> <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com> <1556603804.2432.11.camel@paratix.ch> Message-ID: > On Apr 30, 2019, at 1:56 PM, Philipp Kunz wrote: > > Hi Max, > > I agree that the parentheses are superfluous, however, I would slightly prefer going small steps. > > Would the parentheses have to come from a resource bundle as well like SPACE or COMMA when removed from storeHash values? No. It's hardcoded and not localized in printCert. > Now that with the patch, storeHash is not any longer useful to check whether it contains ckaliases in inKeyStoreForOneSigner (but currently still useful to save another call to store.getCertificateAlias in printCert lateron), would it be a worth a consideration to rearrange the code populating storeHash closer to printCert in some way or even just completely remove storeHash and replace it with store.getCertificateAlias in printCert or anything similar? Probably not. I believe storeHash was introduced to avoid too many calls to store.getCertificateAlias when there are hundreds of classes in a signed jar. --Max > > Regards, > Philipp > > > > > > On Sat, 2019-03-30 at 23:01 +0800, Weijun Wang wrote: >> 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 < >>> philipp.kunz at paratix.ch >>> > 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 sean.mullan at oracle.com Tue Apr 30 16:22:33 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Apr 2019 12:22:33 -0400 Subject: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate In-Reply-To: <766FC86A-0106-4F68-AEAC-C65DCADECFBC@oracle.com> References: <46682417-e772-bc33-e431-97a1ac64054e@oracle.com> <766FC86A-0106-4F68-AEAC-C65DCADECFBC@oracle.com> Message-ID: Thanks for clarifying, Henry. Rajan, can you push this to JDK 13 so everything is back in sync? Thanks, Sean On 4/29/19 10:09 PM, Henry Jen wrote: > This seems should be pushed into jdk.jdk directly as it?s not a vulnerability issue. There is no doubt now this should be pushed directly as it?s already released. > > Because it was not pushed into jdk-cpu before(which IMHO is correct), naturally it won?t be in jdk.jdk without an explicit push. > > Cheers, > Henry > > >> On Apr 29, 2019, at 7:34 AM, Sean Mullan wrote: >> >> On 4/27/19 2:10 AM, Langer, Christoph wrote: >>>> On 4/26/19 6:04 PM, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root >>>>> certificate [0]. >>>>> >>>>> This change has gone into 12.0.1 and also 12.0.2 but it's not part of >>>>> JDK13 (jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, >>>>> 11.0.4-oracle). Could you please shed some light into this unusual >>>>> proceeding? Usually such changes would happen in jdk/jdk first, and then >>>>> be backported, I guess. >>>>> >>>>> Is there any reason why the certificate was only added to the jdk12 >>>>> updates train? >>>> It should be in 11.0.3-oracle. The backport issue is Confidential so >>>> maybe that is why you thought it wasn't. >>> Yep, that explains it. Any particular reason that the 11.0.3-oracle backport is confidential? Could you make it public? Just asking... >> >> Fixed. >> >>>> JDK 13 seems like an oversight. Rajan, any idea what happened? Can you >>>> push this to JDK 13? >>> Thanks in advance. Looking forward to see this in JDK 13. >> >> Sure, still looking into this. >> >> --Sean >> > From rajan.halade at oracle.com Tue Apr 30 18:08:25 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 30 Apr 2019 11:08:25 -0700 Subject: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root certificate In-Reply-To: References: Message-ID: <1ed9610c-8a81-9c5d-f261-2056f617003b@oracle.com> Thanks Christoph for this. I have pushed fix to jdk/jdk repository. - Rajan On 4/29/19 12:31 AM, Langer, Christoph wrote: > > Hi, > > the change to add GlobalSign's R6 Root certificate has only been > pushed to jdk12 updates (12.0.1) so far. According to [0], it was an > oversight to not have it added to jdk/jdk. I also want to bring it to 11u. > > Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not > apply cleanly. test/jdk/sun/security/lib/cacerts/VerifyCACerts.java > fails to resolve because of changed license header and different bug > ids in the @bug tag. So, please review the resolved change. It's the > same for both repos. > > Webrev jdk/jdk: > http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk/ > > > Webrev jdk11u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8216577.jdk11u-dev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216577 > > > Please review. > > @Rajan Halade : please let me know > whether I shall push it to jdk/jdk or feel free to do it yourself. > > Thanks & Best regards > > Christoph > > [0] > https://mail.openjdk.java.net/pipermail/security-dev/2019-April/019766.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue Apr 30 18:39:03 2019 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 30 Apr 2019 11:39:03 -0700 Subject: RFR: 8222137: Remove T-Systems root CA certificate Message-ID: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> Please review this fix for removal of T-Systems Deutsche Telekom Root CA 2 certificate. Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Apr 30 19:19:23 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Apr 2019 15:19:23 -0400 Subject: RFR: 8222137: Remove T-Systems root CA certificate In-Reply-To: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> References: <16611981-a868-b5f1-c42b-7b3bec234b59@oracle.com> Message-ID: <0dd165d4-c783-c4c0-4a18-3fca2ee6b731@oracle.com> Looks good. --Sean On 4/30/19 2:39 PM, Rajan Halade wrote: > Please review this fix for removal of T-Systems Deutsche Telekom Root CA > 2 certificate. > > Webrev: http://cr.openjdk.java.net/~rhalade/8222137/webrev.00/ > > Release note is at - https://bugs.openjdk.java.net/browse/JDK-8223161 > > Thanks, > Rajan From valerie.peng at oracle.com Tue Apr 30 20:25:35 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 30 Apr 2019 13:25:35 -0700 Subject: RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: <43c5e7ea-e459-9399-4d1b-f3d62dfc255d@oracle.com> Looks fine to me. Just curious, how do we see the changes on the artifactory side? Valerie On 4/23/2019 7:39 PM, sha.jiang at oracle.com wrote: > Hi, > NSS 3.41 has been approved, so just build this version for windows > (with VS2017) and macosx. > > Webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8204203 > > Best regards, > John Jiang > From mbalao at redhat.com Tue Apr 30 20:28:21 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 30 Apr 2019 17:28:21 -0300 Subject: RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> References: <37303f3d-8c92-3d02-d33f-3bf443057a02@redhat.com> <8C05F6A7-577C-4EFF-81DE-D15D32153446@oracle.com> <24CD886B-3B7F-446B-9ECA-6102FCCBB71F@oracle.com> Message-ID: <241a2c76-3120-4f60-d74f-77860921ff6b@redhat.com> Hi Max, Thanks for your feedback. Here it's Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.01/ Webrev.01 includes: * rep.encKDCRepPart.pAData may be null in KrbKdcRep.java (found by Max) * When requesting a TGS, the sname principal name is of type KRB_NT_SRV_HST instead of Unknown (found by Max) * When a cross-realm TGT is received, it should be used as the TGT in the next request (found by Max) * Referrals Cache updated to send the previously received TGT * TGTs are now cached * It may not be necessary to do cross-realm authentication when Referrals Cache is used * Moved logic down to serviceCredsSingle method in CredentialsUtil.java because this is the point where we really know that the request will be made (requests at a higher layer may be filtered due to the referrals cache) * Cross-referrals test updated to work with the cross-realm TGT received * Copyright date update Testing: jdk/sun/security/krb5 pass - no regressions Look forward to your comments. I'll start the CSR process meanwhile [1] (work in progress). Kind regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8223172 From weijun.wang at oracle.com Tue Apr 30 23:18:13 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 May 2019 07:18:13 +0800 Subject: RFR 8223063: Support CNG RSA keys Message-ID: Please take a look at https://cr.openjdk.java.net/~weijun/8223063/webrev.00/ Unfortunately, although the new test I added succeeds on my own machine, the "certutil -importPFX" command inside always fail on Mach5 with Command line: [certutil -f -v -p changeit -user -importpfx MY ks NoRoot] A -- A-7626e24d-46df-4ba0-8880-9866bb1-01966 A -- A-7626e24d-46df-4ba0-8880-9866bb178ab6 CertUtil: -importPFX command FAILED: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED) CertUtil: The requested operation is not supported. Maybe there is a permission issue. I'll study it for more, but If anyone of you can fix it I'll be very happy. Thanks, Max