From sgehwolf at redhat.com Mon Sep 2 12:14:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 14:14:12 +0200 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: Hi Andrew, Thanks for the review! On Wed, 2019-08-28 at 18:15 +0100, Andrew John Hughes wrote: > On 26/08/2019 14:23, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this MUSCLE header files update in > > OpenJDK 8u? I'd like to backport this bug as it's also going to be in > > Oracle JDK 8u231 (equiv to OpenJDK 8u232) as well. The OpenJDK 11 patch > > applies almost cleanly post path-unshuffelling. Changes which didn't > > apply were a copyright header update in pcsc.c. I've omitted these. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218780 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/01/webrev/ > > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0bcc59a50c88 > > > > There is going to be a follow-up fix adding back COPYING via > > JDK-8226607 which I propose for backport to OpenJDK 8u as well. > > > > Testing: smartcardio sanity and build on Linux x86_64 (Fedora 30 and RHEL 6) > > > > Thanks to Aleksey Shipilev who helped test this patch. > > > > Thoughts? > > > > Thanks, > > Severin > > > > Most of this looks good. I was a little confused at first because the > patch in your webrev looks quite different to the 11u changeset. > However, once applied locally to the 8u repo, the diff between the two > was as suggested and the PCSC library files (those in MUSCLE) were > identical. I don't know what webrev did in creating that patch. > > The bit I don't understand is why you've decided to drop the copyright > header change on the floor. Just because the original in 8u has 2014, > while the original in 11u had 2015, does not make the change inapplicable. OK. I see. I wasn't sure how to deal with copyright year updates. I've added the copyright update back. The patch is now identical to JDK 11u (modulo differing copyright year base: 2014 - jdk 8 - vs. 2018 - jdk 11): http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/02/webrev > A better alternative may actually be to backport JDK-8207233 [0] first > which is a nice little cleanup patch. I suspect this patch would then > apply cleanly as these PCSC files are rarely touched. > > [0] https://bugs.openjdk.java.net/browse/JDK-8207233 Hmm, this seems overkill just to get the copyright hunk to apply. I'd prefer to keep this dependency out of scope for this patch. While a nice clean-up it's not without risk backporting that too. Thoughts? Thanks, Severin From daniel.fuchs at oracle.com Mon Sep 2 13:00:38 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 2 Sep 2019 14:00:38 +0100 Subject: [testsabilization] RFR: 8230435: Replace wildcard address with loopback or local host in tests - part 22 Message-ID: Hi, (cc-ing security dev for the changes in test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java which is updated to allow for binding on a specific IP Address) Please find below a patch for: 8230435: Replace wildcard address with loopback or local host in tests - part 22 https://bugs.openjdk.java.net/browse/JDK-8230435 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8230435/webrev.00/ This is actually a mixed batch - with some tests only updated to add more diagnostic. Some of the changes have been included because some tests have been observed failing while testing other test changes: 1. Adding more diagnostic / fixing safe publishing of values: test/jdk/java/net/Authenticator/B4678055.java test/jdk/java/net/DatagramSocket/PortUnreachable.java test/jdk/java/net/URLConnection/RedirectLimit.java test/jdk/java/net/URLConnection/Responses.java test/jdk/sun/net/InetAddress/nameservice/simple/DefaultCaching.java test/jdk/sun/net/www/http/HttpClient/RetryPost.java 2. Adding ability to bind to a specific IP Address (e.g. the loopback) test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyTunnelServer.java test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java 3. Removing dependency on the wildcard address: test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java test/jdk/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java 4. Forcing usage of NO_PROXY to prevent usage of system proxies on mac: test/jdk/sun/net/www/AuthHeaderTest.java best regards, -- daniel From gnu.andrew at redhat.com Mon Sep 2 14:20:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 15:20:48 +0100 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: On 02/09/2019 13:14, Severin Gehwolf wrote: snip... >>> >> >> Most of this looks good. I was a little confused at first because the >> patch in your webrev looks quite different to the 11u changeset. >> However, once applied locally to the 8u repo, the diff between the two >> was as suggested and the PCSC library files (those in MUSCLE) were >> identical. I don't know what webrev did in creating that patch. >> >> The bit I don't understand is why you've decided to drop the copyright >> header change on the floor. Just because the original in 8u has 2014, >> while the original in 11u had 2015, does not make the change inapplicable. > > OK. I see. I wasn't sure how to deal with copyright year updates. I've > added the copyright update back. The patch is now identical to JDK 11u > (modulo differing copyright year base: 2014 - jdk 8 - vs. 2018 - jdk > 11): > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/02/webrev > This looks good now (though still issues with the original diff vs local application of it) Please flag the bug for approval. > >> A better alternative may actually be to backport JDK-8207233 [0] first >> which is a nice little cleanup patch. I suspect this patch would then >> apply cleanly as these PCSC files are rarely touched. >> >> [0] https://bugs.openjdk.java.net/browse/JDK-8207233 > > Hmm, this seems overkill just to get the copyright hunk to apply. I'd > prefer to keep this dependency out of scope for this patch. While a > nice clean-up it's not without risk backporting that too. Thoughts? > Well, I think it's a useful cleanup too, but I'm not going to force it as a dependency of this. I just thought it might make the review for this fix redundant as it would then be a clean backport. I might look into it myself at a later date. > Thanks, > Severin > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gnu.andrew at redhat.com Mon Sep 2 14:38:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 2 Sep 2019 15:38:47 +0100 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: References: Message-ID: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> On 26/08/2019 14:24, Severin Gehwolf wrote: > Hi, > > Could I get a review of this follow-up fix for an 8u backport (JDK- > 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc > library header files removed by the JDK-8218780 backport. The patch > differs from the version in JDK 11 since there is no pcsclite.md file > in OpenJDK 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 > > I intend to push this fix together with JDK-8218780 once it passed > review and got approved. > > Thoughts? > > Thanks, > Severin > > > The *.md files in OpenJDK 9+ are the modular equivalent of the THIRD_PARTY_README file found in each OpenJDK 8u repository. See my review of JDK-8217676 [0] for Zhengyu for more details. For reference, the conversion took place in JDK-8169925. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html [1] https://bugs.openjdk.java.net/browse/JDK-8169925 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sgehwolf at redhat.com Mon Sep 2 15:05:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Sep 2019 17:05:54 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> Message-ID: On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: > > On 26/08/2019 14:24, Severin Gehwolf wrote: > > Hi, > > > > Could I get a review of this follow-up fix for an 8u backport (JDK- > > 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc > > library header files removed by the JDK-8218780 backport. The patch > > differs from the version in JDK 11 since there is no pcsclite.md file > > in OpenJDK 8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ > > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 > > > > I intend to push this fix together with JDK-8218780 once it passed > > review and got approved. > > > > Thoughts? > > > > Thanks, > > Severin > > > > > > > > The *.md files in OpenJDK 9+ are the modular equivalent of the > THIRD_PARTY_README file found in each OpenJDK 8u repository. See my > review of JDK-8217676 [0] for Zhengyu for more details. > > For reference, the conversion took place in JDK-8169925. Thanks for this. Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ I intend to push the same updat to THIRD_PARTY_README files on all other repos. Example here is jdk repo. Do you want to see webrevs of this THIRD_PARTY_README update for all 7 other repos? Thanks, Severin > [0] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html > [1] https://bugs.openjdk.java.net/browse/JDK-8169925 From michael.x.mcmahon at oracle.com Tue Sep 3 13:53:54 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 03 Sep 2019 14:53:54 +0100 Subject: [testsabilization] RFR: 8230435: Replace wildcard address with loopback or local host in tests - part 22 In-Reply-To: References: Message-ID: <5D6E7072.6070107@oracle.com> Looks fine to me Daniel. - Michael. On 02/09/2019, 14:00, Daniel Fuchs wrote: > Hi, > > (cc-ing security dev for the changes in > test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > which is updated to allow for binding on a specific > IP Address) > > Please find below a patch for: > 8230435: Replace wildcard address with loopback or local host > in tests - part 22 > https://bugs.openjdk.java.net/browse/JDK-8230435 > > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8230435/webrev.00/ > > This is actually a mixed batch - with some tests only updated > to add more diagnostic. Some of the changes have been included > because some tests have been observed failing while testing other > test changes: > > 1. Adding more diagnostic / fixing safe publishing of values: > test/jdk/java/net/Authenticator/B4678055.java > test/jdk/java/net/DatagramSocket/PortUnreachable.java > test/jdk/java/net/URLConnection/RedirectLimit.java > test/jdk/java/net/URLConnection/Responses.java > test/jdk/sun/net/InetAddress/nameservice/simple/DefaultCaching.java > test/jdk/sun/net/www/http/HttpClient/RetryPost.java > > 2. Adding ability to bind to a specific IP Address (e.g. the loopback) > test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java > test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyTunnelServer.java > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java > > 3. Removing dependency on the wildcard address: > test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java > > > 4. Forcing usage of NO_PROXY to prevent usage of system proxies on mac: > test/jdk/sun/net/www/AuthHeaderTest.java > > best regards, > > -- daniel From sha.jiang at oracle.com Wed Sep 4 03:23:23 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 4 Sep 2019 11:23:23 +0800 Subject: RFR[14] JDK-8226221: Update PKCS11 tests to use NSS 3.46 libs Message-ID: Hi, The below simple patch just take PKCS11 tests to use the latest NSS, exactly version 3.46, libs. diff -r bf3fb5465543 test/jdk/sun/security/pkcs11/PKCS11Test.java --- a/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Tue Sep 03 17:45:02 2019 +0300 +++ b/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Wed Sep 04 11:19:43 2019 +0800 @@ -906,21 +906,21 @@ ???? @Artifact( ???????????? organization = "jpg.tests.jdk.nsslib", ???????????? name = "nsslib-windows_x64", -??????????? revision = "3.41-VS2017", +??????????? revision = "3.46-VS2017", ???????????? extension = "zip") ???? private static class WINDOWS_X64 { } ???? @Artifact( ???????????? organization = "jpg.tests.jdk.nsslib", ???????????? name = "nsslib-windows_x86", -??????????? revision = "3.41-VS2017", +??????????? revision = "3.46-VS2017", ???????????? extension = "zip") ???? private static class WINDOWS_X86 { } ???? @Artifact( ???????????? organization = "jpg.tests.jdk.nsslib", ???????????? name = "nsslib-macosx_x64", -??????????? revision = "3.41", +??????????? revision = "3.46", ???????????? extension = "zip") ???? private static class MACOSX_X64 { } ?} Best regards, John Jiang From xuelei.fan at oracle.com Wed Sep 4 04:09:31 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Sep 2019 21:09:31 -0700 Subject: RFR[14] JDK-8226221: Update PKCS11 tests to use NSS 3.46 libs In-Reply-To: References: Message-ID: <7bfd0f83-719b-434e-1d92-cb73996e5e74@oracle.com> Looks fine to me. Xuelei On 9/3/2019 8:23 PM, sha.jiang at oracle.com wrote: > Hi, > The below simple patch just take PKCS11 tests to use the latest NSS, > exactly version 3.46, libs. > > diff -r bf3fb5465543 test/jdk/sun/security/pkcs11/PKCS11Test.java > --- a/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Tue Sep 03 > 17:45:02 2019 +0300 > +++ b/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Wed Sep 04 > 11:19:43 2019 +0800 > @@ -906,21 +906,21 @@ > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-windows_x64", > -??????????? revision = "3.41-VS2017", > +??????????? revision = "3.46-VS2017", > ???????????? extension = "zip") > ???? private static class WINDOWS_X64 { } > > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-windows_x86", > -??????????? revision = "3.41-VS2017", > +??????????? revision = "3.46-VS2017", > ???????????? extension = "zip") > ???? private static class WINDOWS_X86 { } > > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-macosx_x64", > -??????????? revision = "3.41", > +??????????? revision = "3.46", > ???????????? extension = "zip") > ???? private static class MACOSX_X64 { } > ?} > > Best regards, > John Jiang > From jamil.j.nimeh at oracle.com Wed Sep 4 04:21:40 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 3 Sep 2019 21:21:40 -0700 Subject: RFR[14] JDK-8226221: Update PKCS11 tests to use NSS 3.46 libs In-Reply-To: References: Message-ID: <1a22a9eb-6807-18fa-46ea-723b48518823@oracle.com> Looks good. --Jamil On 9/3/19 8:23 PM, sha.jiang at oracle.com wrote: > Hi, > The below simple patch just take PKCS11 tests to use the latest NSS, > exactly version 3.46, libs. > > diff -r bf3fb5465543 test/jdk/sun/security/pkcs11/PKCS11Test.java > --- a/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Tue Sep 03 > 17:45:02 2019 +0300 > +++ b/test/jdk/sun/security/pkcs11/PKCS11Test.java??? Wed Sep 04 > 11:19:43 2019 +0800 > @@ -906,21 +906,21 @@ > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-windows_x64", > -??????????? revision = "3.41-VS2017", > +??????????? revision = "3.46-VS2017", > ???????????? extension = "zip") > ???? private static class WINDOWS_X64 { } > > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-windows_x86", > -??????????? revision = "3.41-VS2017", > +??????????? revision = "3.46-VS2017", > ???????????? extension = "zip") > ???? private static class WINDOWS_X86 { } > > ???? @Artifact( > ???????????? organization = "jpg.tests.jdk.nsslib", > ???????????? name = "nsslib-macosx_x64", > -??????????? revision = "3.41", > +??????????? revision = "3.46", > ???????????? extension = "zip") > ???? private static class MACOSX_X64 { } > ?} > > Best regards, > John Jiang > From christoph.langer at sap.com Wed Sep 4 06:24:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 06:24:06 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Message-ID: Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn't exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Sep 4 14:25:00 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 4 Sep 2019 15:25:00 +0100 Subject: [testsabilization] RFR: 8230435: Replace wildcard address with loopback or local host in tests - part 22 In-Reply-To: <5D6E7072.6070107@oracle.com> References: <5D6E7072.6070107@oracle.com> Message-ID: <358933ce-d835-c0ee-1477-3017c491bee0@oracle.com> Thanks Michael! If I don't receive more comments I will be pushing this shortly... best regards, -- daniel On 03/09/2019 14:53, Michael McMahon wrote: > Looks fine to me Daniel. > > - Michael. > > On 02/09/2019, 14:00, Daniel Fuchs wrote: >> Hi, >> >> (cc-ing security dev for the changes in >> ?test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java >> ?which is updated to allow for binding on a specific >> ?IP Address) >> >> Please find below a patch for: >> 8230435: Replace wildcard address with loopback or local host >> ???????? in tests - part 22 >> https://bugs.openjdk.java.net/browse/JDK-8230435 >> >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8230435/webrev.00/ >> From matthias.baesken at sap.com Wed Sep 4 14:54:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 4 Sep 2019 14:54:16 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Sep 4 14:59:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 14:59:59 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hi Matthias, good point. What do e.g. Redhat folks say about VS2017 requirement? (@Aleksey) Or will the test also work with these artifacts if using a VS < 2017 to build the JDK? (Maybe somebody on security-dev with some experience with these tests can shed some light on this?) Thanks Christoph From: Baesken, Matthias Sent: Mittwoch, 4. September 2019 16:54 To: Langer, Christoph ; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Thu Sep 5 03:11:13 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 5 Sep 2019 11:11:13 +0800 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: <9d52a94b-e3fd-8fad-8d8d-6de24a6f9a5c@oracle.com> References: <9d52a94b-e3fd-8fad-8d8d-6de24a6f9a5c@oracle.com> Message-ID: Ping... In the future, we would use these utilities to refactor some existing tests, which depend on binary trust/key stores. I just run all tests in java/security, javax/security, javax/net/ssl and sun/security with this patch. The results are fine. Best regards, John Jiang On 2019/8/19 15:17, sha.jiang at oracle.com wrote: > Could this patch be reviewed? > > Best regards, > John > > On 2019/8/4 07:32, sha.jiang at oracle.com wrote: >> Hi Sean, >> I moved test/jdk/java/security/testlibrary/CertUtils.java? to >> test/lib/jdk/test/lib/security/CertUtils.java, and added the new >> methods to this class. >> The affected existing tests are also modified. >> >> http://cr.openjdk.java.net/~jjiang/8228967/webrev.01/ >> >> Best regards, >> John Jiang >> >> On 2019/8/2 19:26, Sean Mullan wrote: >>> Not a full review but there is already a utility class for creating >>> certificates, etc in test/jdk/java/security/testlibrary/CertUtils.java >>> Could you combine/merge that with your new CertUtils class? >>> >>> --Sean >>> >>> On 8/2/19 4:29 AM, sha.jiang at oracle.com wrote: >>>> Hi, >>>> This enhancement provides a set of utilities for creating >>>> certificate, trust/key store and SSL context. >>>> It provides the default trust and key stores with RSA, ECDSA, >>>> RSASSA-PSS and DSA certificates, and also the default TLS and DTLS >>>> contexts with the default trust and key stores. >>>> Three tests are modified for demonstrating the usages. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >> > From xuelei.fan at oracle.com Thu Sep 5 04:06:16 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 4 Sep 2019 21:06:16 -0700 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: <9d52a94b-e3fd-8fad-8d8d-6de24a6f9a5c@oracle.com> Message-ID: Looks good to me. Xuelei On 9/4/2019 8:11 PM, sha.jiang at oracle.com wrote: > Ping... > > In the future, we would use these utilities to refactor some existing > tests, which depend on binary trust/key stores. > > I just run all tests in java/security, javax/security, javax/net/ssl and > sun/security with this patch. > The results are fine. > > Best regards, > John Jiang > > On 2019/8/19 15:17, sha.jiang at oracle.com wrote: >> Could this patch be reviewed? >> >> Best regards, >> John >> >> On 2019/8/4 07:32, sha.jiang at oracle.com wrote: >>> Hi Sean, >>> I moved test/jdk/java/security/testlibrary/CertUtils.java? to >>> test/lib/jdk/test/lib/security/CertUtils.java, and added the new >>> methods to this class. >>> The affected existing tests are also modified. >>> >>> http://cr.openjdk.java.net/~jjiang/8228967/webrev.01/ >>> >>> Best regards, >>> John Jiang >>> >>> On 2019/8/2 19:26, Sean Mullan wrote: >>>> Not a full review but there is already a utility class for creating >>>> certificates, etc in test/jdk/java/security/testlibrary/CertUtils.java >>>> Could you combine/merge that with your new CertUtils class? >>>> >>>> --Sean >>>> >>>> On 8/2/19 4:29 AM, sha.jiang at oracle.com wrote: >>>>> Hi, >>>>> This enhancement provides a set of utilities for creating >>>>> certificate, trust/key store and SSL context. >>>>> It provides the default trust and key stores with RSA, ECDSA, >>>>> RSASSA-PSS and DSA certificates, and also the default TLS and DTLS >>>>> contexts with the default trust and key stores. >>>>> Three tests are modified for demonstrating the usages. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>> >>> >> From sbordet at webtide.com Thu Sep 5 17:44:30 2019 From: sbordet at webtide.com (Simone Bordet) Date: Thu, 5 Sep 2019 19:44:30 +0200 Subject: JDK 13 SSLSession.getValue() throws NPE Message-ID: Hi, we have a number of TLS tests failing in Jetty when running on JDK 13, while they work on JDK 11 and 12. The simplest way to reproduce this is to open 2 TLS sockets to Jetty, one after the other. On the server, the first socket creates a SSLEngine which has a SSLSession. Jetty calls SSLSession.getValue() to check whether a key (that we may have put on the session during SNI processing) is there. For the first socket this works. The second socket, however, is using resumption. On the server, a new SSLEngine is created, but its SSLSession has field "boundValues" == null so trying to call SSLSession.getValue() throws a NPE. Is this a regression? Thanks! -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From jai.forums2013 at gmail.com Fri Sep 6 04:47:57 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 6 Sep 2019 10:17:57 +0530 Subject: JDK 13 SSLSession.getValue() throws NPE In-Reply-To: References: Message-ID: <852de205-a20e-629e-f462-3badee1583bd@gmail.com> Hi Simone, I remember hitting a similar issue back when I was testing a EA version of JDK 13. There was bug for it here https://bugs.openjdk.java.net/browse/JDK-8226649 and that one says it's fixed in "13" but doesn't have a build number associated with it. Which build of JDK 13 are you on? I think I have a test case for this, which was running into this NPE. Later today, I will probably try it out against latest JDK 13 candidate release build and see if it's reproducible there. -Jaikiran On 05/09/19 11:14 PM, Simone Bordet wrote: > Hi, > > we have a number of TLS tests failing in Jetty when running on JDK 13, > while they work on JDK 11 and 12. > > The simplest way to reproduce this is to open 2 TLS sockets to Jetty, > one after the other. > > On the server, the first socket creates a SSLEngine which has a SSLSession. > Jetty calls SSLSession.getValue() to check whether a key (that we may > have put on the session during SNI processing) is there. For the first > socket this works. > > The second socket, however, is using resumption. On the server, a new > SSLEngine is created, but its SSLSession has field "boundValues" == > null so trying to call SSLSession.getValue() throws a NPE. > > Is this a regression? > > Thanks! > From simone.bordet at gmail.com Fri Sep 6 07:39:50 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 6 Sep 2019 09:39:50 +0200 Subject: JDK 13 SSLSession.getValue() throws NPE In-Reply-To: <852de205-a20e-629e-f462-3badee1583bd@gmail.com> References: <852de205-a20e-629e-f462-3badee1583bd@gmail.com> Message-ID: Hi, On Fri, Sep 6, 2019 at 6:48 AM Jaikiran Pai wrote: > > Hi Simone, > > I remember hitting a similar issue back when I was testing a EA version > of JDK 13. There was bug for it here > https://bugs.openjdk.java.net/browse/JDK-8226649 and that one says it's > fixed in "13" but doesn't have a build number associated with it. Which > build of JDK 13 are you on? I was using 13+29. The issue is fixed in 13+33. Sorry for the noise. -- 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 christoph.langer at sap.com Fri Sep 6 12:54:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 12:54:28 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hi, since there?s apparently no veto on this (nor encouraging statements), I?ll go ahead and push this testfix soon. After all, it?ll just re-enable a few tests where I can?t see problems with. Should somebody run into issues with the tests because of this update, we can always disable them again. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. September 2019 17:00 To: Baesken, Matthias ; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Aleksey Shipilev Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi Matthias, good point. What do e.g. Redhat folks say about VS2017 requirement? (@Aleksey) Or will the test also work with these artifacts if using a VS < 2017 to build the JDK? (Maybe somebody on security-dev with some experience with these tests can shed some light on this?) Thanks Christoph From: Baesken, Matthias > Sent: Mittwoch, 4. September 2019 16:54 To: Langer, Christoph >; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Sep 11 15:13:56 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 11 Sep 2019 15:13:56 +0000 Subject: RFR [XS] : 8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect Message-ID: Hello, please review this small fix . It adds a ReleaseStringUTFChars to an early (special case) return in function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8230861 http://cr.openjdk.java.net/~mbaesken/webrevs/8230861.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Sep 11 15:35:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 16:35:54 +0100 Subject: RFR [XS] : 8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: On 11/09/2019 16:13, Baesken, Matthias wrote: > > Hello, please review this small fix . > > It adds a ReleaseStringUTFChars?? to an early ?(special case)? return > in function Java_sun_security_pkcs11_wrapper_PKCS11_connect? . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8230861 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230861.0/ > ReleaseStringUTFChars is safe to call when there is pending exception so I think this is okay. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Sep 11 15:50:48 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Sep 2019 17:50:48 +0200 Subject: RFR [XS] : 8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: +1 Cheers, Thomas On Wed, Sep 11, 2019 at 5:15 PM Baesken, Matthias wrote: > Hello, please review this small fix . > > It adds a ReleaseStringUTFChars to an early (special case) return in > function Java_sun_security_pkcs11_wrapper_PKCS11_connect . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8230861 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8230861.0/ > > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Sep 12 07:00:12 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 12 Sep 2019 07:00:12 +0000 Subject: RFR [XS] : 8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect In-Reply-To: References: Message-ID: Hi Alan and Thomas, Thanks for the reviews ! From: Thomas St?fe Sent: Mittwoch, 11. September 2019 17:51 To: Baesken, Matthias Cc: security-dev at openjdk.java.net Subject: Re: RFR [XS] : 8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect +1 Cheers, Thomas On Wed, Sep 11, 2019 at 5:15 PM Baesken, Matthias > wrote: Hello, please review this small fix . It adds a ReleaseStringUTFChars to an early (special case) return in function Java_sun_security_pkcs11_wrapper_PKCS11_connect . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8230861 http://cr.openjdk.java.net/~mbaesken/webrevs/8230861.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Sep 12 11:31:48 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Sep 2019 07:31:48 -0400 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit In-Reply-To: References: Message-ID: This is in the security-libs area, not core-libs. Cross-posting to security-dev and bcc-ing core-libs-dev. --Sean On 9/12/19 6:40 AM, Thomas St?fe wrote: > Hi all, > > may I please have reviews for the following trivial build fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ > > Thanks, > > Thomas > From Alan.Bateman at oracle.com Fri Sep 13 07:22:49 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Sep 2019 08:22:49 +0100 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit In-Reply-To: References: Message-ID: <151097c3-c0d3-af88-f169-f186f7b316da@oracle.com> Using size_t looks okay here. -Alan On 12/09/2019 12:31, Sean Mullan wrote: > This is in the security-libs area, not core-libs. Cross-posting to > security-dev and bcc-ing core-libs-dev. > > --Sean > > On 9/12/19 6:40 AM, Thomas St?fe wrote: >> Hi all, >> >> may I please have reviews for the following trivial build fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ >> >> >> Thanks, >> >> Thomas >> From weijun.wang at oracle.com Fri Sep 13 12:58:36 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Sep 2019 20:58:36 +0800 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit In-Reply-To: <151097c3-c0d3-af88-f169-f186f7b316da@oracle.com> References: <151097c3-c0d3-af88-f169-f186f7b316da@oracle.com> Message-ID: <4013B8A7-6138-4071-9F8D-B85A09D265B7@oracle.com> Also looks fine to me. I can confirm it also builds successfully on windows-x64. Thanks, Max > On Sep 13, 2019, at 3:22 PM, Alan Bateman wrote: > > > Using size_t looks okay here. > > -Alan > > On 12/09/2019 12:31, Sean Mullan wrote: >> This is in the security-libs area, not core-libs. Cross-posting to security-dev and bcc-ing core-libs-dev. >> >> --Sean >> >> On 9/12/19 6:40 AM, Thomas St?fe wrote: >>> Hi all, >>> >>> may I please have reviews for the following trivial build fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ >>> >>> Thanks, >>> >>> Thomas >>> > From peter.firmstone at zeus.net.au Fri Sep 13 22:07:15 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 14 Sep 2019 08:07:15 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D571F0A.8020709@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> Message-ID: <5D7C1313.9060709@zeus.net.au> Hi Claes, So this security manager is part of a much larger program, (a fork of Jini / Apache River), I've almost finished the transition from Java 8 to Java 11... One change I noticed is permissions granted to the java extension directory are now granted to every domain in our policy provider as the java.ext.dirs property is now blank, I also had to grant permissions to a number of jdk modules, after fixing these, everthing running as expected, except for a few minor test failures. Next step will be to test against the EA builds. On 17/08/2019 7:24 AM, Peter Firmstone wrote: > Thanks Claes, > > I'll run some tests :) > > Cheers, > > Peter. > > On 16/08/2019 9:14 PM, Claes Redestad wrote: >> Hi Peter, >> >> by explicitly ensuring the file system has been initialized before >> installing a SecurityManager using a hook in System.setSecurityManager, >> the patch at hand takes step to ensure things stay neutral w.r.t. >> Permission initialization order when using any SecurityManager. It's not >> perfectly identical, so while unlikely, there's a theoretical >> possibility some implementation scenario not covered by our regression >> tests might run into issues. Any help testing custom implementation on >> coming EA builds would be greatly appreciated! >> >> One thing we could do on the JDK end to reduce fragility somewhat in >> this area is to provoke initialization of >> sun.security.util.SecurityConstants before installing the first SM. >> >> /Claes >> >> On 2019-08-16 12:40, Peter Firmstone wrote: >>> Hello Alan, >>> >>> Yes, we are aware of those issues. >>> >>> I mean documenting that system Permission classes should be loaded >>> before setting a custom SecurityManager, accessing the file system >>> is important, so if you haven't loaded the necessary classes before >>> setting a custom SecurityManager, it won't be gracefull... The >>> simplest way of ensuring classes are loaded is by creating object >>> instances of them. >>> >>> Perhaps just a note to beware of ensuring necessary classes are >>> loaded and let developers figure out what they need. >>> >>> The recursive calls are easy enough to deal with to avoid any stack >>> overflows using ThreadLocal. >>> >>> inTrustedCodeRecursiveCall.set(Boolean.TRUE); >>> try { >>> delegateContext = AccessController.doPrivileged( >>> new PrivilegedAction(){ >>> public AccessControlContext run() { >>> return new >>> AccessControlContext(finalExecutionContext, dc); >>> } >>> } >>> ); >>> }finally { >>> inTrustedCodeRecursiveCall.set(Boolean.FALSE); // >>> Must always happen, no matter what. >>> } >>> >>> We've only really been caught out once with some jvm bootstrap >>> changes, otherwise it's been rock solid. >>> >>> The other thing we do is once we've got more than three >>> ProtectionDomains on the stack is execute the ProtectionDomain >>> implies checks in parallel. Really helps when you're making a lot >>> of network calls. >>> >>> Cheers, >>> >>> Peter. >>> >>> On 16/08/2019 5:04 PM, Alan Bateman wrote: >>>> On 15/08/2019 23:20, Peter Firmstone wrote: >>>>> : >>>>> >>>>> The following code is included in the constructor of our >>>>> SecurityManager implementation, I suspect we may need to add some >>>>> classes to this list, perhaps this is something that needs >>>>> documenting? >>>> The checkPermission method of custom security manager can run >>>> arbitrary code so recursive initialization, stack overflow, >>>> bootstrap method errors, ... are always hazards. I don't know what >>>> documentation you have in mind but I don't think there is a >>>> definite list of classes that need to be loaded/initialized before >>>> the custom security manager is set because it will come down to the >>>> code that it executes in its checkPermission method. >>>> >>>> -Alan. >>>> >>>> >>> > From Alan.Bateman at oracle.com Sat Sep 14 07:22:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Sep 2019 08:22:17 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D7C1313.9060709@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> Message-ID: On 13/09/2019 23:07, Peter Firmstone wrote: > : > > One change I noticed is permissions granted to the java extension > directory are now granted to every domain in our policy provider as > the java.ext.dirs property is now blank, I also had to grant > permissions to a number of jdk modules, after fixing these, everthing > running as expected, except for a few minor test failures. The extension mechanism was deprecated in one of the maintenance releases of the JSR for Java SE 8 so hopefully not a surprise that the system property java.ext.dirs is no longer set. Since JDK 9, the VM will will not start if this system property is set on the command line and there is also a XX option in JDK 8 to help find usages of this mechanism. So I think I'm surprised that permissions are being granted when the property isn't set. Also surprised to hear that you need to grant permissions to the java.* or jdk.* modules. Are you saying that that the permissions granted in the default JDK policy file are incomplete or that there are code is missing a call to doPrivileged somewhere? Part of the reason for asking is that the both "-Djava.security.policy=" and "-Djava.security.policy==" will augment rather than override the default permissions. Maybe you are doing something that doesn't use this mechanism and you are always overriding the permissions granted to the modules in the run-time image? -Alan From peter.firmstone at zeus.net.au Sat Sep 14 20:21:13 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 15 Sep 2019 06:21:13 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> Message-ID: <5D7D4BB9.1010408@zeus.net.au> Hi Alan, We've got a bunch of very old policy files in our test suite, so they still had policy grants using the extension directory property. The grant for the extension directory property was followed by a forward slash and asterix. Oddly when the property was missing the grant became a wildcard URL. Note this isn't the sun PolicyFile implementation, but our policy provider also augments, rather than replace, maybe there's a new policy file our provider isn't aware of? From memory there was something special about the way the extension directory property was treated by the policy provider, but I don't recall the details, the same problems don't appear to exist when other properties in policy files cannot be resolved. Modules that required permissions, seem to be service providers: grant codebase "jrt:/jdk.security.auth" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.smartcardio" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/java.security.jgss" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.localedata" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.security.jgss" { permission java.security.AllPermission "", ""; }; Regards, Peter. On 14/09/2019 5:22 PM, Alan Bateman wrote: > On 13/09/2019 23:07, Peter Firmstone wrote: >> : >> >> One change I noticed is permissions granted to the java extension >> directory are now granted to every domain in our policy provider as >> the java.ext.dirs property is now blank, I also had to grant >> permissions to a number of jdk modules, after fixing these, everthing >> running as expected, except for a few minor test failures. > The extension mechanism was deprecated in one of the maintenance > releases of the JSR for Java SE 8 so hopefully not a surprise that the > system property java.ext.dirs is no longer set. Since JDK 9, the VM > will will not start if this system property is set on the command line > and there is also a XX option in JDK 8 to help find usages of this > mechanism. So I think I'm surprised that permissions are being granted > when the property isn't set. > > Also surprised to hear that you need to grant permissions to the > java.* or jdk.* modules. Are you saying that that the permissions > granted in the default JDK policy file are incomplete or that there > are code is missing a call to doPrivileged somewhere? Part of the > reason for asking is that the both "-Djava.security.policy=" and > "-Djava.security.policy==" will augment rather than override the > default permissions. Maybe you are doing something that doesn't use > this mechanism and you are always overriding the permissions granted > to the modules in the run-time image? > > -Alan > From thomas.stuefe at gmail.com Sun Sep 15 06:42:50 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 15 Sep 2019 08:42:50 +0200 Subject: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit In-Reply-To: <4013B8A7-6138-4071-9F8D-B85A09D265B7@oracle.com> References: <151097c3-c0d3-af88-f169-f186f7b316da@oracle.com> <4013B8A7-6138-4071-9F8D-B85A09D265B7@oracle.com> Message-ID: Thanks for the reviews, will push. ..Thomas On Fri, Sep 13, 2019 at 2:58 PM Weijun Wang wrote: > Also looks fine to me. I can confirm it also builds successfully on > windows-x64. > > Thanks, > Max > > > > On Sep 13, 2019, at 3:22 PM, Alan Bateman > wrote: > > > > > > Using size_t looks okay here. > > > > -Alan > > > > On 12/09/2019 12:31, Sean Mullan wrote: > >> This is in the security-libs area, not core-libs. Cross-posting to > security-dev and bcc-ing core-libs-dev. > >> > >> --Sean > >> > >> On 9/12/19 6:40 AM, Thomas St?fe wrote: > >>> Hi all, > >>> > >>> may I please have reviews for the following trivial build fix. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230910 > >>> webrev: > >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/ > >>> > >>> Thanks, > >>> > >>> Thomas > >>> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Sep 15 12:58:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Sep 2019 13:58:56 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D7D4BB9.1010408@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> <5D7D4BB9.1010408@zeus.net.au> Message-ID: On 14/09/2019 21:21, Peter Firmstone wrote: > Hi Alan, > > We've got a bunch of very old policy files in our test suite, so they > still had policy grants using the extension directory property.? The > grant for the extension directory property was followed by a forward > slash and asterix.? Oddly when the property was missing the grant > became a wildcard URL.? Note this isn't the sun PolicyFile > implementation, but our policy provider also augments, rather than > replace, maybe there's a new policy file our provider isn't aware of? > > From memory there was something special about the way the extension > directory property was treated by the policy provider, but I don't > recall the details, the same problems don't appear to exist when other > properties in policy files cannot be resolved. > > > Modules that required permissions, seem to be service providers: In jdk/jdk repo, the following policy files are merged in the build to create the default policy: src/java.base/windows/lib/security/default.policy src/java.base/solaris/lib/security/default.policy src/java.base/share/lib/security/default.policy The default policy goes into a JDK internal location in the run-time image and used by the PolicyFile implementation. If you look in there you should see the permissions that are granted to the modules that map to the platform class loader. The intention is that deployments that are setting their own policy files don't need to be concerned about the permissions of modules in the run-time image. I suspect you are looking for a custom PolicyFile implementation to make use of these defaults to avoid needing to be concerned with the specific permissions that the modules in the run-time image. -Alan From peter.firmstone at zeus.net.au Mon Sep 16 21:15:26 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 17 Sep 2019 07:15:26 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> <5D571F0A.8020709@zeus.net.au> <5D7C1313.9060709@zeus.net.au> <5D7D4BB9.1010408@zeus.net.au> Message-ID: <5D7FFB6E.9060907@zeus.net.au> Hi Alan, Your suspicion is correct. :) Thanks for the leads, I'll look into it further. Currently the policy implementation finds policy url's in system properties, "java.security.policy" and numbered policy locations with the prefix "policy.url." if the "java.security.policy" property doesn't begin with "=" (which represents java.security.policy==). Cheers, Peter. On 15/09/2019 10:58 PM, Alan Bateman wrote: > On 14/09/2019 21:21, Peter Firmstone wrote: >> Hi Alan, >> >> We've got a bunch of very old policy files in our test suite, so they >> still had policy grants using the extension directory property. The >> grant for the extension directory property was followed by a forward >> slash and asterix. Oddly when the property was missing the grant >> became a wildcard URL. Note this isn't the sun PolicyFile >> implementation, but our policy provider also augments, rather than >> replace, maybe there's a new policy file our provider isn't aware of? >> >> From memory there was something special about the way the extension >> directory property was treated by the policy provider, but I don't >> recall the details, the same problems don't appear to exist when >> other properties in policy files cannot be resolved. >> >> >> Modules that required permissions, seem to be service providers: > In jdk/jdk repo, the following policy files are merged in the build to > create the default policy: > > src/java.base/windows/lib/security/default.policy > src/java.base/solaris/lib/security/default.policy > src/java.base/share/lib/security/default.policy > > The default policy goes into a JDK internal location in the run-time > image and used by the PolicyFile implementation. If you look in there > you should see the permissions that are granted to the modules that > map to the platform class loader. The intention is that deployments > that are setting their own policy files don't need to be concerned > about the permissions of modules in the run-time image. I suspect you > are looking for a custom PolicyFile implementation to make use of > these defaults to avoid needing to be concerned with the specific > permissions that the modules in the run-time image. > > -Alan From tianshi at amazon.com Tue Sep 17 19:46:04 2019 From: tianshi at amazon.com (Shi, Tianmin) Date: Tue, 17 Sep 2019 19:46:04 +0000 Subject: Issue related to backport JDK-7092821 Message-ID: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> Hi Everyone, This is Tianmin Shi from the Amazon Corretto team. I am new to JDK development, please let me know if I missed anything. I am working on backport JDK-7092821 to 8u and 11u. however I think there is a potential race condition introduced by the change, which could cause method getService in class java.security.Provider to return incorrect results. Which is due to the read of legacyMap at line 1260 is not synchronized with clear and repopulate of the same map?s entries inside ensureLegacyParsed(), the fix is a simpler one liner in the attached webrev. Can we push this change to tip so I can backport it with JDK-7092821 together? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 140504 bytes Desc: webrev.zip URL: From valerie.peng at oracle.com Thu Sep 19 00:56:28 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Sep 2019 17:56:28 -0700 (PDT) Subject: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" Message-ID: Can someone help reviewing this fix? AFAIK, only S11.4 have such mechanisms, e.g. RC4 which only does decryption but not encryption. But the checks seems reasonable to apply to all PKCS11 libraries when querying mechanisms. No new regression test needed as this is already caught by running existing regression tests on S11.4. Bug: https://bugs.openjdk.java.net/browse/JDK-8176837 Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/ Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Sep 19 01:01:53 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Sep 2019 18:01:53 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> References: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> Message-ID: <25344aaf-5703-f30d-a5ac-be94d0258243@oracle.com> Ping? Can someone help take a look? Thanks, Valerie On 8/15/2019 4:49 PM, Valerie Peng wrote: > > Anyone has time to help review this fix? PKCS#11 v2.40 has > inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec > (sec 2..12.3) has: > > typedef struct CK_GCM_PARAMS { > ??? CK_BYTE_PTR?????? pIv; > ??? CK_ULONG????????? ulIvLen; > ??? CK_BYTE_PTR?????? pAAD; > ??? CK_ULONG????????? ulAADLen; > ??? CK_ULONG????????? ulTagBits; > } CK_GCM_PARAMS; > > However, the header file pkcs11t.h has an extra "ulIvBits" field: > > typedef struct CK_GCM_PARAMS { > ??? CK_BYTE_PTR?????? pIv; > ??? CK_ULONG????????? ulIvLen; > *??? CK_ULONG????????? ulIvBits;* > ??? CK_BYTE_PTR?????? pAAD; > ??? CK_ULONG????????? ulAADLen; > ??? CK_ULONG????????? ulTagBits; > } CK_GCM_PARAMS; > > Some vendors such OpenHSM2 and Solaris go with the header file while > some vendor such as NSS go with the mech spec. Current SunPKCS11 > provider impl works with NSS but not with other vendors whose > CK_GCM_PARAMS struct contains ulIvBits field. Based on testing > results, OpenHSM2 and Solaris error out at init time when the > parameter length does not have their expected value. Thus, one way to > workaround this inconsistency is to re-try with a different structure > for AES GCM when the init failed. In addition, given the parameters > contains Iv and AAD which some vendor may use during subsequent > enc/dec operations, I changed to use the same model as RSASSA-PSS to > defer the freeing after the enc/dec operation is finished. Verified > the changes on Solaris 11.4 against existing GCM regression tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 > > Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Thu Sep 19 01:10:41 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Sep 2019 18:10:41 -0700 Subject: Issue related to backport JDK-7092821 In-Reply-To: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> References: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> Message-ID: <66055825-48c1-cde5-2804-fe8cc3017118@oracle.com> I will take a look. For bug management, we need to file a separate issue to keep track of this and mark it for backport. Valerie On 9/17/2019 12:46 PM, Shi, Tianmin wrote: > > Hi Everyone, > > ? This is Tianmin Shi from the Amazon Corretto team. I am new to JDK > development, please let me know if I missed anything. > > ??I am working on backport JDK-7092821 > to 8u and 11u. > however I think there is a potential race condition introduced by the > change, which could cause method getService in class > java.security.Provider to return incorrect results. Which is due to > the read of legacyMap at line 1260 is not synchronized with clear and > repopulate of the same map?s entries inside ensureLegacyParsed(), the > fix is a simpler one liner in the attached webrev. Can we push this > change to tip so I can backport it with JDK-7092821 > together? > > Thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Sep 19 01:47:30 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Sep 2019 18:47:30 -0700 Subject: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" In-Reply-To: References: Message-ID: <1dcbbe45-117f-7ff3-c061-0c3e9d901917@oracle.com> Just a very minor nit. In the initToken() implementation, there is a check for the upper 32 bits set of a mech and may continue to next mech. The continue may ignore the showinfo dump for some cases in the patch. Maybe, it might be more straightforward if we don't want to merge the log in one place: 1. always show the mech info log for every supported mechanism. 2. if not enabled, log with "DISABLED ...". 3. if upper 32 bits set, log with "UNKNOWN ...". 4. if legacy, log with "Legacy ...". for each mech { if (showInfo) { System.out.println("Mechanism " + Functions.getMechanismName(longMech) + ": " + p11.C_GetMechanismInfo(slotID, longMech); } if (!config.isEnabled(longMech)) { System.out.println("DISABLED in configuration"); continue; } if (longMech >>> 32 != 0) { System.out.println("Unknown mechanism in configuration"); continue; } int mech = (int)longMech; if (isLegacy(token, mech)) { System.out.println("Legacy mechanism in configuration"); continue; } ... } Otherwise, looks good to me. Just a nit, no more review cycle is needed for me. Thanks, Xuelei On 9/18/2019 5:56 PM, Valerie Peng wrote: > > Can someone help reviewing this fix? AFAIK, only S11.4 have such > mechanisms, e.g. RC4 which only does decryption but not encryption. > But the checks seems reasonable to apply to all PKCS11 libraries when > querying mechanisms. > No new regression test needed as this is already caught by running > existing regression tests on S11.4. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176837 > Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/ > > Thanks, > Valerie From matthias.baesken at sap.com Thu Sep 19 14:27:59 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 19 Sep 2019 14:27:59 +0000 Subject: RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces Message-ID: Hello, please reviews this fix of the pkcs11 native tracing ( P11_DEBUG guarded native traces ). I had enabled it to look into a issue with pkcs11 not working on a recently patched Linux system . But noticed that the traces did not work any more (probably mostly because of changed compilers and related warning levels ). With this change I could successfully again for run on Linux with traces enabled . (see pkcs11wrapper.h P11_DEBUG ) Maybe it would make sense to always compile with tracing enabled , and make the trace depend on a system property, what do you think ? (but this would be a separate change) . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231222 http://cr.openjdk.java.net/~mbaesken/webrevs/8231222.0/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Sep 19 14:47:42 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Sep 2019 07:47:42 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: <25344aaf-5703-f30d-a5ac-be94d0258243@oracle.com> References: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> <25344aaf-5703-f30d-a5ac-be94d0258243@oracle.com> Message-ID: <9ce51d8c-ed44-529a-93d6-b782db60bde7@oracle.com> Will the inconsistency structure be continue? I was just wondering if OpenHSM2/Solaris/NSS will fix the bug and use one structure in the future, then we may not need to workaround the issue in the calling side. I had a quick look the PKCS#11 3.0 draft, there is no update of the structure yet. Xuelei On 9/18/2019 6:01 PM, Valerie Peng wrote: > Ping? > > Can someone help take a look? > > Thanks, > > Valerie > > On 8/15/2019 4:49 PM, Valerie Peng wrote: >> >> Anyone has time to help review this fix? PKCS#11 v2.40 has >> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >> (sec 2..12.3) has: >> >> typedef struct CK_GCM_PARAMS { >> ??? CK_BYTE_PTR?????? pIv; >> ??? CK_ULONG????????? ulIvLen; >> ??? CK_BYTE_PTR?????? pAAD; >> ??? CK_ULONG????????? ulAADLen; >> ??? CK_ULONG????????? ulTagBits; >> } CK_GCM_PARAMS; >> >> However, the header file pkcs11t.h has an extra "ulIvBits" field: >> >> typedef struct CK_GCM_PARAMS { >> ??? CK_BYTE_PTR?????? pIv; >> ??? CK_ULONG????????? ulIvLen; >> *??? CK_ULONG????????? ulIvBits;* >> ??? CK_BYTE_PTR?????? pAAD; >> ??? CK_ULONG????????? ulAADLen; >> ??? CK_ULONG????????? ulTagBits; >> } CK_GCM_PARAMS; >> >> Some vendors such OpenHSM2 and Solaris go with the header file while >> some vendor such as NSS go with the mech spec. Current SunPKCS11 >> provider impl works with NSS but not with other vendors whose >> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >> results, OpenHSM2 and Solaris error out at init time when the >> parameter length does not have their expected value. Thus, one way to >> workaround this inconsistency is to re-try with a different structure >> for AES GCM when the init failed. In addition, given the parameters >> contains Iv and AAD which some vendor may use during subsequent >> enc/dec operations, I changed to use the same model as RSASSA-PSS to >> defer the freeing after the enc/dec operation is finished. Verified >> the changes on Solaris 11.4 against existing GCM regression tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >> >> Thanks, >> Valerie From joe.darcy at oracle.com Thu Sep 19 17:32:53 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Sep 2019 10:32:53 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes Message-ID: Hello, Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be helpful to mark fields in security libs classes where the class is serializable, but a non-transient instance field does *not* have a serialiable type. Such classes may have difficulties being serialized at runtime: ??? JDK-8231262 : Suppress warnings on non-serializable instance fields in security libs serializable classes ??? http://cr.openjdk.java.net/~darcy/8231262.0/ The review thread of the of the analogous core libs change, JDK-8231202: "Suppress warnings on non-serializable non-transient instance fields in serializable classes", is out on core-libs: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062456.html Thanks, -Joe From peter.firmstone at zeus.net.au Thu Sep 19 20:40:48 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 20 Sep 2019 06:40:48 +1000 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: References: Message-ID: <5D83E7D0.40002@zeus.net.au> Hello, I'd make an exception for interfaces, often these are not serializable, but their implementations may be, in this case a warning would be spurious. Regards, Peter. On 20/09/2019 3:32 AM, Joe Darcy wrote: > Hello, > > Ahead of augmenting javac's serial lint checks under JDK-8160675, it > would be helpful to mark fields in security libs classes where the > class is serializable, but a non-transient instance field does *not* > have a serialiable type. Such classes may have difficulties being > serialized at runtime: > > JDK-8231262 : Suppress warnings on non-serializable instance > fields in security libs serializable classes > http://cr.openjdk.java.net/~darcy/8231262.0/ > > The review thread of the of the analogous core libs change, > JDK-8231202: "Suppress warnings on non-serializable non-transient > instance fields in serializable classes", is out on core-libs: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062456.html > > > Thanks, > > -Joe > From valerie.peng at oracle.com Fri Sep 20 00:46:13 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Sep 2019 17:46:13 -0700 (PDT) Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Message-ID: I am not on the PKCS#11 committee and not sure about the plan. As for which one is right, I am more inclined to the "spec is right" side which is also what NSS picked. Comparing between spec and header, shouldn't the former get more eyeballs in terms of review? The header file also has a deprecated structure CK_AES_GCM_PARAMS which contains both ulIvLen and ulIvBits fields. As ulIvBits and ulIvLen are essentially same in terms of meaning except bytes vs bits. Having both just creates confusion and potential inconsistency and makes not much sense to me. Valerie ----- Original Message ----- From: xuelei.fan at oracle.com To: valerie.peng at oracle.com, security-dev at openjdk.java.net Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada Pacific Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Will the inconsistency structure be continue? I was just wondering if OpenHSM2/Solaris/NSS will fix the bug and use one structure in the future, then we may not need to workaround the issue in the calling side. I had a quick look the PKCS#11 3.0 draft, there is no update of the structure yet. Xuelei On 9/18/2019 6:01 PM, Valerie Peng wrote: > Ping? > > Can someone help take a look? > > Thanks, > > Valerie > > On 8/15/2019 4:49 PM, Valerie Peng wrote: >> >> Anyone has time to help review this fix? PKCS#11 v2.40 has >> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >> (sec 2..12.3) has: >> >> typedef struct CK_GCM_PARAMS { >> ??? CK_BYTE_PTR?????? pIv; >> ??? CK_ULONG????????? ulIvLen; >> ??? CK_BYTE_PTR?????? pAAD; >> ??? CK_ULONG????????? ulAADLen; >> ??? CK_ULONG????????? ulTagBits; >> } CK_GCM_PARAMS; >> >> However, the header file pkcs11t.h has an extra "ulIvBits" field: >> >> typedef struct CK_GCM_PARAMS { >> ??? CK_BYTE_PTR?????? pIv; >> ??? CK_ULONG????????? ulIvLen; >> *??? CK_ULONG????????? ulIvBits;* >> ??? CK_BYTE_PTR?????? pAAD; >> ??? CK_ULONG????????? ulAADLen; >> ??? CK_ULONG????????? ulTagBits; >> } CK_GCM_PARAMS; >> >> Some vendors such OpenHSM2 and Solaris go with the header file while >> some vendor such as NSS go with the mech spec. Current SunPKCS11 >> provider impl works with NSS but not with other vendors whose >> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >> results, OpenHSM2 and Solaris error out at init time when the >> parameter length does not have their expected value. Thus, one way to >> workaround this inconsistency is to re-try with a different structure >> for AES GCM when the init failed. In addition, given the parameters >> contains Iv and AAD which some vendor may use during subsequent >> enc/dec operations, I changed to use the same model as RSASSA-PSS to >> defer the freeing after the enc/dec operation is finished. Verified >> the changes on Solaris 11.4 against existing GCM regression tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Fri Sep 20 00:57:23 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Sep 2019 17:57:23 -0700 (PDT) Subject: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" Message-ID: <4d147966-9c30-420e-a17b-fcf59161346b@default> Hi Xuelei, I have added the debugging output for the "unknown" case as you suggested. Webrev updated in case you feel like taking another look. http://cr.openjdk.java.net/~valeriep/8176837/webrev.01/ Thanks for the review~ Valerie ----- Original Message ----- From: xuelei.fan at oracle.com To: valerie.peng at oracle.com, security-dev at openjdk.java.net Sent: Wednesday, September 18, 2019 6:47:31 PM GMT -08:00 US/Canada Pacific Subject: Re: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" Just a very minor nit. In the initToken() implementation, there is a check for the upper 32 bits set of a mech and may continue to next mech. The continue may ignore the showinfo dump for some cases in the patch. Maybe, it might be more straightforward if we don't want to merge the log in one place: 1. always show the mech info log for every supported mechanism. 2. if not enabled, log with "DISABLED ...". 3. if upper 32 bits set, log with "UNKNOWN ...". 4. if legacy, log with "Legacy ...". for each mech { if (showInfo) { System.out.println("Mechanism " + Functions.getMechanismName(longMech) + ": " + p11.C_GetMechanismInfo(slotID, longMech); } if (!config.isEnabled(longMech)) { System.out.println("DISABLED in configuration"); continue; } if (longMech >>> 32 != 0) { System.out.println("Unknown mechanism in configuration"); continue; } int mech = (int)longMech; if (isLegacy(token, mech)) { System.out.println("Legacy mechanism in configuration"); continue; } ... } Otherwise, looks good to me. Just a nit, no more review cycle is needed for me. Thanks, Xuelei On 9/18/2019 5:56 PM, Valerie Peng wrote: > > Can someone help reviewing this fix? AFAIK, only S11.4 have such > mechanisms, e.g. RC4 which only does decryption but not encryption. > But the checks seems reasonable to apply to all PKCS11 libraries when > querying mechanisms. > No new regression test needed as this is already caught by running > existing regression tests on S11.4. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176837 > Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/ > > Thanks, > Valerie From xuelei.fan at oracle.com Fri Sep 20 02:49:32 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Sep 2019 19:49:32 -0700 Subject: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" In-Reply-To: <4d147966-9c30-420e-a17b-fcf59161346b@default> References: <4d147966-9c30-420e-a17b-fcf59161346b@default> Message-ID: Looks good to me. Thanks, Xuelei On 9/19/2019 5:57 PM, Valerie Peng wrote: > Hi Xuelei, > > I have added the debugging output for the "unknown" case as you suggested. > > Webrev updated in case you feel like taking another look. > http://cr.openjdk.java.net/~valeriep/8176837/webrev.01/ > > Thanks for the review~ > Valerie > > ----- Original Message ----- > From: xuelei.fan at oracle.com > To: valerie.peng at oracle.com, security-dev at openjdk.java.net > Sent: Wednesday, September 18, 2019 6:47:31 PM GMT -08:00 US/Canada Pacific > Subject: Re: [14] RFR JDK-8176837 "SunPKCS11 provider needs to check more details on PKCS11 Mechanism" > > Just a very minor nit. > > In the initToken() implementation, there is a check for the upper 32 > bits set of a mech and may continue to next mech. The continue may > ignore the showinfo dump for some cases in the patch. > > Maybe, it might be more straightforward if we don't want to merge the > log in one place: > 1. always show the mech info log for every supported mechanism. > 2. if not enabled, log with "DISABLED ...". > 3. if upper 32 bits set, log with "UNKNOWN ...". > 4. if legacy, log with "Legacy ...". > > for each mech { > if (showInfo) { > System.out.println("Mechanism " + > Functions.getMechanismName(longMech) + ": " + > p11.C_GetMechanismInfo(slotID, longMech); > } > > if (!config.isEnabled(longMech)) { > System.out.println("DISABLED in configuration"); > > continue; > } > > if (longMech >>> 32 != 0) { > System.out.println("Unknown mechanism in configuration"); > > continue; > } > > int mech = (int)longMech; > if (isLegacy(token, mech)) { > System.out.println("Legacy mechanism in configuration"); > > continue; > } > > ... > } > > Otherwise, looks good to me. Just a nit, no more review cycle is needed > for me. > > Thanks, > Xuelei > > On 9/18/2019 5:56 PM, Valerie Peng wrote: >> >> Can someone help reviewing this fix? AFAIK, only S11.4 have such >> mechanisms, e.g. RC4 which only does decryption but not encryption. >> But the checks seems reasonable to apply to all PKCS11 libraries when >> querying mechanisms. >> No new regression test needed as this is already caught by running >> existing regression tests on S11.4. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176837 >> Webrev: http://cr.openjdk.java.net/~valeriep/8176837/webrev.00/ >> >> Thanks, >> Valerie From sha.jiang at oracle.com Fri Sep 20 06:56:41 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 20 Sep 2019 14:56:41 +0800 Subject: RFR[14] JDK-8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID Message-ID: Hi, Tests sun/security/pkcs11/Secmod/AddTrustedCert.java and sun/security/pkcs11/tls/TestKeyMaterial.java failed due to some changes in NSS. This fix just workarounds this problem. For more details, please see the comments in this JBS issue. And it also provides a pre-built NSS libs for linux-x64 platform. Then, the PKCS11 tests won't depend on the system built-in NSS libs in our CI on this platform. Issue: https://bugs.openjdk.java.net/browse/JDK-8180837 Webrev: http://cr.openjdk.java.net/~jjiang/8180837/webrev.00/ Best regards, John Jiang From weijun.wang at oracle.com Fri Sep 20 09:06:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Sep 2019 17:06:04 +0800 Subject: RFR CSR 8231106: PKCS12 keystore integrity check is ineffective Message-ID: Please review the CSR at https://bugs.openjdk.java.net/browse/JDK-8231292 The bug itself is https://bugs.openjdk.java.net/browse/JDK-8231106. Since there is only spec change, I'll not request for a code review and every reviewer of the CSR will be review of the code change. Thanks, Max From xuelei.fan at oracle.com Fri Sep 20 15:12:50 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 20 Sep 2019 08:12:50 -0700 Subject: RFR[14] JDK-8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID In-Reply-To: References: Message-ID: Looks good to me. Xuelei On 9/19/2019 11:56 PM, sha.jiang at oracle.com wrote: > Hi, > Tests sun/security/pkcs11/Secmod/AddTrustedCert.java and > sun/security/pkcs11/tls/TestKeyMaterial.java failed due to some changes > in NSS. > This fix just workarounds this problem. For more details, please see the > comments in this JBS issue. > And it also provides a pre-built NSS libs for linux-x64 platform. Then, > the PKCS11 tests won't depend on the system built-in NSS libs in our CI > on this platform. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8180837 > Webrev: http://cr.openjdk.java.net/~jjiang/8180837/webrev.00/ > > Best regards, > John Jiang > From Alan.Bateman at oracle.com Fri Sep 20 16:29:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 17:29:39 +0100 Subject: AccessController.getInheritedAccessControlContext, does it need to call through the VM Message-ID: Is there any reason for AccessController.getInheritedAccessControlContext to be a native method? I'm wondering if we can use the shared secrets mechanism to read the Thread.inheritedAccessControlContext field instead. -Alan From chris.hegarty at oracle.com Sat Sep 21 11:15:30 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 21 Sep 2019 12:15:30 +0100 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: References: Message-ID: <17D6D260-E44B-421F-ADEA-22BFBCAF6C01@oracle.com> > On 19 Sep 2019, at 18:32, Joe Darcy wrote: > > Hello, > > Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be helpful to mark fields in security libs classes where the class is serializable, but a non-transient instance field does *not* have a serialiable type. Such classes may have difficulties being serialized at runtime: > > JDK-8231262 : Suppress warnings on non-serializable instance fields in security libs serializable classes > http://cr.openjdk.java.net/~darcy/8231262.0/ The changes look good to me. The fields in PrivateCredentialPermission and SecureRandom, could be made final and assigned null, ensuring non-Serializable types will never leak into them. But equally, this could be left to a follow on change for someone working in the security area. -Chris. From joe.darcy at oracle.com Sat Sep 21 16:32:11 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 21 Sep 2019 09:32:11 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <17D6D260-E44B-421F-ADEA-22BFBCAF6C01@oracle.com> References: <17D6D260-E44B-421F-ADEA-22BFBCAF6C01@oracle.com> Message-ID: <74f33177-3bdd-112a-8d93-96fd67942bd6@oracle.com> On 9/21/2019 4:15 AM, Chris Hegarty wrote: > >> On 19 Sep 2019, at 18:32, Joe Darcy wrote: >> >> Hello, >> >> Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be helpful to mark fields in security libs classes where the class is serializable, but a non-transient instance field does *not* have a serialiable type. Such classes may have difficulties being serialized at runtime: >> >> JDK-8231262 : Suppress warnings on non-serializable instance fields in security libs serializable classes >> http://cr.openjdk.java.net/~darcy/8231262.0/ > The changes look good to me. > > The fields in PrivateCredentialPermission and SecureRandom, could be made final and assigned null, ensuring non-Serializable types will never leak into them. But equally, this could be left to a follow on change for someone working in the security area. I'd prefer to leave such code changes to people working more directly in the area. Thanks for the review, -Joe From tianshi at amazon.com Mon Sep 23 08:21:08 2019 From: tianshi at amazon.com (Shi, Tianmin) Date: Mon, 23 Sep 2019 08:21:08 +0000 Subject: Issue related to backport JDK-7092821 In-Reply-To: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> References: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> Message-ID: Hi Everyone, I haven?t get any response yet for my previous email. so I would like to raise this issue again and also attached a small code sample to repo the issue. This sample code works fine in JDK8 but print out this line in JDK13 due to the race condition "CertificateFactory.Fixed is NULL" Thank you, From: "Shi, Tianmin" Date: Tuesday, September 17, 2019 at 12:46 PM To: "security-dev at openjdk.java.net" Subject: Issue related to backport JDK-7092821 Hi Everyone, This is Tianmin Shi from the Amazon Corretto team. I am new to JDK development, please let me know if I missed anything. I am working on backport JDK-7092821 to 8u and 11u. however I think there is a potential race condition introduced by the change, which could cause method getService in class java.security.Provider to return incorrect results. Which is due to the read of legacyMap at line 1260 is not synchronized with clear and repopulate of the same map?s entries inside ensureLegacyParsed(), the fix is a simpler one liner in the attached webrev. Can we push this change to tip so I can backport it with JDK-7092821 together? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.java Type: application/octet-stream Size: 1919 bytes Desc: Main.java URL: From huangjia at loongson.cn Mon Sep 23 10:04:20 2019 From: huangjia at loongson.cn (Jia Huang) Date: Mon, 23 Sep 2019 18:04:20 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc Message-ID: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8231351 Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. According to the comments in JDK-8231338, it was caused by the improper NSS libs of the system. These failures are confusing and hard to diagnose. It might be better to add some notes for the pkcs11 tests. Thanks a lot. Best regards, Jia From sha.jiang at oracle.com Mon Sep 23 12:54:51 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 23 Sep 2019 20:54:51 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> Message-ID: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Hi Jia, I think this isn't a general testing problem. It may not worthy of highlighting this point in the JDK testing doc. In fact, PKCS11 tests have their own doc at: test/jdk/sun/security/pkcs11/README Best regards, John Jiang On 2019/9/23 18:04, Jia Huang wrote: > Hi all, > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 > Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ > > sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. > According to the comments in JDK-8231338, it was caused by the > improper NSS libs of the system. > > These failures are confusing and hard to diagnose. > It might be better to add some notes for the pkcs11 tests. > > Thanks a lot. > > Best regards, > Jia > > > From matthias.baesken at sap.com Mon Sep 23 13:15:47 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Sep 2019 13:15:47 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Message-ID: Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Sep 23 13:52:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Sep 2019 13:52:48 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: Message-ID: Hi Matthias, generally I agree that it's a good idea to have more diagnostic output in case of failures in this test. But, given that there's an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn't good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it's not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph ; Zeller, Arno Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Sep 23 14:06:44 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Sep 2019 14:06:44 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: Message-ID: Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let's see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it's a good idea to have more diagnostic output in case of failures in this test. But, given that there's an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn't good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it's not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Sep 23 14:49:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Sep 2019 14:49:30 +0000 Subject: RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces In-Reply-To: References: Message-ID: Hi Matthias, your change looks good to me. Don't forget to update the copyright years before pushing. Best regards Christoph From: security-dev On Behalf Of Baesken, Matthias Sent: Donnerstag, 19. September 2019 16:28 To: security-dev at openjdk.java.net Subject: [CAUTION] RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces Hello, please reviews this fix of the pkcs11 native tracing ( P11_DEBUG guarded native traces ). I had enabled it to look into a issue with pkcs11 not working on a recently patched Linux system . But noticed that the traces did not work any more (probably mostly because of changed compilers and related warning levels ). With this change I could successfully again for run on Linux with traces enabled . (see pkcs11wrapper.h P11_DEBUG ) Maybe it would make sense to always compile with tracing enabled , and make the trace depend on a system property, what do you think ? (but this would be a separate change) . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231222 http://cr.openjdk.java.net/~mbaesken/webrevs/8231222.0/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Sep 23 15:02:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 23 Sep 2019 15:02:19 +0000 Subject: RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review ! I'll update the Copyright years . Will push it as XS tomorrow in case of no further comments / objections. Best regards, Matthias From: Langer, Christoph Sent: Montag, 23. September 2019 16:50 To: Baesken, Matthias ; security-dev at openjdk.java.net Subject: RE: RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces Hi Matthias, your change looks good to me. Don't forget to update the copyright years before pushing. Best regards Christoph From: security-dev > On Behalf Of Baesken, Matthias Sent: Donnerstag, 19. September 2019 16:28 To: security-dev at openjdk.java.net Subject: [CAUTION] RFR: 8231222: fix pkcs11 P11_DEBUG guarded native traces Hello, please reviews this fix of the pkcs11 native tracing ( P11_DEBUG guarded native traces ). I had enabled it to look into a issue with pkcs11 not working on a recently patched Linux system . But noticed that the traces did not work any more (probably mostly because of changed compilers and related warning levels ). With this change I could successfully again for run on Linux with traces enabled . (see pkcs11wrapper.h P11_DEBUG ) Maybe it would make sense to always compile with tracing enabled , and make the trace depend on a system property, what do you think ? (but this would be a separate change) . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231222 http://cr.openjdk.java.net/~mbaesken/webrevs/8231222.0/ Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Sep 23 15:18:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Sep 2019 08:18:00 -0700 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: I think this type of comment fits well in the top level test doc. It just provides basic instructions for setting up these tests so that they pass without going into too much detail. Perhaps a reference to the pkcs11 README for more details would be a good idea. Looks good to me. /Erik On 2019-09-23 05:54, sha.jiang at oracle.com wrote: > Hi Jia, > I think this isn't a general testing problem. > It may not worthy of highlighting this point in the JDK testing doc. > In fact, PKCS11 tests have their own doc at: > test/jdk/sun/security/pkcs11/README > > Best regards, > John Jiang > > On 2019/9/23 18:04, Jia Huang wrote: >> Hi all, >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 >> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >> >> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >> According to the comments in JDK-8231338, it was caused by the >> improper NSS libs of the system. >> >> These failures are confusing and hard to diagnose. >> It might be better to add some notes for the pkcs11 tests. >> >> Thanks a lot. >> >> Best regards, >> Jia >> >> >> From sean.mullan at oracle.com Mon Sep 23 19:19:46 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Sep 2019 15:19:46 -0400 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: References: Message-ID: Hi Joe, It's a little odd to suppress the warnings in the X509CertImpl class since it is a subclass of java.security.cert.Certificate which implements the writeReplace method so these fields are not serialized. Also for other classes like X509Key which are internal it is a little odd to suppress the warnings for fields like bitStringKey that are not Serializable and are never serialized. It is probably better to mark them as transient, but I'm not really sure it is worth making those changes for otherwise stable code. I guess when I look at some of the warnings, I might think there is an issue when there really isn't. I suppose these are not things you can easily detect at compile time, but I am wondering what you think. --Sean On 9/19/19 1:32 PM, Joe Darcy wrote: > Hello, > > Ahead of augmenting javac's serial lint checks under JDK-8160675, it > would be helpful to mark fields in security libs classes where the class > is serializable, but a non-transient instance field does *not* have a > serialiable type. Such classes may have difficulties being serialized at > runtime: > > ??? JDK-8231262 : Suppress warnings on non-serializable instance fields > in security libs serializable classes > ??? http://cr.openjdk.java.net/~darcy/8231262.0/ > > The review thread of the of the analogous core libs change, JDK-8231202: > "Suppress warnings on non-serializable non-transient instance fields in > serializable classes", is out on core-libs: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-September/062456.html > > > Thanks, > > -Joe > From joe.darcy at oracle.com Mon Sep 23 20:16:32 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 23 Sep 2019 13:16:32 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: References: Message-ID: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> Hi Sean, On 9/23/2019 12:19 PM, Sean Mullan wrote: > Hi Joe, > > It's a little odd to suppress the warnings in the X509CertImpl class > since it is a subclass of java.security.cert.Certificate which > implements the writeReplace method so these fields are not serialized. > > Also for other classes like X509Key which are internal it is a little > odd to suppress the warnings for fields like bitStringKey that are not > Serializable and are never serialized. It is probably better to mark > them as transient, but I'm not really sure it is worth making those > changes for otherwise stable code. I guess when I look at some of the > warnings, I might think there is an issue when there really isn't. > > I suppose these are not things you can easily detect at compile time, > but I am wondering what you think. > > Thanks for the feedback. One motivation to send out these review is to help tune-up the warning analysis. A brief philosophical note, when designing any sort of warning scheme the cost of false positives vs false negatives needs to be weighed as any static check can likely only approximate the full range of dynamic behavior. The checks as written give up, i.e. do not attempt to analyze and warn, if the class uses serialPersistentFields. It would be possible for the checks to similarly decline to analyze if any of the various write* or read* serialization methods are defined. My current impression is that the net benefit for the checks when write* methods are defined is still worthwhile, even though there are some false positives. As you observe, given the handling of the serial methods, bitStringKey in X509Key is effectively transient. I think it would be better serial coding for the field to be explicitly marked as transient to make it more obviously consistent with the implementation. Moreover, all the instance fields in X509Key except encodedKey look to be effectively transient. Since the class already has a serialVersionUID, marking the fields as transient is a serial-compatible change. Cheers, -Joe From joe.darcy at oracle.com Tue Sep 24 00:15:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 23 Sep 2019 17:15:51 -0700 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss Message-ID: Hello, Another module, another review request as part of making serial warnings more robust: ??? JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss ??? http://cr.openjdk.java.net/~darcy/8231368.0/ (Related earlier review https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) In this latest review, I included a comment in KRBError.java that its writeObject method uses a different encoding scheme. Thanks, -Joe From hohensee at amazon.com Tue Sep 24 02:09:06 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 24 Sep 2019 02:09:06 +0000 Subject: Issue related to backport JDK-7092821 In-Reply-To: References: <01878D70-5FEA-45D5-B9AA-1896278FF2F9@amazon.com> Message-ID: I?ve filed https://bugs.openjdk.java.net/browse/JDK-8231387 to track this. Thanks, Paul From: "Shi, Tianmin" Date: Monday, September 23, 2019 at 1:21 AM To: "security-dev at openjdk.java.net" Cc: "Hohensee, Paul" Subject: Re: Issue related to backport JDK-7092821 Hi Everyone, I haven?t get any response yet for my previous email. so I would like to raise this issue again and also attached a small code sample to repo the issue. This sample code works fine in JDK8 but print out this line in JDK13 due to the race condition "CertificateFactory.Fixed is NULL" Thank you, From: "Shi, Tianmin" Date: Tuesday, September 17, 2019 at 12:46 PM To: "security-dev at openjdk.java.net" Subject: Issue related to backport JDK-7092821 Hi Everyone, This is Tianmin Shi from the Amazon Corretto team. I am new to JDK development, please let me know if I missed anything. I am working on backport JDK-7092821 to 8u and 11u. however I think there is a potential race condition introduced by the change, which could cause method getService in class java.security.Provider to return incorrect results. Which is due to the read of legacyMap at line 1260 is not synchronized with clear and repopulate of the same map?s entries inside ensureLegacyParsed(), the fix is a simpler one liner in the attached webrev. Can we push this change to tip so I can backport it with JDK-7092821 together? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From huangjia at loongson.cn Tue Sep 24 03:57:07 2019 From: huangjia at loongson.cn (Jia Huang) Date: Tue, 24 Sep 2019 11:57:07 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Hi Erik, Thank you for your review and valuable comments. Updated: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ - The reference to the pkcs11 README and the reviewers had been added. Please note the user in the patch. Hope you wouldn't mind it. Thanks. Could you please sponsor it? Thanks a lot. Best regards, Jia ? 2019?09?23? 23:18, Erik Joelsson ??: > I think this type of comment fits well in the top level test doc. It > just provides basic instructions for setting up these tests so that > they pass without going into too much detail. Perhaps a reference to > the pkcs11 README for more details would be a good idea. > > Looks good to me. > > /Erik > > On 2019-09-23 05:54, sha.jiang at oracle.com wrote: >> Hi Jia, >> I think this isn't a general testing problem. >> It may not worthy of highlighting this point in the JDK testing doc. >> In fact, PKCS11 tests have their own doc at: >> test/jdk/sun/security/pkcs11/README >> >> Best regards, >> John Jiang >> >> On 2019/9/23 18:04, Jia Huang wrote: >>> Hi all, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231351 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >>> >>> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >>> According to the comments in JDK-8231338, it was caused by the >>> improper NSS libs of the system. >>> >>> These failures are confusing and hard to diagnose. >>> It might be better to add some notes for the pkcs11 tests. >>> >>> Thanks a lot. >>> >>> Best regards, >>> Jia >>> >>> >>> From huangjia at loongson.cn Tue Sep 24 04:06:03 2019 From: huangjia at loongson.cn (Jia Huang) Date: Tue, 24 Sep 2019 12:06:03 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: Hi John Jiang, Thank you for your review. ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: > In fact, PKCS11 tests have their own doc at: > test/jdk/sun/security/pkcs11/README I'm afraid most people wouldn't see test/jdk/sun/security/pkcs11/README at all. So it makes very little sense to add the notes in it. I still prefer doc/testing.md. A reference to test/jdk/sun/security/pkcs11/README had been added in [1]. Thanks a lot. Best regards, Jia [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ From xuelei.fan at oracle.com Tue Sep 24 06:01:47 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 23 Sep 2019 23:01:47 -0700 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> Message-ID: <95ad95a4-bed5-63cc-2628-366d34ac5aa5@oracle.com> I may be a little bit hesitate to add such words, "highly recommended to use the latest NSS version ...", in the general TOP doc. There are a few issues that I wary about: It is not always expected that all PKCS 11 test should be run on latest NSS version. Otherwise, there might be compatibility issues that we did not handle properly. The JDK is expected to work with as much NSS versions as possible, not just the latest version. It is good to know which version does not really work because of a specific bug. The note should be added as close as to the place where the issue happens, for maintaining and searching. I think the best place could be the test code where the failure occurs (test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java?). However, I'm still not sure if we really want this note. JDK-8231338 is reported with NSS 3.35. Per the comment, the test could pass with NSS 3.35 on Debian and Ubuntu, and the bug submitter could pass the test with a proper build of NSS 3.35. And then the bug was closed as "Cannot Reproduce". I think we are done with the bug. It might not be necessary to add a note any more. Just my $.02. Xuelei On 9/23/2019 9:06 PM, Jia Huang wrote: > Hi John Jiang, > > Thank you for your review. > > ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: >> In fact, PKCS11 tests have their own doc at: >> test/jdk/sun/security/pkcs11/README > I'm afraid most people wouldn't see test/jdk/sun/security/pkcs11/README > at all. > So it makes very little sense to add the notes in it. > I still prefer doc/testing.md. > > A reference to test/jdk/sun/security/pkcs11/README had been added in [1]. > > Thanks a lot. > Best regards, > Jia > > [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ > > > From fujie at loongson.cn Tue Sep 24 07:03:21 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 24 Sep 2019 15:03:21 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <95ad95a4-bed5-63cc-2628-366d34ac5aa5@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <95ad95a4-bed5-63cc-2628-366d34ac5aa5@oracle.com> Message-ID: <8a2f2248-5daf-9db8-61ab-73103849685a@loongson.cn> I can't understand why JDK-8231338 was closed as "Cannot Reproduce" since it can always be reproduced on Ubuntu 18.04.2 LTS. Reproduce on Ubuntu 18.04 is very simple: ------------------------------------- make test TEST="jtreg:sun/security/pkcs11/Secmod/AddTrustedCert.java" CONF=re ------------------------------------- In the fix of JDK-8180837, the NSS-3.35 was assumed to work with AddTrustedCert.java, but it failed on Ubuntu 18.04. I wonder whether there is some other reasons which may lead to the failure. So I filed JDK-8231338 hoping to find the root cause of the failure. But I was disappointed since the author of JDK-8180837 just told me: ?"it's hard to say what's the problem, Linux, NSS build or others, on this test case." In fact, the root cause for the failure on Ubuntu 18.04 still remains unknown. Thanks a lot. Best regards, Jie On 2019/9/24 ??2:01, Xuelei Fan wrote: > I may be a little bit hesitate to add such words, "highly recommended > to use the latest NSS version ...", in the general TOP doc.? There are > a few issues that I wary about: > > It is not always expected that all PKCS 11 test should be run on > latest NSS version.? Otherwise, there might be compatibility issues > that we did not handle properly.? The JDK is expected to work with as > much NSS versions as possible, not just the latest version.? It is > good to know which version does not really work because of a specific > bug. > > The note should be added as close as to the place where the issue > happens, for maintaining and searching.? I think the best place could > be the test code where the failure occurs > (test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java?). > > However, I'm still not sure if we really want this note. > > JDK-8231338 is reported with NSS 3.35.? Per the comment, the test > could pass with NSS 3.35 on Debian and Ubuntu, and the bug submitter > could pass the test with a proper build of NSS 3.35. And then the bug > was closed as "Cannot Reproduce".? I think we are done with the bug.? > It might not be necessary to add a note any more. > > Just my $.02. > > Xuelei > > On 9/23/2019 9:06 PM, Jia Huang wrote: >> Hi John Jiang, >> >> Thank you for your review. >> >> ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: >>> In fact, PKCS11 tests have their own doc at: >>> test/jdk/sun/security/pkcs11/README >> I'm afraid most people wouldn't see >> test/jdk/sun/security/pkcs11/README at all. >> So it makes very little sense to add the notes in it. >> I still prefer doc/testing.md. >> >> A reference to test/jdk/sun/security/pkcs11/README had been added in >> [1]. >> >> Thanks a lot. >> Best regards, >> Jia >> >> [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ >> >> >> From sha.jiang at oracle.com Tue Sep 24 08:01:26 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 24 Sep 2019 16:01:26 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <8a2f2248-5daf-9db8-61ab-73103849685a@loongson.cn> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <95ad95a4-bed5-63cc-2628-366d34ac5aa5@oracle.com> <8a2f2248-5daf-9db8-61ab-73103849685a@loongson.cn> Message-ID: <6898c0fa-f1ce-61a3-f6fc-f8d00945b972@oracle.com> Hi Jie, IIRC, this test passed on your Ubuntu 18.04 with a new built NSS 3.35 libs. So, I suspected your Linux or the system built-in NSS libs had something wrong. Now that this test passed with NSS 3.35 on others' Linux, including mine, it may not make sense that this test is skipped for NSS 3.35 on all platforms (even Linux only). Certainly, you are always welcomed to re-open JDK-8231338. A bit furthermore... Some different PKCS11 test cases have been skipped due to the bugs on different NSS releases or platforms. It would be better not to make the codes more complicated to deal with this scenario. The alternative NSS libs could be specified (via system property test.nss.lib.paths) for PKCS11 tests. It doesn't have to depend on the system built-in NSS libs. Different people can use different NSS versions based on their requirements. Best regards, John Jiang On 2019/9/24 15:03, Jie Fu wrote: > I can't understand why JDK-8231338 was closed as "Cannot Reproduce" > since it can always be reproduced on Ubuntu 18.04.2 LTS. > > Reproduce on Ubuntu 18.04 is very simple: > ------------------------------------- > make test TEST="jtreg:sun/security/pkcs11/Secmod/AddTrustedCert.java" > CONF=re > ------------------------------------- > > In the fix of JDK-8180837, the NSS-3.35 was assumed to work with > AddTrustedCert.java, but it failed on Ubuntu 18.04. > I wonder whether there is some other reasons which may lead to the > failure. > So I filed JDK-8231338 hoping to find the root cause of the failure. > > But I was disappointed since the author of JDK-8180837 just told me: > ?"it's hard to say what's the problem, Linux, NSS build or others, on > this test case." > > In fact, the root cause for the failure on Ubuntu 18.04 still remains > unknown. > > Thanks a lot. > Best regards, > Jie > > On 2019/9/24 ??2:01, Xuelei Fan wrote: >> I may be a little bit hesitate to add such words, "highly recommended >> to use the latest NSS version ...", in the general TOP doc.? There >> are a few issues that I wary about: >> >> It is not always expected that all PKCS 11 test should be run on >> latest NSS version.? Otherwise, there might be compatibility issues >> that we did not handle properly.? The JDK is expected to work with as >> much NSS versions as possible, not just the latest version.? It is >> good to know which version does not really work because of a specific >> bug. >> >> The note should be added as close as to the place where the issue >> happens, for maintaining and searching.? I think the best place could >> be the test code where the failure occurs >> (test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java?). >> >> However, I'm still not sure if we really want this note. >> >> JDK-8231338 is reported with NSS 3.35.? Per the comment, the test >> could pass with NSS 3.35 on Debian and Ubuntu, and the bug submitter >> could pass the test with a proper build of NSS 3.35. And then the bug >> was closed as "Cannot Reproduce".? I think we are done with the bug.? >> It might not be necessary to add a note any more. >> >> Just my $.02. >> >> Xuelei >> >> On 9/23/2019 9:06 PM, Jia Huang wrote: >>> Hi John Jiang, >>> >>> Thank you for your review. >>> >>> ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: >>>> In fact, PKCS11 tests have their own doc at: >>>> test/jdk/sun/security/pkcs11/README >>> I'm afraid most people wouldn't see >>> test/jdk/sun/security/pkcs11/README at all. >>> So it makes very little sense to add the notes in it. >>> I still prefer doc/testing.md. >>> >>> A reference to test/jdk/sun/security/pkcs11/README had been added in >>> [1]. >>> >>> Thanks a lot. >>> Best regards, >>> Jia >>> >>> [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ >>> >>> >>> > > From fujie at loongson.cn Tue Sep 24 08:29:05 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 24 Sep 2019 16:29:05 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <6898c0fa-f1ce-61a3-f6fc-f8d00945b972@oracle.com> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <95ad95a4-bed5-63cc-2628-366d34ac5aa5@oracle.com> <8a2f2248-5daf-9db8-61ab-73103849685a@loongson.cn> <6898c0fa-f1ce-61a3-f6fc-f8d00945b972@oracle.com> Message-ID: <00a455f7-2c05-ebaa-d768-8a978427fd51@loongson.cn> Hi John Jiang, I don't care which NSS you have skipped. I am just curious about the root cause for the failure on Ubuntu. It seems more reasonable to close JDK-8231338 as won't fix. But you just closed it as can't reproduce. Thanks. Best regards, Jie On 2019/9/24 ??4:01, sha.jiang at oracle.com wrote: > Hi Jie, > IIRC, this test passed on your Ubuntu 18.04 with a new built NSS 3.35 > libs. > So, I suspected your Linux or the system built-in NSS libs had > something wrong. > Now that this test passed with NSS 3.35 on others' Linux, including > mine, it may not make sense that this test is skipped for NSS 3.35 on > all platforms (even Linux only). > Certainly, you are always welcomed to re-open JDK-8231338. > > A bit furthermore... > Some different PKCS11 test cases have been skipped due to the bugs on > different NSS releases or platforms. > It would be better not to make the codes more complicated to deal with > this scenario. > The alternative NSS libs could be specified (via system property > test.nss.lib.paths) for PKCS11 tests. > It doesn't have to depend on the system built-in NSS libs. > Different people can use different NSS versions based on their > requirements. > > Best regards, > John Jiang > > On 2019/9/24 15:03, Jie Fu wrote: >> I can't understand why JDK-8231338 was closed as "Cannot Reproduce" >> since it can always be reproduced on Ubuntu 18.04.2 LTS. >> >> Reproduce on Ubuntu 18.04 is very simple: >> ------------------------------------- >> make test TEST="jtreg:sun/security/pkcs11/Secmod/AddTrustedCert.java" >> CONF=re >> ------------------------------------- >> >> In the fix of JDK-8180837, the NSS-3.35 was assumed to work with >> AddTrustedCert.java, but it failed on Ubuntu 18.04. >> I wonder whether there is some other reasons which may lead to the >> failure. >> So I filed JDK-8231338 hoping to find the root cause of the failure. >> >> But I was disappointed since the author of JDK-8180837 just told me: >> ?"it's hard to say what's the problem, Linux, NSS build or others, on >> this test case." >> >> In fact, the root cause for the failure on Ubuntu 18.04 still remains >> unknown. >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/9/24 ??2:01, Xuelei Fan wrote: >>> I may be a little bit hesitate to add such words, "highly >>> recommended to use the latest NSS version ...", in the general TOP >>> doc.? There are a few issues that I wary about: >>> >>> It is not always expected that all PKCS 11 test should be run on >>> latest NSS version.? Otherwise, there might be compatibility issues >>> that we did not handle properly.? The JDK is expected to work with >>> as much NSS versions as possible, not just the latest version.? It >>> is good to know which version does not really work because of a >>> specific bug. >>> >>> The note should be added as close as to the place where the issue >>> happens, for maintaining and searching.? I think the best place >>> could be the test code where the failure occurs >>> (test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java?). >>> >>> However, I'm still not sure if we really want this note. >>> >>> JDK-8231338 is reported with NSS 3.35.? Per the comment, the test >>> could pass with NSS 3.35 on Debian and Ubuntu, and the bug submitter >>> could pass the test with a proper build of NSS 3.35. And then the >>> bug was closed as "Cannot Reproduce".? I think we are done with the >>> bug.? It might not be necessary to add a note any more. >>> >>> Just my $.02. >>> >>> Xuelei >>> >>> On 9/23/2019 9:06 PM, Jia Huang wrote: >>>> Hi John Jiang, >>>> >>>> Thank you for your review. >>>> >>>> ? 2019?09?23? 20:54, sha.jiang at oracle.com ??: >>>>> In fact, PKCS11 tests have their own doc at: >>>>> test/jdk/sun/security/pkcs11/README >>>> I'm afraid most people wouldn't see >>>> test/jdk/sun/security/pkcs11/README at all. >>>> So it makes very little sense to add the notes in it. >>>> I still prefer doc/testing.md. >>>> >>>> A reference to test/jdk/sun/security/pkcs11/README had been added >>>> in [1]. >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jia >>>> >>>> [1] http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ >>>> >>>> >>>> >> >> From matthias.baesken at sap.com Tue Sep 24 08:29:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 24 Sep 2019 08:29:52 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 References: Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ I adjusted the imports and now output a warning . Best regards, Matthias From: Baesken, Matthias Sent: Montag, 23. September 2019 16:07 To: Langer, Christoph ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let's see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph > Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it's a good idea to have more diagnostic output in case of failures in this test. But, given that there's an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn't good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it's not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Sep 24 12:21:40 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Sep 2019 08:21:40 -0400 Subject: [14] RFR 8228659: Record which Java methods are called by native codes in JGSS and JAAS In-Reply-To: <67DCF08E-2AC6-4D08-BEAB-9E7EA79BC54F@oracle.com> References: <624CB9FE-FD3C-42D0-A9C0-BB05BE5F44B3@oracle.com> <67DCF08E-2AC6-4D08-BEAB-9E7EA79BC54F@oracle.com> Message-ID: <192fdfb7-5917-182f-36ac-4450a322afec@oracle.com> Just a couple of minor comments: 1. For comments like this: // Warning: Used by NativeCreds.c and nativeccache.c I think not capitalizing "Used" would be better. Also, would "called by" be more appropriate? Result: // Warning: called by NativeCreds.c and nativeccache.c 2. Sometimes you end a comment with a period, and other times you don't: // Warning: The following 4 fields are used by Unix.c. I think removing the period reads better: // Warning: The following 4 fields are used by Unix.c On 8/19/19 10:35 AM, Weijun Wang wrote: > Ping again. > >> On Jul 26, 2019, at 11:24 PM, Weijun Wang wrote: >> >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8228659/webrev.00/ >> >> Most of the change is new comments on internal Java methods called by native code. I also take this chance to simply Ticket creation in nativeccache.c and NativeCreds.c. There is no need to call `new Ticket(new DerValue(byteArray))` which is identical to `new Ticket(byteArray)`. >> >> I added the label noreg-doc but does not feel really comfortable. There is no public document here. noreg-comment or noreg-clarification would be better, if they exists. Please advise. You have changed more than comments so noreg-doc is not appropriate. How about noreg-cleanup? --Sean From christoph.langer at sap.com Tue Sep 24 12:39:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 12:39:02 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: Message-ID: Hi Matthias, looks good to me. One minor style nit: You could close the else case in line 335 with "}" and then have just one throw e; after the whole if else block. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 24. September 2019 10:30 To: Langer, Christoph ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ I adjusted the imports and now output a warning . Best regards, Matthias From: Baesken, Matthias Sent: Montag, 23. September 2019 16:07 To: Langer, Christoph >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let's see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph > Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it's a good idea to have more diagnostic output in case of failures in this test. But, given that there's an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn't good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it's not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Sep 24 15:19:33 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Sep 2019 08:19:33 -0700 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Message-ID: Sure, will do. /Erik On 2019-09-23 20:57, Jia Huang wrote: > Hi Erik, > > Thank you for your review and valuable comments. > > Updated: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.01/ > ?- The reference to the pkcs11 README and the reviewers had been added. > > Please note the user in the patch. > Hope you wouldn't mind it. Thanks. > > Could you please sponsor it? > > Thanks a lot. > Best regards, > Jia > > ? 2019?09?23? 23:18, Erik Joelsson ??: >> I think this type of comment fits well in the top level test doc. It >> just provides basic instructions for setting up these tests so that >> they pass without going into too much detail. Perhaps a reference to >> the pkcs11 README for more details would be a good idea. >> >> Looks good to me. >> >> /Erik >> >> On 2019-09-23 05:54, sha.jiang at oracle.com wrote: >>> Hi Jia, >>> I think this isn't a general testing problem. >>> It may not worthy of highlighting this point in the JDK testing doc. >>> In fact, PKCS11 tests have their own doc at: >>> test/jdk/sun/security/pkcs11/README >>> >>> Best regards, >>> John Jiang >>> >>> On 2019/9/23 18:04, Jia Huang wrote: >>>> Hi all, >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231351 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8231351-huangjia/webrev.00/ >>>> >>>> sun/security/pkcs11/Secmod/AddTrustedCert.java failed on Ubuntu 18.04. >>>> According to the comments in JDK-8231338, it was caused by the >>>> improper NSS libs of the system. >>>> >>>> These failures are confusing and hard to diagnose. >>>> It might be better to add some notes for the pkcs11 tests. >>>> >>>> Thanks a lot. >>>> >>>> Best regards, >>>> Jia >>>> >>>> >>>> > > From sean.coffey at oracle.com Tue Sep 24 17:58:44 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 24 Sep 2019 10:58:44 -0700 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: References: Message-ID: <17f522d7-e99b-16f4-815d-f111e709a002@oracle.com> Looks fine Joe. regards, Sean. On 23/09/2019 17:15, Joe Darcy wrote: > Hello, > > Another module, another review request as part of making serial > warnings more robust: > > ??? JDK-8231368: Suppress warnings on non-serializable non-transient > instance fields in java.security.jgss > ??? http://cr.openjdk.java.net/~darcy/8231368.0/ > > (Related earlier review > https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) > > In this latest review, I included a comment in KRBError.java that its > writeObject method uses a different encoding scheme. > > Thanks, > > -Joe > From tianshi at amazon.com Tue Sep 24 19:36:34 2019 From: tianshi at amazon.com (Shi, Tianmin) Date: Tue, 24 Sep 2019 19:36:34 +0000 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Message-ID: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 24 21:15:20 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Sep 2019 14:15:20 -0700 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> Message-ID: <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: > Hi > Can someone help reviewing this fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 > > Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ > > Thank you, > > Tianmin Shi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 24 21:29:48 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Sep 2019 14:29:48 -0700 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: Message-ID: <688dd8e3-c0a3-8932-17d6-0820ccb8ac34@oracle.com> Hi Matthias, The output on line 324 may report inconsistent info - the provider in use may not be NSS but yet you put NSS version with provider name? Since you are updating the code here, how about re-org the code a bit and first check for whether NSS provider is used then do the various version-specific handling. Regards, Valerie On 9/24/2019 5:39 AM, Langer, Christoph wrote: > > Hi Matthias, > > looks good to me. > > One minor style nit: You could close the else case in line 335 with > ?}? and then have just one throw e; after the whole if else block. > > Best regards > > Christoph > > *From:*Baesken, Matthias > *Sent:* Dienstag, 24. September 2019 10:30 > *To:* Langer, Christoph ; > security-dev at openjdk.java.net > *Cc:* Zeller, Arno > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ > > I adjusted the imports and? now output a warning . > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Montag, 23. September 2019 16:07 > *To:* Langer, Christoph >; security-dev at openjdk.java.net > > *Cc:* Zeller, Arno > > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Christoph,?? I am okay ?with your suggestion to?? just? print? a? > message in ?case that? an? older nss lib? < 3.15 is found ; however?? > let?s? see what others think . > > (but for Solaris? we let the test pass when?? noticing? old nss > versions , so I thought? it might make some sense to behave on Linux > in the same way ) > > Best regards, Matthias > > *From:*Langer, Christoph > > *Sent:* Montag, 23. September 2019 15:53 > *To:* Baesken, Matthias >; security-dev at openjdk.java.net > > *Cc:* Zeller, Arno > > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Matthias, > > generally I agree that it?s a good idea to have more diagnostic output > in case of failures in this test. > > But, given that there?s an upgrade path even on our old Linux SLES > 11.3 system to a newer libnss that has a fix for the bug that we > observe, I suggest that the test should still fail with libnss 3.14. > So I suggest you only add the line > > System.out.println("Exception occured using " + p.getName() + " > version " + ver); > > and maybe a comment stating that libnss 3.14 on Linux isn?t good for > this test. > > BTW, if you want to clean up the testcase a bit, you might remove line > 36, import java.math.*; because it?s not needed. Or replace all the > imports with: > > import java.security.GeneralSecurityException; > > import java.security.Provider; > > import java.util.Arrays; > > import javax.crypto.Cipher; > > import javax.crypto.SecretKey; > > import javax.crypto.spec.GCMParameterSpec; > > import javax.crypto.spec.SecretKeySpec; > > Thanks > > Christoph > > *From:*Baesken, Matthias > > *Sent:* Montag, 23. September 2019 15:16 > *To:* security-dev at openjdk.java.net > *Cc:* Langer, Christoph >; Zeller, Arno > > *Subject:* RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hello,? please review? this small test related change . > > We? noticed that ?on our SLES (SuSE Linux) 11 ??test? machines, the test > > sun/security/pkcs11/Cipher/TestKATForGCM.java > > fails when older nss versions? are used on the system , especially > ?nss 3.14 . > > > The used package is named? ?mozilla-nss-3.14 . > Upgrading to newer versions (e.g. 3.20) ??makes the test succeed , so > it might be helpful > to add a check in the test like it is done already for old nss > versions on Solaris. > > (nss? 3.15 contains a couple? of? AES cipher with GCM ??related fixes, > those might be the ones needed to run the test successfully ). > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231357 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Sep 24 21:37:39 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 24 Sep 2019 21:37:39 +0000 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> Message-ID: Yes, I?ll sponsor. Though it looks ok to me, I?m not a security expert, so do we need another security reviewer? From: security-dev on behalf of Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 24 22:01:59 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Sep 2019 15:01:59 -0700 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> Message-ID: <11e399bb-cbf1-4969-f6e6-6c466040978d@oracle.com> I am the security reviewer that you need. One should be enough. ;) Valerie On 9/24/2019 2:37 PM, Hohensee, Paul wrote: > > Yes, I?ll sponsor. Though it looks ok to me, I?m not a security > expert, so do we need another security reviewer? > > *From: *security-dev on behalf > of Valerie Peng > *Organization: *Oracle Corporation > *Date: *Tuesday, September 24, 2019 at 2:17 PM > *To: *"security-dev at openjdk.java.net" > *Subject: *Re: RFR (XS) JDK-8231387 "java.security.Provider.getService > returns random result due to race condition with mutating methods in > the same class" > > Changes look fine. I suppose Paul will help sponsoring the fix as he > is listed as the RE for 8231387? > > Thanks, > Valerie > > On 9/24/2019 12:36 PM, Shi, Tianmin wrote: > > Hi > > Can someone help reviewing this fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 > > Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ > > Thank you, > > Tianmin Shi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Sep 25 00:49:53 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 25 Sep 2019 00:49:53 +0000 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: <11e399bb-cbf1-4969-f6e6-6c466040978d@oracle.com> References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> <11e399bb-cbf1-4969-f6e6-6c466040978d@oracle.com> Message-ID: Thank you, Valerie. :) The patch needs a test, however, so I added a slightly modified version of Tianmin?s reproducer. New webrev at http://cr.openjdk.java.net/~phh/8231387/webrev.01/ The test fails without the fix. From: Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 3:03 PM To: "Hohensee, Paul" , "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" I am the security reviewer that you need. One should be enough. ;) Valerie On 9/24/2019 2:37 PM, Hohensee, Paul wrote: Yes, I?ll sponsor. Though it looks ok to me, I?m not a security expert, so do we need another security reviewer? From: security-dev on behalf of Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi -------------- next part -------------- An HTML attachment was scrubbed... URL: From huangjia at loongson.cn Wed Sep 25 02:06:23 2019 From: huangjia at loongson.cn (Jia Huang) Date: Wed, 25 Sep 2019 10:06:23 +0800 Subject: RFR: 8231351: Add notes for PKCS11 tests in the test doc In-Reply-To: References: <446542f6-9aa0-6dc6-f327-5ce1eb077a5d@loongson.cn> <53bdb782-7337-5afb-f6d3-dc279383dccb@oracle.com> <701123fd-1fe4-7a25-619e-651a9dd7f415@loongson.cn> Message-ID: <8f6c88b2-d2e7-61c0-97ee-6688adb2a378@loongson.cn> Thanks Erik. ? 2019?09?24? 23:19, Erik Joelsson ??: > Sure, will do. > > /Erik From xuelei.fan at oracle.com Wed Sep 25 04:20:34 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Sep 2019 21:20:34 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: References: Message-ID: I looked at the latest webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.01/ Which is good to me. Thanks, Xuelei On 9/19/2019 5:46 PM, Valerie Peng wrote: > > I am not on the PKCS#11 committee and not sure about the plan. > As for which one is right, I am more inclined to the "spec is right" side which is also what NSS picked. > Comparing between spec and header, shouldn't the former get more eyeballs in terms of review? > The header file also has a deprecated structure CK_AES_GCM_PARAMS which contains both ulIvLen and ulIvBits fields. > As ulIvBits and ulIvLen are essentially same in terms of meaning except bytes vs bits. Having both just creates confusion and potential inconsistency and makes not much sense to me. > > Valerie > > ----- Original Message ----- > From: xuelei.fan at oracle.com > To: valerie.peng at oracle.com, security-dev at openjdk.java.net > Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada Pacific > Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" > > Will the inconsistency structure be continue? I was just wondering if > OpenHSM2/Solaris/NSS will fix the bug and use one structure in the > future, then we may not need to workaround the issue in the calling side. > > I had a quick look the PKCS#11 3.0 draft, there is no update of the > structure yet. > > Xuelei > > On 9/18/2019 6:01 PM, Valerie Peng wrote: >> Ping? >> >> Can someone help take a look? >> >> Thanks, >> >> Valerie >> >> On 8/15/2019 4:49 PM, Valerie Peng wrote: >>> >>> Anyone has time to help review this fix? PKCS#11 v2.40 has >>> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >>> (sec 2..12.3) has: >>> >>> typedef struct CK_GCM_PARAMS { >>> ??? CK_BYTE_PTR?????? pIv; >>> ??? CK_ULONG????????? ulIvLen; >>> ??? CK_BYTE_PTR?????? pAAD; >>> ??? CK_ULONG????????? ulAADLen; >>> ??? CK_ULONG????????? ulTagBits; >>> } CK_GCM_PARAMS; >>> >>> However, the header file pkcs11t.h has an extra "ulIvBits" field: >>> >>> typedef struct CK_GCM_PARAMS { >>> ??? CK_BYTE_PTR?????? pIv; >>> ??? CK_ULONG????????? ulIvLen; >>> *??? CK_ULONG????????? ulIvBits;* >>> ??? CK_BYTE_PTR?????? pAAD; >>> ??? CK_ULONG????????? ulAADLen; >>> ??? CK_ULONG????????? ulTagBits; >>> } CK_GCM_PARAMS; >>> >>> Some vendors such OpenHSM2 and Solaris go with the header file while >>> some vendor such as NSS go with the mech spec. Current SunPKCS11 >>> provider impl works with NSS but not with other vendors whose >>> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >>> results, OpenHSM2 and Solaris error out at init time when the >>> parameter length does not have their expected value. Thus, one way to >>> workaround this inconsistency is to re-try with a different structure >>> for AES GCM when the init failed. In addition, given the parameters >>> contains Iv and AAD which some vendor may use during subsequent >>> enc/dec operations, I changed to use the same model as RSASSA-PSS to >>> defer the freeing after the enc/dec operation is finished. Verified >>> the changes on Solaris 11.4 against existing GCM regression tests. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >>> >>> Thanks, >>> Valerie From valerie.peng at oracle.com Wed Sep 25 04:40:56 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Sep 2019 21:40:56 -0700 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> <11e399bb-cbf1-4969-f6e6-6c466040978d@oracle.com> Message-ID: <044f84d5-b4d8-093a-dadd-f5c08a77eb32@oracle.com> Great, the update looks good. Thanks, Valerie On 9/24/2019 5:49 PM, Hohensee, Paul wrote: > > Thank you, Valerie. :) > > The patch needs a test, however, so I added a slightly modified > version of Tianmin?s reproducer. New webrev at > > http://cr.openjdk.java.net/~phh/8231387/webrev.01/ > > The test fails without the fix. > > *From: *Valerie Peng > *Organization: *Oracle Corporation > *Date: *Tuesday, September 24, 2019 at 3:03 PM > *To: *"Hohensee, Paul" , > "security-dev at openjdk.java.net" > *Subject: *Re: RFR (XS) JDK-8231387 "java.security.Provider.getService > returns random result due to race condition with mutating methods in > the same class" > > I am the security reviewer that you need. One should be enough. ;) > > Valerie > > On 9/24/2019 2:37 PM, Hohensee, Paul wrote: > > Yes, I?ll sponsor. Though it looks ok to me, I?m not a security > expert, so do we need another security reviewer? > > *From: *security-dev > on behalf of > Valerie Peng > > *Organization: *Oracle Corporation > *Date: *Tuesday, September 24, 2019 at 2:17 PM > *To: *"security-dev at openjdk.java.net" > > > *Subject: *Re: RFR (XS) JDK-8231387 > "java.security.Provider.getService returns random result due to > race condition with mutating methods in the same class" > > Changes look fine. I suppose Paul will help sponsoring the fix as > he is listed as the RE for 8231387? > > Thanks, > Valerie > > On 9/24/2019 12:36 PM, Shi, Tianmin wrote: > > Hi > > Can someone help reviewing this fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 > > Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ > > Thank you, > > Tianmin Shi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Sep 25 04:45:42 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Sep 2019 21:45:42 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: References: Message-ID: <2acfd22a-7682-d7d8-a49d-516f0a064abd@oracle.com> Great, thanks for the review and feedback~ Valerie On 9/24/2019 9:20 PM, Xuelei Fan wrote: > I looked at the latest webrev: > ? http://cr.openjdk.java.net/~valeriep/8229243/webrev.01/ > > Which is good to me. > > Thanks, > Xuelei > > On 9/19/2019 5:46 PM, Valerie Peng wrote: >> >> I am not on the PKCS#11 committee and not sure about the plan. >> As for which one is right, I am more inclined to the "spec is right" >> side which is also what NSS picked. >> Comparing between spec and header, shouldn't the former get more >> eyeballs in terms of review? >> The header file also has a deprecated structure CK_AES_GCM_PARAMS >> which contains both ulIvLen and ulIvBits fields. >> As ulIvBits and ulIvLen are essentially same in terms of meaning >> except bytes vs bits. Having both just creates confusion and >> potential inconsistency and makes not much sense to me. >> >> Valerie >> >> ----- Original Message ----- >> From: xuelei.fan at oracle.com >> To: valerie.peng at oracle.com, security-dev at openjdk.java.net >> Sent: Thursday, September 19, 2019 7:47:43 AM GMT -08:00 US/Canada >> Pacific >> Subject: Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests >> failing on Solaris 11.4" >> >> Will the inconsistency structure be continue?? I was just wondering if >> OpenHSM2/Solaris/NSS will fix the bug and use one structure in the >> future, then we may not need to workaround the issue in the calling >> side. >> >> I had a quick look the PKCS#11 3.0 draft, there is no update of the >> structure yet. >> >> Xuelei >> >> On 9/18/2019 6:01 PM, Valerie Peng wrote: >>> Ping? >>> >>> Can someone help take a look? >>> >>> Thanks, >>> >>> Valerie >>> >>> On 8/15/2019 4:49 PM, Valerie Peng wrote: >>>> >>>> Anyone has time to help review this fix? PKCS#11 v2.40 has >>>> inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec >>>> (sec 2..12.3) has: >>>> >>>> ???? typedef struct CK_GCM_PARAMS { >>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>> ???? ??? CK_ULONG????????? ulIvLen; >>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>> ???? ??? CK_ULONG????????? ulAADLen; >>>> ???? ??? CK_ULONG????????? ulTagBits; >>>> ???? } CK_GCM_PARAMS; >>>> >>>> However, the header file pkcs11t.h has an extra "ulIvBits" field: >>>> >>>> ???? typedef struct CK_GCM_PARAMS { >>>> ???? ??? CK_BYTE_PTR?????? pIv; >>>> ???? ??? CK_ULONG????????? ulIvLen; >>>> ???? *??? CK_ULONG????????? ulIvBits;* >>>> ???? ??? CK_BYTE_PTR?????? pAAD; >>>> ???? ??? CK_ULONG????????? ulAADLen; >>>> ???? ??? CK_ULONG????????? ulTagBits; >>>> ???? } CK_GCM_PARAMS; >>>> >>>> Some vendors such OpenHSM2 and Solaris go with the header file while >>>> some vendor such as NSS go with the mech spec. Current SunPKCS11 >>>> provider impl works with NSS but not with other vendors whose >>>> CK_GCM_PARAMS struct contains ulIvBits field. Based on testing >>>> results, OpenHSM2 and Solaris error out at init time when the >>>> parameter length does not have their expected value. Thus, one way to >>>> workaround this inconsistency is to re-try with a different structure >>>> for AES GCM when the init failed. In addition, given the parameters >>>> contains Iv and AAD which some vendor may use during subsequent >>>> enc/dec operations, I changed to use the same model as RSASSA-PSS to >>>> defer the freeing after the enc/dec operation is finished. Verified >>>> the changes on Solaris 11.4 against existing GCM regression tests. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From weijun.wang at oracle.com Wed Sep 25 09:55:39 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 25 Sep 2019 17:55:39 +0800 Subject: [14] RFR 8228659: Record which Java methods are called by native codes in JGSS and JAAS In-Reply-To: <192fdfb7-5917-182f-36ac-4450a322afec@oracle.com> References: <624CB9FE-FD3C-42D0-A9C0-BB05BE5F44B3@oracle.com> <67DCF08E-2AC6-4D08-BEAB-9E7EA79BC54F@oracle.com> <192fdfb7-5917-182f-36ac-4450a322afec@oracle.com> Message-ID: <05B1FACB-CAC0-4E31-BCF9-00F39DDB5456@oracle.com> I've changed all method calls to "called by" and keep field references as "used by". I also removed the periods. Pushed to https://hg.openjdk.java.net/jdk/jdk/rev/e4ce29f6094e. Thanks, Max > On Sep 24, 2019, at 8:21 PM, Sean Mullan wrote: > > Just a couple of minor comments: > > 1. For comments like this: > > // Warning: Used by NativeCreds.c and nativeccache.c > > I think not capitalizing "Used" would be better. Also, would "called by" be more appropriate? Result: > > // Warning: called by NativeCreds.c and nativeccache.c > > 2. Sometimes you end a comment with a period, and other times you don't: > > // Warning: The following 4 fields are used by Unix.c. > > I think removing the period reads better: > > // Warning: The following 4 fields are used by Unix.c > > > On 8/19/19 10:35 AM, Weijun Wang wrote: >> Ping again. >>> On Jul 26, 2019, at 11:24 PM, Weijun Wang wrote: >>> >>> Please review the change at >>> >>> http://cr.openjdk.java.net/~weijun/8228659/webrev.00/ >>> >>> Most of the change is new comments on internal Java methods called by native code. I also take this chance to simply Ticket creation in nativeccache.c and NativeCreds.c. There is no need to call `new Ticket(new DerValue(byteArray))` which is identical to `new Ticket(byteArray)`. >>> >>> I added the label noreg-doc but does not feel really comfortable. There is no public document here. noreg-comment or noreg-clarification would be better, if they exists. Please advise. > > You have changed more than comments so noreg-doc is not appropriate. How about noreg-cleanup? > > --Sean From matthias.baesken at sap.com Wed Sep 25 14:34:23 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 25 Sep 2019 14:34:23 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: <688dd8e3-c0a3-8932-17d6-0820ccb8ac34@oracle.com> Message-ID: Hi Valerie / Christoph , New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.2/ * Followed the idea of Christoph : "One minor style nit: You could close the else case in line 335 with "}" and then have just one throw e;" * Moved the isNSS(Provider) check in front of the version checking and potential output Best regards, Matthias Hi Matthias, The output on line 324 may report inconsistent info - the provider in use may not be NSS but yet you put NSS version with provider name? Since you are updating the code here, how about re-org the code a bit and first check for whether NSS provider is used then do the various version-specific handling. Regards, Valerie On 9/24/2019 5:39 AM, Langer, Christoph wrote: Hi Matthias, looks good to me. One minor style nit: You could close the else case in line 335 with "}" and then have just one throw e; after the whole if else block. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 24. September 2019 10:30 To: Langer, Christoph ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ I adjusted the imports and now output a warning . Best regards, Matthias From: Baesken, Matthias Sent: Montag, 23. September 2019 16:07 To: Langer, Christoph >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let's see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph > Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it's a good idea to have more diagnostic output in case of failures in this test. But, given that there's an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn't good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it's not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Sep 25 14:49:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 14:49:36 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: <688dd8e3-c0a3-8932-17d6-0820ccb8ac34@oracle.com> Message-ID: Hi Matthias, looks good. One minor thing I just recognized: java.security.Provider::getVersion() is deprecated. Can you please use p.getVersionStr in line 323? But no need to see another webrev ?? Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 25. September 2019 16:34 To: Valerie Peng ; security-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: Re: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Valerie / Christoph , New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.2/ * Followed the idea of Christoph : ?One minor style nit: You could close the else case in line 335 with ?}? and then have just one throw e;? * Moved the isNSS(Provider) check in front of the version checking and potential output Best regards, Matthias Hi Matthias, The output on line 324 may report inconsistent info - the provider in use may not be NSS but yet you put NSS version with provider name? Since you are updating the code here, how about re-org the code a bit and first check for whether NSS provider is used then do the various version-specific handling. Regards, Valerie On 9/24/2019 5:39 AM, Langer, Christoph wrote: Hi Matthias, looks good to me. One minor style nit: You could close the else case in line 335 with ?}? and then have just one throw e; after the whole if else block. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 24. September 2019 10:30 To: Langer, Christoph ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ I adjusted the imports and now output a warning . Best regards, Matthias From: Baesken, Matthias Sent: Montag, 23. September 2019 16:07 To: Langer, Christoph >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let?s see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph > Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it?s a good idea to have more diagnostic output in case of failures in this test. But, given that there?s an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn?t good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it?s not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Sep 25 14:59:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Sep 2019 15:59:32 +0100 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> Message-ID: <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> On 02/09/2019 16:05, Severin Gehwolf wrote: > On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: >> >> On 26/08/2019 14:24, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I get a review of this follow-up fix for an 8u backport (JDK- >>> 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc >>> library header files removed by the JDK-8218780 backport. The patch >>> differs from the version in JDK 11 since there is no pcsclite.md file >>> in OpenJDK 8u. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ >>> JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 >>> >>> I intend to push this fix together with JDK-8218780 once it passed >>> review and got approved. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >>> >>> >>> >> >> The *.md files in OpenJDK 9+ are the modular equivalent of the >> THIRD_PARTY_README file found in each OpenJDK 8u repository. See my >> review of JDK-8217676 [0] for Zhengyu for more details. >> >> For reference, the conversion took place in JDK-8169925. > > Thanks for this. Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ > > I intend to push the same updat to > THIRD_PARTY_README files on all other repos. Example here is jdk repo. > Do you want to see webrevs of this THIRD_PARTY_README update for all 7 > other repos? > > Thanks, > Severin > >> [0] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html >> [1] https://bugs.openjdk.java.net/browse/JDK-8169925 > I'm happy assuming the same THIRD_PARTY_README change for all repos. This looks fine to me. Can you flag it jdk8u-critical-request so we can get this into 8u232 with JDK-8218780? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From hohensee at amazon.com Wed Sep 25 15:30:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 25 Sep 2019 15:30:07 +0000 Subject: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" In-Reply-To: <044f84d5-b4d8-093a-dadd-f5c08a77eb32@oracle.com> References: <8AD762D2-521D-45CE-A635-A8125B3F2E7A@amazon.com> <92de4a8c-a7ea-52da-b624-e5298b6b605d@oracle.com> <11e399bb-cbf1-4969-f6e6-6c466040978d@oracle.com> <044f84d5-b4d8-093a-dadd-f5c08a77eb32@oracle.com> Message-ID: Thanks, Valerie. Pushed. From: Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 9:42 PM To: "Hohensee, Paul" , "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Great, the update looks good. Thanks, Valerie On 9/24/2019 5:49 PM, Hohensee, Paul wrote: Thank you, Valerie. :) The patch needs a test, however, so I added a slightly modified version of Tianmin?s reproducer. New webrev at http://cr.openjdk.java.net/~phh/8231387/webrev.01/ The test fails without the fix. From: Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 3:03 PM To: "Hohensee, Paul" , "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" I am the security reviewer that you need. One should be enough. ;) Valerie On 9/24/2019 2:37 PM, Hohensee, Paul wrote: Yes, I?ll sponsor. Though it looks ok to me, I?m not a security expert, so do we need another security reviewer? From: security-dev on behalf of Valerie Peng Organization: Oracle Corporation Date: Tuesday, September 24, 2019 at 2:17 PM To: "security-dev at openjdk.java.net" Subject: Re: RFR (XS) JDK-8231387 "java.security.Provider.getService returns random result due to race condition with mutating methods in the same class" Changes look fine. I suppose Paul will help sponsoring the fix as he is listed as the RE for 8231387? Thanks, Valerie On 9/24/2019 12:36 PM, Shi, Tianmin wrote: Hi Can someone help reviewing this fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8231387 Webrev: http://cr.openjdk.java.net/~phh/8231387/webrev.00/ Thank you, Tianmin Shi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Wed Sep 25 15:49:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 25 Sep 2019 17:49:33 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers In-Reply-To: <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> References: <846dd0f7-c132-e2a9-b9d4-343a0524f784@redhat.com> <74e204af-a8f9-c450-b386-c2ea6cebe68d@redhat.com> Message-ID: <18ba0f7b13c979efb93791af018e3ec57e7fe56d.camel@redhat.com> On Wed, 2019-09-25 at 15:59 +0100, Andrew John Hughes wrote: > On 02/09/2019 16:05, Severin Gehwolf wrote: > > On Mon, 2019-09-02 at 15:38 +0100, Andrew John Hughes wrote: > > > On 26/08/2019 14:24, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I get a review of this follow-up fix for an 8u backport (JDK- > > > > 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc > > > > library header files removed by the JDK-8218780 backport. The patch > > > > differs from the version in JDK 11 since there is no pcsclite.md file > > > > in OpenJDK 8u. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ > > > > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 > > > > > > > > I intend to push this fix together with JDK-8218780 once it passed > > > > review and got approved. > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > > > > > > > The *.md files in OpenJDK 9+ are the modular equivalent of the > > > THIRD_PARTY_README file found in each OpenJDK 8u repository. See my > > > review of JDK-8217676 [0] for Zhengyu for more details. > > > > > > For reference, the conversion took place in JDK-8169925. > > > > Thanks for this. Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/02/webrev/ > > > > I intend to push the same updat to > > THIRD_PARTY_README files on all other repos. Example here is jdk repo. > > Do you want to see webrevs of this THIRD_PARTY_README update for all 7 > > other repos? > > > > Thanks, > > Severin > > > > > [0] > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/010116.html > > > [1] https://bugs.openjdk.java.net/browse/JDK-8169925 > > I'm happy assuming the same THIRD_PARTY_README change for all repos. > > This looks fine to me. Thanks for the review! > Can you flag it jdk8u-critical-request so we can > get this into 8u232 with JDK-8218780? Done. Thanks, Severin From sean.mullan at oracle.com Wed Sep 25 18:51:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 25 Sep 2019 14:51:47 -0400 Subject: AccessController.getInheritedAccessControlContext, does it need to call through the VM In-Reply-To: References: Message-ID: <27b0c8e2-0951-439d-52ea-1bcd6c324347@oracle.com> On 9/20/19 12:29 PM, Alan Bateman wrote: > > Is there any reason for > AccessController.getInheritedAccessControlContext to be a native method? No, I don't believe so. > I'm wondering if we can use the shared secrets mechanism to read the > Thread.inheritedAccessControlContext field instead. Yes, that should work. --Sean From weijun.wang at oracle.com Thu Sep 26 02:50:08 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Sep 2019 10:50:08 +0800 Subject: RFR 8231365, 8231196: bugs on kerberos permissions Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8231365/webrev.00 Thanks, Max From matthias.baesken at sap.com Thu Sep 26 09:30:33 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 26 Sep 2019 09:30:33 +0000 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: <688dd8e3-c0a3-8932-17d6-0820ccb8ac34@oracle.com> Message-ID: Hi Christoph, you are right - I should better use getVersionStr() , I?ll replace it . Valerie are you fine with the latest webrev ? Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 25. September 2019 16:50 To: Baesken, Matthias ; Valerie Peng ; security-dev at openjdk.java.net Subject: RE: Re: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, looks good. One minor thing I just recognized: java.security.Provider::getVersion() is deprecated. Can you please use p.getVersionStr in line 323? But no need to see another webrev ?? Best regards Christoph From: Baesken, Matthias > Sent: Mittwoch, 25. September 2019 16:34 To: Valerie Peng >; security-dev at openjdk.java.net Cc: Langer, Christoph > Subject: RE: Re: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Valerie / Christoph , New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.2/ * Followed the idea of Christoph : ?One minor style nit: You could close the else case in line 335 with ?}? and then have just one throw e;? * Moved the isNSS(Provider) check in front of the version checking and potential output Best regards, Matthias Hi Matthias, The output on line 324 may report inconsistent info - the provider in use may not be NSS but yet you put NSS version with provider name? Since you are updating the code here, how about re-org the code a bit and first check for whether NSS provider is used then do the various version-specific handling. Regards, Valerie On 9/24/2019 5:39 AM, Langer, Christoph wrote: Hi Matthias, looks good to me. One minor style nit: You could close the else case in line 335 with ?}? and then have just one throw e; after the whole if else block. Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 24. September 2019 10:30 To: Langer, Christoph ; security-dev at openjdk.java.net Cc: Zeller, Arno Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ I adjusted the imports and now output a warning . Best regards, Matthias From: Baesken, Matthias Sent: Montag, 23. September 2019 16:07 To: Langer, Christoph >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Christoph, I am okay with your suggestion to just print a message in case that an older nss lib < 3.15 is found ; however let?s see what others think . (but for Solaris we let the test pass when noticing old nss versions , so I thought it might make some sense to behave on Linux in the same way ) Best regards, Matthias From: Langer, Christoph > Sent: Montag, 23. September 2019 15:53 To: Baesken, Matthias >; security-dev at openjdk.java.net Cc: Zeller, Arno > Subject: RE: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hi Matthias, generally I agree that it?s a good idea to have more diagnostic output in case of failures in this test. But, given that there?s an upgrade path even on our old Linux SLES 11.3 system to a newer libnss that has a fix for the bug that we observe, I suggest that the test should still fail with libnss 3.14. So I suggest you only add the line System.out.println("Exception occured using " + p.getName() + " version " + ver); and maybe a comment stating that libnss 3.14 on Linux isn?t good for this test. BTW, if you want to clean up the testcase a bit, you might remove line 36, import java.math.*; because it?s not needed. Or replace all the imports with: import java.security.GeneralSecurityException; import java.security.Provider; import java.util.Arrays; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; Thanks Christoph From: Baesken, Matthias > Sent: Montag, 23. September 2019 15:16 To: security-dev at openjdk.java.net Cc: Langer, Christoph >; Zeller, Arno > Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 Hello, please review this small test related change . We noticed that on our SLES (SuSE Linux) 11 test machines, the test sun/security/pkcs11/Cipher/TestKATForGCM.java fails when older nss versions are used on the system , especially nss 3.14 . The used package is named mozilla-nss-3.14 . Upgrading to newer versions (e.g. 3.20) makes the test succeed , so it might be helpful to add a check in the test like it is done already for old nss versions on Solaris. (nss 3.15 contains a couple of AES cipher with GCM related fixes, those might be the ones needed to run the test successfully ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8231357 http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Sep 26 19:35:58 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Sep 2019 15:35:58 -0400 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: References: Message-ID: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> - Krb5Context.java 1394 @SuppressWarnings("serial") // Not statically typed as Serializable 1395 private final EncryptionKey key; EncryptionKey is Serializable (it derives from java.security.Key which is Serializable). I was wondering why we needed to suppress the warning here. --Sean On 9/23/19 8:15 PM, Joe Darcy wrote: > Hello, > > Another module, another review request as part of making serial warnings > more robust: > > ??? JDK-8231368: Suppress warnings on non-serializable non-transient > instance fields in java.security.jgss > ??? http://cr.openjdk.java.net/~darcy/8231368.0/ > > (Related earlier review > https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) > > > In this latest review, I included a comment in KRBError.java that its > writeObject method uses a different encoding scheme. > > Thanks, > > -Joe > From Roger.Riggs at oracle.com Thu Sep 26 19:41:17 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 26 Sep 2019 15:41:17 -0400 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> Message-ID: Sean, I think that's the other EncryptionKey. The one in src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java isn't. Roger On 9/26/19 3:35 PM, Sean Mullan wrote: > - Krb5Context.java > > 1394???????? @SuppressWarnings("serial") // Not statically typed as > Serializable > 1395???????? private final EncryptionKey key; > > EncryptionKey is Serializable (it derives from java.security.Key which > is Serializable). I was wondering why we needed to suppress the > warning here. > > --Sean > > On 9/23/19 8:15 PM, Joe Darcy wrote: >> Hello, >> >> Another module, another review request as part of making serial >> warnings more robust: >> >> ???? JDK-8231368: Suppress warnings on non-serializable non-transient >> instance fields in java.security.jgss >> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >> >> (Related earlier review >> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >> >> >> In this latest review, I included a comment in KRBError.java that its >> writeObject method uses a different encoding scheme. >> >> Thanks, >> >> -Joe >> From sean.mullan at oracle.com Thu Sep 26 19:46:13 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Sep 2019 15:46:13 -0400 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> Message-ID: On 9/23/19 4:16 PM, Joe Darcy wrote: > Hi Sean, > > On 9/23/2019 12:19 PM, Sean Mullan wrote: >> Hi Joe, >> >> It's a little odd to suppress the warnings in the X509CertImpl class >> since it is a subclass of java.security.cert.Certificate which >> implements the writeReplace method so these fields are not serialized. >> >> Also for other classes like X509Key which are internal it is a little >> odd to suppress the warnings for fields like bitStringKey that are not >> Serializable and are never serialized. It is probably better to mark >> them as transient, but I'm not really sure it is worth making those >> changes for otherwise stable code. I guess when I look at some of the >> warnings, I might think there is an issue when there really isn't. >> >> I suppose these are not things you can easily detect at compile time, >> but I am wondering what you think. >> >> > Thanks for the feedback. One motivation to send out these review is to > help tune-up the warning analysis. > > A brief philosophical note, when designing any sort of warning scheme > the cost of false positives vs false negatives needs to be weighed as > any static check can likely only approximate the full range of dynamic > behavior. The checks as written give up, i.e. do not attempt to analyze > and warn, if the class uses serialPersistentFields. It would be possible > for the checks to similarly decline to analyze if any of the various > write* or read* serialization methods are defined. My current impression > is that the net benefit for the checks when write* methods are defined > is still worthwhile, even though there are some false positives. > > As you observe, given the handling of the serial methods, bitStringKey > in X509Key is effectively transient. I think it would be better serial > coding for the field to be explicitly marked as transient to make it > more obviously consistent with the implementation. Moreover, all the > instance fields in X509Key except encodedKey look to be effectively > transient. Since the class already has a serialVersionUID, marking the > fields as transient is a serial-compatible change. Ok. Well I understand that the benefit here is to try to detect serialization issues, and that is great. But at least in some cases like in security libs where classes are doing their own alternate serialization and have more than a few fields, the workaround of leaving the warnings in or having to mark all the fields as transient - either approach is not ideal to me. Could the SuppressWarnings("serial") annotation be applied at the class level so that it basically said "I know what I'm doing here, don't warn me about serialization issues"? --Sean From sean.mullan at oracle.com Thu Sep 26 19:51:56 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Sep 2019 15:51:56 -0400 Subject: JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss In-Reply-To: References: <2aba8d6c-90f9-96d4-1be5-6765459e9929@oracle.com> Message-ID: On 9/26/19 3:41 PM, Roger Riggs wrote: > Sean, > > I think that's the other EncryptionKey. > The one in > src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java isn't. Right you are! Ok, never mind about my comment. --Sean > > > Roger > > > On 9/26/19 3:35 PM, Sean Mullan wrote: >> - Krb5Context.java >> >> 1394???????? @SuppressWarnings("serial") // Not statically typed as >> Serializable >> 1395???????? private final EncryptionKey key; >> >> EncryptionKey is Serializable (it derives from java.security.Key which >> is Serializable). I was wondering why we needed to suppress the >> warning here. >> >> --Sean >> >> On 9/23/19 8:15 PM, Joe Darcy wrote: >>> Hello, >>> >>> Another module, another review request as part of making serial >>> warnings more robust: >>> >>> ???? JDK-8231368: Suppress warnings on non-serializable non-transient >>> instance fields in java.security.jgss >>> ???? http://cr.openjdk.java.net/~darcy/8231368.0/ >>> >>> (Related earlier review >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) >>> >>> >>> In this latest review, I included a comment in KRBError.java that its >>> writeObject method uses a different encoding scheme. >>> >>> Thanks, >>> >>> -Joe >>> > From joe.darcy at oracle.com Thu Sep 26 20:10:07 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 26 Sep 2019 13:10:07 -0700 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> Message-ID: <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> Hi Sean, On 9/26/2019 12:46 PM, Sean Mullan wrote: > On 9/23/19 4:16 PM, Joe Darcy wrote: >> Hi Sean, >> >> On 9/23/2019 12:19 PM, Sean Mullan wrote: >>> Hi Joe, >>> >>> It's a little odd to suppress the warnings in the X509CertImpl class >>> since it is a subclass of java.security.cert.Certificate which >>> implements the writeReplace method so these fields are not serialized. >>> >>> Also for other classes like X509Key which are internal it is a >>> little odd to suppress the warnings for fields like bitStringKey >>> that are not Serializable and are never serialized. It is probably >>> better to mark them as transient, but I'm not really sure it is >>> worth making those changes for otherwise stable code. I guess when I >>> look at some of the warnings, I might think there is an issue when >>> there really isn't. >>> >>> I suppose these are not things you can easily detect at compile >>> time, but I am wondering what you think. >>> >>> >> Thanks for the feedback. One motivation to send out these review is >> to help tune-up the warning analysis. >> >> A brief philosophical note, when designing any sort of warning scheme >> the cost of false positives vs false negatives needs to be weighed as >> any static check can likely only approximate the full range of >> dynamic behavior. The checks as written give up, i.e. do not attempt >> to analyze and warn, if the class uses serialPersistentFields. It >> would be possible for the checks to similarly decline to analyze if >> any of the various write* or read* serialization methods are defined. >> My current impression is that the net benefit for the checks when >> write* methods are defined is still worthwhile, even though there are >> some false positives. >> >> As you observe, given the handling of the serial methods, >> bitStringKey in X509Key is effectively transient. I think it would be >> better serial coding for the field to be explicitly marked as >> transient to make it more obviously consistent with the >> implementation. Moreover, all the instance fields in X509Key except >> encodedKey look to be effectively transient. Since the class already >> has a serialVersionUID, marking the fields as transient is a >> serial-compatible change. > > Ok. Well I understand that the benefit here is to try to detect > serialization issues, and that is great. But at least in some cases > like in security libs where classes are doing their own alternate > serialization and have more than a few fields, the workaround of > leaving the warnings in or having to mark all the fields as transient > - either approach is not ideal to me. Could the > SuppressWarnings("serial") annotation be applied at the class level so > that it basically said "I know what I'm doing here, don't warn me > about serialization issues"? Yes; applying SuppressWarnings("serial") to the class will silence this new warning for all the fields. I didn't take that approach in the version I sent to review since, by default, I wanted to provide the narrowest scope of the suppression. Would you prefer I revise the patch where there are multiple SuppressWarnings("serial") on fields to put a single one on the class instead? Cheers, -Joe From sean.mullan at oracle.com Thu Sep 26 20:20:42 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Sep 2019 16:20:42 -0400 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> Message-ID: <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> On 9/26/19 4:10 PM, Joe Darcy wrote: > Hi Sean, > > On 9/26/2019 12:46 PM, Sean Mullan wrote: >> On 9/23/19 4:16 PM, Joe Darcy wrote: >>> Hi Sean, >>> >>> On 9/23/2019 12:19 PM, Sean Mullan wrote: >>>> Hi Joe, >>>> >>>> It's a little odd to suppress the warnings in the X509CertImpl class >>>> since it is a subclass of java.security.cert.Certificate which >>>> implements the writeReplace method so these fields are not serialized. >>>> >>>> Also for other classes like X509Key which are internal it is a >>>> little odd to suppress the warnings for fields like bitStringKey >>>> that are not Serializable and are never serialized. It is probably >>>> better to mark them as transient, but I'm not really sure it is >>>> worth making those changes for otherwise stable code. I guess when I >>>> look at some of the warnings, I might think there is an issue when >>>> there really isn't. >>>> >>>> I suppose these are not things you can easily detect at compile >>>> time, but I am wondering what you think. >>>> >>>> >>> Thanks for the feedback. One motivation to send out these review is >>> to help tune-up the warning analysis. >>> >>> A brief philosophical note, when designing any sort of warning scheme >>> the cost of false positives vs false negatives needs to be weighed as >>> any static check can likely only approximate the full range of >>> dynamic behavior. The checks as written give up, i.e. do not attempt >>> to analyze and warn, if the class uses serialPersistentFields. It >>> would be possible for the checks to similarly decline to analyze if >>> any of the various write* or read* serialization methods are defined. >>> My current impression is that the net benefit for the checks when >>> write* methods are defined is still worthwhile, even though there are >>> some false positives. >>> >>> As you observe, given the handling of the serial methods, >>> bitStringKey in X509Key is effectively transient. I think it would be >>> better serial coding for the field to be explicitly marked as >>> transient to make it more obviously consistent with the >>> implementation. Moreover, all the instance fields in X509Key except >>> encodedKey look to be effectively transient. Since the class already >>> has a serialVersionUID, marking the fields as transient is a >>> serial-compatible change. >> >> Ok. Well I understand that the benefit here is to try to detect >> serialization issues, and that is great. But at least in some cases >> like in security libs where classes are doing their own alternate >> serialization and have more than a few fields, the workaround of >> leaving the warnings in or having to mark all the fields as transient >> - either approach is not ideal to me. Could the >> SuppressWarnings("serial") annotation be applied at the class level so >> that it basically said "I know what I'm doing here, don't warn me >> about serialization issues"? > > Yes; applying SuppressWarnings("serial") to the class will silence this > new warning for all the fields. I didn't take that approach in the > version I sent to review since, by default, I wanted to provide the > narrowest scope of the suppression. > > Would you prefer I revise the patch where there are multiple > SuppressWarnings("serial") on fields to put a single one on the class > instead? Yes, but only in the cases where we are clearly using some form of alternate serialization like ASN.1 encoding. I need to double-check the review again (it's a bit more time consuming because I have to look at the code in more detail), but the two that I spotted so far are: src/java.base/share/classes/sun/security/x509/X509CertImpl.java src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java (from the JDK-8231368 review) --Sean From sean.mullan at oracle.com Thu Sep 26 20:55:30 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Sep 2019 16:55:30 -0400 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> <6b2e97ed-7865-05a2-622f-40dcf2a0602c@oracle.com> Message-ID: <3fb58edd-9095-ee2d-5b64-3a92640a1cdc@oracle.com> On 9/26/19 4:20 PM, Sean Mullan wrote: >> Would you prefer I revise the patch where there are multiple >> SuppressWarnings("serial") on fields to put a single one on the class >> instead? > > Yes, but only in the cases where we are clearly using some form of > alternate serialization like ASN.1 encoding. I need to double-check the > review again (it's a bit more time consuming because I have to look at > the code in more detail), but the two that I spotted so far are: > > src/java.base/share/classes/sun/security/x509/X509CertImpl.java > src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java > (from the JDK-8231368 review) Ok, I double-checked everything. The only other class in the webrev that uses an alternate serial form is: sun/security/x509/X509Key.java but since that only has one field that is not Serializable, it probably is ok to leave as-is. --Sean From michael.osipov at siemens.com Fri Sep 27 08:28:49 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Fri, 27 Sep 2019 10:28:49 +0200 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support Message-ID: Hi folks, apologies upfront that I wasn't able when Martin Balao asked for a review of the code. I finally made to test it and cannot see that it is working anyhow here. I won't dive into my usecase now, but will depict two simple cases which are not possible. All tests were performed with Oracle JDK 13 on Windows 7: > java version "13" 2019-09-17 > Java(TM) SE Runtime Environment (build 13+33) > Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) 1. kinit (JDK bundled) does not work. It does neither provide an '-E' option, nor does it send NT-ENTERPRISE, but only NT-UNKNOWN: > 0000 30 25 a0 03 02 01 00 a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic > 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem > 0020 65 6e 73 2e 63 6f 6d ens.com In byte 0x06 is the name type NT-UNKNOWN (0). In contrast to this with MIT Kerberos 1.17 and 'kinit -E' I see in Wireshark: > 0000 30 25 a0 03 02 01 0a a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic > 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem > 0020 65 6e 73 2e 63 6f 6d ens.com byte 0x06 is now name type NT-ENTERPRISE-PRINCIPAL (10). Trying the very same with LSA on Windows with "run as user" I get for my implicit UPN osipovmi at AD001.SIEMENS.NET always type 10. It only uses NT-PRINCIPAL when I provide the local part (samAccountName). 2. Using the appropriate OID for the enterprise principal: > public static void main(String[] args) throws GSSException { > > GSSManager m = GSSManager.getInstance(); > > Oid msUpnOid = new Oid("1.3.6.1.4.1.311.20.2.3"); > Oid krb5PrincipalOid = new Oid("1.2.840.113554.1.2.2.1"); > Oid krb5EnterprisePrincialOid = new Oid("1.2.840.113554.1.2.2.6"); > > Oid krb5MechOid = new Oid("1.2.840.113554.1.2.2"); > > GSSName upn = m.createName("michael.osipov at siemens.com", krb5EnterprisePrincialOid); > > } gives me: > Exception in thread "main" GSSException: Name of unsupported type provided (Mechanism level: 1.2.840.113554.1.2.2.6 is an unsupported nametype) > at java.security.jgss/sun.security.jgss.krb5.Krb5NameElement.getInstance(Krb5NameElement.java:87) > at java.security.jgss/sun.security.jgss.krb5.Krb5MechFactory.getNameElement(Krb5MechFactory.java:99) > at java.security.jgss/sun.security.jgss.GSSManagerImpl.getNameElement(GSSManagerImpl.java:184) > at java.security.jgss/sun.security.jgss.GSSNameImpl.getElement(GSSNameImpl.java:478) > at java.security.jgss/sun.security.jgss.GSSNameImpl.init(GSSNameImpl.java:201) > at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:170) > at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:151) > at java.security.jgss/sun.security.jgss.GSSManagerImpl.createName(GSSManagerImpl.java:109) > at com.siemens.dynamowerk.Main.main(Main.java:20) and yes, the OID has never been defined in that class [1], but is present in MIT Kerberos [2]. I haven't tried a programmatical kinit, but as mentioned in the notes [3], Krb5LoginModule does not support it, so I don't even have to try. Any ideas? Beside that, it'd be very cool if this gets into 11u or better yet to 8u. I have talked with Weijun about this several times many years ago for Java 7+. I have no option to use anything else, but Java 8 for now. If someone wants to know better about my usecase, I'd be happy to lay it out in detail. I do need at least krb5EnterprisePrincialOid and better msUpnOid for my usecase. The only option I see now is to write a delegating wrapper for this: > GSSName upn = m.createName("michael.osipov at siemens.com", krb5PrincipalOid); > > GSSName wrappedUpn = new WrappedGSSName(upn, krb5EnterprisePrincialOid); > > System.out.println(wrappedUpn); > System.out.println(wrappedUpn.getStringNameType()); > michael.osipov at siemens.com > 1.2.840.113554.1.2.2.6 Michael [1] https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/bb0786d980437800b9d6efe17e42d18241714ea1/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java#L51-L61 [2] https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018952.html From chris.hegarty at oracle.com Fri Sep 27 12:59:18 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 Sep 2019 13:59:18 +0100 Subject: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes In-Reply-To: <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> References: <1cce2ac6-cfa1-6859-aa24-4051aeece1aa@oracle.com> <4ec1729b-6625-4aef-8fb2-03adc9536431@oracle.com> Message-ID: On 26/09/2019 21:10, Joe Darcy wrote: > .. > > Yes; applying SuppressWarnings("serial") to the class will silence this > new warning for all the fields. Will is also suppress other warnings, like on the serialization-related magic methods? Which would be unfortunate. -Chris. From sean.mullan at oracle.com Fri Sep 27 14:20:03 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 27 Sep 2019 10:20:03 -0400 Subject: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection In-Reply-To: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> References: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> Message-ID: Hi Ivan, The fix looks good. Good catch. --Sean On 8/30/19 7:32 PM, Ivan Gerasimov wrote: > Hello! > > In the two implementations of PermissionCollection.implies(Permission), > all the permissions are traversed, and their corresponding bit mask are > checked. > > For example, here's a snippet from FilePermission.java: > > ??????? int desired = fperm.getMask(); > ??????? int effective = 0; > ??????? int needed = desired; > > ??????? for (Permission perm : perms.values()) { > ??????????? FilePermission fp = (FilePermission)perm; > ??????????? if (((needed & fp.getMask()) != 0) && > fp.impliesIgnoreMask(fperm)) { > ??????????????? effective |= fp.getMask(); > ??????????????? if ((effective & desired) == desired) { > ??????????????????? return true; > ??????????????? } > ??????????????? needed = (desired ^ effective);// <<< should be > (desired & ~effective) > ??????????? } > ??????? } > > Here, if a permission's mask `fp.getMask()` intersects with `needed`, > but does not fully cover all the needed bits, the variable `needed` is > updated as XOR of desired and effective. This can raise a > not-really-needed bits in the `needed` mask, so that for all subsequent > permissions from the collection with that unneeded bits in the mask, an > expensive fp.impliesIgnoreMask(fperm) will be executed. > > The fix does not change the behavior, but helps avoid unnecessary calls > to impliesIgnoreMask(). > > Would you please help review a trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415 > WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/ > > Thanks in advance! > From ivan.gerasimov at oracle.com Mon Sep 30 18:42:03 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 30 Sep 2019 11:42:03 -0700 Subject: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection In-Reply-To: References: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> Message-ID: <10175bdf-027b-54ec-fb30-370843aed6f0@oracle.com> Thank you Sean for reviewing! With kind regards, Ivan On 9/27/19 7:20 AM, Sean Mullan wrote: > Hi Ivan, > > The fix looks good. Good catch. > > --Sean > > On 8/30/19 7:32 PM, Ivan Gerasimov wrote: >> Hello! >> >> In the two implementations of >> PermissionCollection.implies(Permission), all the permissions are >> traversed, and their corresponding bit mask are checked. >> >> For example, here's a snippet from FilePermission.java: >> >> ???????? int desired = fperm.getMask(); >> ???????? int effective = 0; >> ???????? int needed = desired; >> >> ???????? for (Permission perm : perms.values()) { >> ???????????? FilePermission fp = (FilePermission)perm; >> ???????????? if (((needed & fp.getMask()) != 0) && >> fp.impliesIgnoreMask(fperm)) { >> ???????????????? effective |= fp.getMask(); >> ???????????????? if ((effective & desired) == desired) { >> ???????????????????? return true; >> ???????????????? } >> ???????????????? needed = (desired ^ effective);// <<< should be >> (desired & ~effective) >> ???????????? } >> ???????? } >> >> Here, if a permission's mask `fp.getMask()` intersects with `needed`, >> but does not fully cover all the needed bits, the variable `needed` >> is updated as XOR of desired and effective. This can raise a >> not-really-needed bits in the `needed` mask, so that for all >> subsequent permissions from the collection with that unneeded bits in >> the mask, an expensive fp.impliesIgnoreMask(fperm) will be executed. >> >> The fix does not change the behavior, but helps avoid unnecessary >> calls to impliesIgnoreMask(). >> >> Would you please help review a trivial fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/ >> >> Thanks in advance! >> > -- With kind regards, Ivan Gerasimov From valerie.peng at oracle.com Mon Sep 30 19:21:44 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Sep 2019 12:21:44 -0700 Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using mozilla-nss-3.14 In-Reply-To: References: <688dd8e3-c0a3-8932-17d6-0820ccb8ac34@oracle.com> Message-ID: Yes, latest webrev looks fine to me. Thanks for the update, Valerie On 9/26/2019 2:30 AM, Baesken, Matthias wrote: > > Hi Christoph, you are right ?- ?I should? better use getVersionStr()?? > ,? I?ll replace it . > > Valerie are you fine with the latest webrev ? > > Best regards, Matthias > > *From:*Langer, Christoph > *Sent:* Mittwoch, 25. September 2019 16:50 > *To:* Baesken, Matthias ; Valerie Peng > ; security-dev at openjdk.java.net > *Subject:* RE: Re: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Matthias, > > looks good. > > One minor thing I just recognized: > java.security.Provider::getVersion() is deprecated. Can you please use > p.getVersionStr in line 323? But no need to see another webrev ?? > > Best regards > > Christoph > > *From:*Baesken, Matthias > > *Sent:* Mittwoch, 25. September 2019 16:34 > *To:* Valerie Peng >; security-dev at openjdk.java.net > > *Cc:* Langer, Christoph > > *Subject:* RE: Re: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Valerie / Christoph? , > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.2/ > > * Followed ?the idea of Christoph : ?One minor style nit: You could > close the else case in line 335 with ?}? and then have just one > throw e;? > * Moved the isNSS(Provider)?? check in front of the version? > checking??? and potential output > > Best regards, Matthias > > Hi Matthias, > > The output on line 324 may report inconsistent info - the provider in > use may not be NSS but yet you put NSS version with provider name? > > Since you are updating the code here, how about re-org the code a bit > and first check for whether NSS provider is used then do the various > version-specific handling. > > Regards, > > Valerie > > On 9/24/2019 5:39 AM, Langer, Christoph wrote: > > Hi Matthias, > > looks good to me. > > One minor style nit: You could close the else case in line 335 with > ?}? and then have just one throw e; after the whole if else block. > > Best regards > > Christoph > > *From:*Baesken, Matthias > > *Sent:* Dienstag, 24. September 2019 10:30 > *To:* Langer, Christoph > ; security-dev at openjdk.java.net > > *Cc:* Zeller, Arno > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.1/ > > I adjusted the imports and? now output a warning . > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Montag, 23. September 2019 16:07 > *To:* Langer, Christoph >; security-dev at openjdk.java.net > > *Cc:* Zeller, Arno > > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Christoph,?? I am okay ?with your suggestion to?? just? print? a? > message in ?case that? an? older nss lib? < 3.15 is found ; however?? > let?s? see what others think . > > (but for Solaris? we let the test pass when?? noticing? old nss > versions ,? so I thought? it might make some sense to behave on Linux > in the same way ) > > Best regards, Matthias > > *From:*Langer, Christoph > > *Sent:* Montag, 23. September 2019 15:53 > *To:* Baesken, Matthias >; security-dev at openjdk.java.net > > *Cc:* Zeller, Arno > > *Subject:* RE: RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hi Matthias, > > generally I agree that it?s a good idea to have more diagnostic output > in case of failures in this test. > > But, given that there?s an upgrade path even on our old Linux SLES > 11.3 system to a newer libnss that has a fix for the bug that we > observe, I suggest that the test should still fail with libnss 3.14. > So I suggest you only add the line > > System.out.println("Exception occured using " + p.getName() + " > version " + ver); > > and maybe a comment stating that libnss 3.14 on Linux isn?t good for > this test. > > BTW, if you want to clean up the testcase a bit, you might remove line > 36, import java.math.*; because it?s not needed. Or replace all the > imports with: > > import java.security.GeneralSecurityException; > > import java.security.Provider; > > import java.util.Arrays; > > import javax.crypto.Cipher; > > import javax.crypto.SecretKey; > > import javax.crypto.spec.GCMParameterSpec; > > import javax.crypto.spec.SecretKeySpec; > > Thanks > > Christoph > > *From:*Baesken, Matthias > > *Sent:* Montag, 23. September 2019 15:16 > *To:* security-dev at openjdk.java.net > *Cc:* Langer, Christoph >; Zeller, Arno > > *Subject:* RFR [XS] 8231357: > sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using > mozilla-nss-3.14 > > Hello,? please review this small test related change . > > We? noticed that ?on our SLES (SuSE Linux) 11 ??test? machines, the test > > sun/security/pkcs11/Cipher/TestKATForGCM.java > > fails when older nss versions? are used on the system , especially > ?nss 3.14 . > > > The used package is named? ?mozilla-nss-3.14 . > Upgrading to newer versions (e.g. 3.20) ??makes the test succeed , so > it might be helpful > to add a check in the test like it is done already for old nss > versions on Solaris. > > (nss? 3.15? contains a couple? of? AES cipher with GCM? ??related > fixes, those might be the ones needed to run the test successfully ). > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8231357 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.0/ > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.osipov at siemens.com Wed Sep 25 21:27:17 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Wed, 25 Sep 2019 23:27:17 +0200 Subject: [JDK-8223172] Incomplete/Unusable Kerberos Cross-Realm Referrals Support Message-ID: Hi folks, apologies upfront that I wasn't able when Martin Balao asked for a review of the code. I finally made to test it and cannot see that it is working anyhow here. I won't dive into my usecase now, but will depict two simple cases which are not possible. All tests were performed with Oracle JDK 13 on Windows 7: > java version "13" 2019-09-17 > Java(TM) SE Runtime Environment (build 13+33) > Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) 1. kinit (JDK bundled) does not work. It does neither provide an '-E' option, nor does it send NT-ENTERPRISE, but only NT-UNKNOWN: > 0000 30 25 a0 03 02 01 00 a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic > 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem > 0020 65 6e 73 2e 63 6f 6d ens.com In byte 0x06 is the name type NT-UNKNOWN (0). In contrast to this with MIT Kerberos 1.17 and 'kinit -E' I see in Wireshark: > 0000 30 25 a0 03 02 01 0a a1 1e 30 1c 1b 1a 6d 69 63 0%.......0...mic > 0010 68 61 65 6c 2e 6f 73 69 70 6f 76 40 73 69 65 6d hael.osipov at siem > 0020 65 6e 73 2e 63 6f 6d ens.com byte 0x06 is now name type NT-ENTERPRISE-PRINCIPAL (10). Trying the very same with LSA on Windows with "run as user" I get for my implicit UPN osipovmi at AD001.SIEMENS.NET always type 10. It only uses NT-PRINCIPAL when I provide the local part (samAccountName). 2. Using the appropriate OID for the enterprise principal: > public static void main(String[] args) throws GSSException { > > GSSManager m = GSSManager.getInstance(); > > Oid msUpnOid = new Oid("1.3.6.1.4.1.311.20.2.3"); > Oid krb5PrincipalOid = new Oid("1.2.840.113554.1.2.2.1"); > Oid krb5EnterprisePrincialOid = new Oid("1.2.840.113554.1.2.2.6"); > > Oid krb5MechOid = new Oid("1.2.840.113554.1.2.2"); > > GSSName upn = m.createName("michael.osipov at siemens.com", krb5EnterprisePrincialOid); > > } gives me: > Exception in thread "main" GSSException: Name of unsupported type provided (Mechanism level: 1.2.840.113554.1.2.2.6 is an unsupported nametype) > at java.security.jgss/sun.security.jgss.krb5.Krb5NameElement.getInstance(Krb5NameElement.java:87) > at java.security.jgss/sun.security.jgss.krb5.Krb5MechFactory.getNameElement(Krb5MechFactory.java:99) > at java.security.jgss/sun.security.jgss.GSSManagerImpl.getNameElement(GSSManagerImpl.java:184) > at java.security.jgss/sun.security.jgss.GSSNameImpl.getElement(GSSNameImpl.java:478) > at java.security.jgss/sun.security.jgss.GSSNameImpl.init(GSSNameImpl.java:201) > at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:170) > at java.security.jgss/sun.security.jgss.GSSNameImpl.(GSSNameImpl.java:151) > at java.security.jgss/sun.security.jgss.GSSManagerImpl.createName(GSSManagerImpl.java:109) > at com.siemens.dynamowerk.Main.main(Main.java:20) and yes, the OID has never been defined in that class [1], but is present in MIT Kerberos [2]. I haven't tried a programmatical kinit, but as mentioned in the notes [3], Krb5LoginModule does not support it, so I don't even have to try. Any insights? Beside that, it'd be very cool if this gets into 11u or better yet to 8u. I have talked with Weijun about this several times many years ago for Java 7+. I have no option to use anything else, but Java 8 for now. If someone wants to know better about my usecase, I'd be happy to lay it out in detail. I do need at least krb5EnterprisePrincialOid and better msUpnOid for my usecase. The only option I see now is to write a delegating wrapper for this: > GSSName upn = m.createName("michael.osipov at siemens.com", krb5PrincipalOid); > > GSSName wrappedUpn = new WrappedGSSName(upn, krb5EnterprisePrincialOid); > > System.out.println(wrappedUpn); > System.out.println(wrappedUpn.getStringNameType()); > michael.osipov at siemens.com > 1.2.840.113554.1.2.2.6 Michael [1] https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/bb0786d980437800b9d6efe17e42d18241714ea1/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java#L51-L61 [2] https://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html [3] http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018952.html