From chap at anastigmatix.net Tue Jun 1 00:11:48 2021 From: chap at anastigmatix.net (Chapman Flack) Date: Mon, 31 May 2021 20:11:48 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> Message-ID: <60B57B44.2010200@anastigmatix.net> On 05/31/21 03:59, Alan Bateman wrote: > The SM survey in 2018 showed that there was some usage too. Out of curiosity, where can I learn more about this survey? Was it the kind of survey that, if I had been hanging around in the right places in 2018, I might have been solicited to respond to? Regards, -Chap From Alan.Bateman at oracle.com Tue Jun 1 05:51:16 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Jun 2021 06:51:16 +0100 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <60B57B44.2010200@anastigmatix.net> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> Message-ID: On 01/06/2021 01:11, Chapman Flack wrote: > On 05/31/21 03:59, Alan Bateman wrote: >> The SM survey in 2018 showed that there was some usage too. > Out of curiosity, where can I learn more about this survey? > > Was it the kind of survey that, if I had been hanging around in the right > places in 2018, I might have been solicited to respond to? The survey that has been referenced a few times here was in Feb 2018 [1]. Sean linked to the results at the time [2] but the link no longer works. The main goal was to gather data on usages beyond applets and JNLP. -Alan [1] https://twitter.com/seanjmullan/status/960553938553630721 [2] https://twitter.com/seanjmullan/status/976466563997028354 From peter.firmstone at zeus.net.au Tue Jun 1 06:11:11 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 1 Jun 2021 16:11:11 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> Message-ID: <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> Would have really liked to have known about that. Any chance Java 17 LTS (hopefully with sorted security manager property), can be supported as long as Java 8, 16 years? The new security API's don't exist yet, I'd prefer to work with a version that has a fully functional SecurityManager rather than one that's non functional, because it's the functionality that's important to us. It's going to take a long time to migrate, once the new API's exist, they need to receive acceptance, then we also need to rewrite our software to suit, assuming it takes 4 years to write and implement the new security api, there's not much time left then before 17's EOL if it only has 8 years of support. I figure there's no harm in asking. Regards, Peter. On 1/06/2021 3:51 pm, Alan Bateman wrote: > On 01/06/2021 01:11, Chapman Flack wrote: >> On 05/31/21 03:59, Alan Bateman wrote: >>> The SM survey in 2018 showed that there was some usage too. >> Out of curiosity, where can I learn more about this survey? >> >> Was it the kind of survey that, if I had been hanging around in the >> right >> places in 2018, I might have been solicited to respond to? > The survey that has been referenced a few times here was in Feb 2018 > [1]. Sean linked to the results at the time [2] but the link no longer > works. The main goal was to gather data on usages beyond applets and > JNLP. > > -Alan > > [1] https://twitter.com/seanjmullan/status/960553938553630721 > [2] https://twitter.com/seanjmullan/status/976466563997028354 From Alan.Bateman at oracle.com Tue Jun 1 07:21:16 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 Jun 2021 08:21:16 +0100 Subject: JEP 411: Disable warning message with flag? In-Reply-To: <60B55AF4.803@anastigmatix.net> References: <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com> <60B512C4.40608@anastigmatix.net> <25588843-E867-4720-97CD-D8B44155AE72@oracle.com> <60B55AF4.803@anastigmatix.net> Message-ID: <5cb0d3fd-441a-bdbc-f0ca-8d51c933f8e4@oracle.com> On 31/05/2021 22:53, Chapman Flack wrote: > : > Thank you for that. One question I have been wondering about: do you have > any internally-tracked metrics that you can share about how many uses > of doPrivileged there are in the JDK codebase, and perhaps even a histogram > of the stack depth from the doPrivileged down to the affected > checked operation(s)? The #usages of doPrivileged in the JDK is around 1200. The code is in the openjdk/jdk repo so you can get other stats if you want. If you do analysis to create a histogram on the number of frames walked when doing privileged operations then it would be useful to share. -Alan From ron.pressler at oracle.com Tue Jun 1 08:56:09 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 1 Jun 2021 08:56:09 +0000 Subject: [External] : Re: JEP 411: Disable warning message with flag? In-Reply-To: <60B55AF4.803@anastigmatix.net> References: <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com> <60B512C4.40608@anastigmatix.net> <25588843-E867-4720-97CD-D8B44155AE72@oracle.com> <60B55AF4.803@anastigmatix.net> Message-ID: > On 31 May 2021, at 22:53, Chapman Flack wrote: > > > I am not sure what you are getting at with goal 3. Will the warning > phone home? No, but it will make users aware, and that awareness can be measured or estimated. > > I am also sort of wondering what's to become of some of the familiar > known rules in the post-SM world. Will getClassLoader() become always > allowed, whether the loader is an ancestor or not? Will > setContextClassLoader() be a free-for-all? checkGuard()? ...? > > Is it confidently believed that the JPMS encapsulation suffices for > integrity enforcement and non-circumvention with all of those former > familiar rules relaxed? > Someone on the security team would be better placed to answer those questions but it is not our goal to provide a sandbox in the JDK or replace the current functionality of the Security Manager. We believe the module system, once encapsulation is fully made airtight, will significantly reduce the JDK?s attack surface area (and that of any other component the application chooses to encapsulate). ? Ron From peter.firmstone at zeus.net.au Tue Jun 1 09:06:33 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 1 Jun 2021 19:06:33 +1000 Subject: JEP 411 - Secure Java Distribution Message-ID: If a vendor were to continue supporting SecurityManager and was backporting from OpenJDK, if it passes the JCK with SecurityManager disabled, that's still acceptable right? -- Regards, Peter Firmstone From ron.pressler at oracle.com Tue Jun 1 10:02:28 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 1 Jun 2021 10:02:28 +0000 Subject: JEP 411 - Secure Java Distribution In-Reply-To: References: Message-ID: <82020879-12B9-48D4-84D2-79FB9A6D5A3A@oracle.com> That depends what you mean by ?acceptable.? You can maintain a version of the Java SE spec that contains the Security Manager forever. If you want to add the SecurityManager to a version of the spec that doesn?t contain it (or contains it but behaves in a degraded manner) then that will not pass the JCK even when no Security Manager is installed, as the spec requires that ?spec-owned? APIs are neither removed *nor added*. You could create a JDK targeting such a version that still passes the JCK with an API *similar* to SecurityManager but that isn?t in any of the spec?s namespaces. Of course, OpenJDK has an open-source license, and you can do what you want with that code in accordance with the license even if you don?t pass the JCK. Adding *new* files that are not currently covered by the license might have other issues if they interfere with the spec in some way, and you?ll need to consult with the appropriate people. ? Ron > On 1 Jun 2021, at 10:06, Peter Firmstone wrote: > > If a vendor were to continue supporting SecurityManager and was backporting from OpenJDK, if it passes the JCK with SecurityManager disabled, that's still acceptable right? > > -- > Regards, > Peter Firmstone > From alanb at openjdk.java.net Tue Jun 1 12:50:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 12:50:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the middle of the declaration? The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From dalibor.topic at oracle.com Tue Jun 1 13:12:19 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 1 Jun 2021 15:12:19 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> Message-ID: <6939723e-7ba8-4c16-fa84-5b4eeaf80e50@oracle.com> On 01.06.2021 08:11, Peter Firmstone wrote: > Any chance Java 17 LTS (hopefully with sorted security manager > property), can be supported as long as Java 8, 16 years? According to the Oracle Java SE Support Roadmap at https://www.oracle.com/java/technologies/java-se-support-roadmap.html extended support for Java SE 17 is planned until September 2029. That's longer than Java SE 8 was initially planned to be supported. It's too early to speculate about extensions at this point in time before the ecosystem has had a chance to adopt the release. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From weijun at openjdk.java.net Tue Jun 1 15:06:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:06:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: rename setSecurityManagerDirect to implSetSecurityManager ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue Jun 1 15:21:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:21:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07 Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From fguallini at openjdk.java.net Tue Jun 1 15:28:22 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 1 Jun 2021 15:28:22 GMT Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 15:50:23 GMT, Fernando Guallini wrote: >> Refactor the following shell tests to Java: >> - security/pkcs11/KeyStore/Basic.sh >> - security/pkcs11/KeyStore/ClientAuth.sh >> - security/pkcs11/KeyStore/SecretKeysBasic.sh >> - security/pkcs11/Provider/ConfigQuotedString.sh >> - security/pkcs11/Provider/Login.sh >> - security/pkcs11/Config/ReadConfInUTF16Env.sh >> >> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR. >> >> Additionally, further changes are introduced in the following test: >> >> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired. >> >> - Basic: Remove redundant X509Certificate casting >> >> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue. >> >> All the mentioned tests were run many times in multiple platforms to ensure stability > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into 8180571 > - removed tab in comment > - Merge branch 'master' into 8180571 > - fixed summary in ClientAuth > - refactor tests > - refactored shell tests to java Please if someone could review and sponsor this PR. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/4092 From xuelei at openjdk.java.net Tue Jun 1 15:44:22 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Jun 2021 15:44:22 GMT Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 15:50:23 GMT, Fernando Guallini wrote: >> Refactor the following shell tests to Java: >> - security/pkcs11/KeyStore/Basic.sh >> - security/pkcs11/KeyStore/ClientAuth.sh >> - security/pkcs11/KeyStore/SecretKeysBasic.sh >> - security/pkcs11/Provider/ConfigQuotedString.sh >> - security/pkcs11/Provider/Login.sh >> - security/pkcs11/Config/ReadConfInUTF16Env.sh >> >> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR. >> >> Additionally, further changes are introduced in the following test: >> >> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired. >> >> - Basic: Remove redundant X509Certificate casting >> >> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue. >> >> All the mentioned tests were run many times in multiple platforms to ensure stability > > Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into 8180571 > - removed tab in comment > - Merge branch 'master' into 8180571 > - fixed summary in ClientAuth > - refactor tests > - refactored shell tests to java Nice update. Look good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4092 From alanb at openjdk.java.net Tue Jun 1 16:05:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 16:05:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Tue Jun 1 16:28:27 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Jun 2021 16:28:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From sean.mullan at oracle.com Tue Jun 1 16:32:34 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Jun 2021 12:32:34 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> Message-ID: <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> On 6/1/21 2:11 AM, Peter Firmstone wrote: > Would have really liked to have known about that. It was announced on jdk-dev at the time it was launched, with a follow-up reminder one week later: https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html --Sean > > Any chance Java 17 LTS (hopefully with sorted security manager > property), can be supported as long as Java 8, 16 years? > > The new security API's don't exist yet, I'd prefer to work with a > version that has a fully functional SecurityManager rather than one > that's non functional, because it's the functionality that's important > to us. > > It's going to take a long time to migrate, once the new API's exist, > they need to receive acceptance, then we also need to rewrite our > software to suit, assuming it takes 4 years to write and implement the > new security api, there's not much time left then before 17's EOL if it > only has 8 years of support. > > I figure there's no harm in asking. > > Regards, > > Peter. > > On 1/06/2021 3:51 pm, Alan Bateman wrote: >> On 01/06/2021 01:11, Chapman Flack wrote: >>> On 05/31/21 03:59, Alan Bateman wrote: >>>> The SM survey in 2018 showed that there was some usage too. >>> Out of curiosity, where can I learn more about this survey? >>> >>> Was it the kind of survey that, if I had been hanging around in the >>> right >>> places in 2018, I might have been solicited to respond to? >> The survey that has been referenced a few times here was in Feb 2018 >> [1]. Sean linked to the results at the time [2] but the link no longer >> works. The main goal was to gather data on usages beyond applets and >> JNLP. >> >> -Alan >> >> [1] https://twitter.com/seanjmullan/status/960553938553630721 >> [2] https://twitter.com/seanjmullan/status/976466563997028354 From dalibor.topic at oracle.com Tue Jun 1 17:03:05 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 1 Jun 2021 19:03:05 +0200 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> Message-ID: <71741157-19e2-f11d-998e-db33d79ad27b@oracle.com> The survey was also shared by @java to its many followers, fwiw: https://twitter.com/java/status/961296752732135424?s=20 and through the OpenJDK Quality Outreach to the many projects participating there: https://mail.openjdk.java.net/pipermail/quality-discuss/2018-February/000749.html If you'd like to get regular information about upcoming JEPs, bug fixes, surveys etc. please consider joining the Quality Outreach for your open source project by joining the mailing list quality-discuss, and asking there to be added to the list. Please see https://wiki.openjdk.java.net/display/quality/Quality+Outreach for details on participating projects, reports, etc. cheers, dalibor topic On 01.06.2021 18:32, Sean Mullan wrote: > > > On 6/1/21 2:11 AM, Peter Firmstone wrote: >> Would have really liked to have known about that. > > It was announced on jdk-dev at the time it was launched, with a > follow-up reminder one week later: > > https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html > > --Sean > >> >> Any chance Java 17 LTS (hopefully with sorted security manager >> property), can be supported as long as Java 8, 16 years? >> >> The new security API's don't exist yet, I'd prefer to work with a >> version that has a fully functional SecurityManager rather than one >> that's non functional, because it's the functionality that's important >> to us. >> >> It's going to take a long time to migrate, once the new API's exist, >> they need to receive acceptance, then we also need to rewrite our >> software to suit, assuming it takes 4 years to write and implement the >> new security api, there's not much time left then before 17's EOL if it >> only has 8 years of support. >> >> I figure there's no harm in asking. >> >> Regards, >> >> Peter. >> >> On 1/06/2021 3:51 pm, Alan Bateman wrote: >>> On 01/06/2021 01:11, Chapman Flack wrote: >>>> On 05/31/21 03:59, Alan Bateman wrote: >>>>> The SM survey in 2018 showed that there was some usage too. >>>> Out of curiosity, where can I learn more about this survey? >>>> >>>> Was it the kind of survey that, if I had been hanging around in the >>>> right >>>> places in 2018, I might have been solicited to respond to? >>> The survey that has been referenced a few times here was in Feb 2018 >>> [1]. Sean linked to the results at the time [2] but the link no longer >>> works. The main goal was to gather data on usages beyond applets and >>> JNLP. >>> >>> -Alan >>> >>> [1] https://twitter.com/seanjmullan/status/960553938553630721 >>> [2] https://twitter.com/seanjmullan/status/976466563997028354 -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From mcimadamore at openjdk.java.net Tue Jun 1 17:03:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 17:03:59 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v27] In-Reply-To: References: Message-ID: <2Ea2q8-xz5mHKcvpHDlC9SqoArgaW0Iw32iG4HpQuVs=.c4df006f-e9fe-4438-ada1-abab7e7bd2a8@github.com> > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into JEP-412 - Merge branch 'master' into JEP-412 - * Add missing `final` in some static fields * Downgrade native methods in ProgrammableUpcallHandler to package-private - Add sealed modifiers in morally sealed API interfaces - Merge branch 'master' into JEP-412 - Fix VaList test Remove unused code in Utils - Merge pull request #11 from JornVernee/JEP-412-MXCSR Add MXCSR save and restore to upcall stubs for non-windows platforms - Add MXCSR save and restore to upcall stubs for non-windows platforms - Merge branch 'master' into JEP-412 - Fix issue with bounded arena allocator - ... and 28 more: https://git.openjdk.java.net/jdk/compare/36dc268a...10767bc0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=26 Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Tue Jun 1 17:13:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Jun 2021 17:13:24 GMT Subject: Integrated: 8267990: Revisit some uses of `synchronized` in the HttpClient API In-Reply-To: References: Message-ID: On Mon, 31 May 2021 16:21:29 GMT, Daniel Fuchs wrote: > The Utils.remaining(List list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. > > Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place). This pull request has now been integrated. Changeset: 9d8ad2ed Author: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/9d8ad2ed62325bd8d813974d5aa1e031ed8bf8da Stats: 105 lines in 13 files changed: 62 ins; 6 del; 37 mod 8267990: Revisit some uses of `synchronized` in the HttpClient API Reviewed-by: chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/4275 From chap at anastigmatix.net Tue Jun 1 17:30:38 2021 From: chap at anastigmatix.net (Chapman Flack) Date: Tue, 1 Jun 2021 13:30:38 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> Message-ID: <60B66EBE.6040900@anastigmatix.net> On 06/01/21 12:32, Sean Mullan wrote: > On 6/1/21 2:11 AM, Peter Firmstone wrote: >> Would have really liked to have known about that. > > It was announced on jdk-dev at the time it was launched, with a follow-up > reminder one week later: > > https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html Thanks for that link. I see the announcement said The results of the survey will be made public after the survey closes. That email thread seems to end with the week-later reminder, but I think I found the followup [1]. It links to the results on SurveyMonkey [2], which seem to be viewable if one whitelists www.surveymonkey.com, cdnjs.cloudflare.com, and prod.smassets.net. It also refers to a blog post [3], no longer a good link; also the only occurrence of that URL in the Wayback Machine is a November 2020 archive of its "The content that you're looking [sic] is no longer on this page" page [4]. Is it possible the blogs.oracle.com URL structure just got rearranged? Is there a currently usable link? (My search there for "security manager survey" produces 742 results, six at a time; I haven't found it yet.) Ironically, I easily found a March 2021 blog post [5] "Quiz yourself: Using the SecurityManager class in Java", from which a reader might have come away confident the thing was a going concern. Regards, -Chap [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000929.html [2] https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/ [3] https://blogs.oracle.com/mullan/securitymanager-survey-results [4] https://web.archive.org/web/20201121023702/https://blogs.oracle.com/mullan/securitymanager-survey-results [5] https://blogs.oracle.com/javamagazine/quiz-yourself-using-the-securitymanager-class-in-java From sean.mullan at oracle.com Tue Jun 1 18:24:08 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Jun 2021 14:24:08 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <60B66EBE.6040900@anastigmatix.net> References: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au> <60B57B44.2010200@anastigmatix.net> <8f72869f-a700-16c6-0d13-dfe4c0589585@zeus.net.au> <1169bfa6-ad17-48e2-39ee-1866429ee6a0@oracle.com> <60B66EBE.6040900@anastigmatix.net> Message-ID: <1e66535f-4c35-f0cb-4241-7f659cd02750@oracle.com> On 6/1/21 1:30 PM, Chapman Flack wrote: > On 06/01/21 12:32, Sean Mullan wrote: >> On 6/1/21 2:11 AM, Peter Firmstone wrote: >>> Would have really liked to have known about that. >> >> It was announced on jdk-dev at the time it was launched, with a follow-up >> reminder one week later: >> >> https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html > > Thanks for that link. I see the announcement said > > The results of the survey will be made public after the survey closes. > > That email thread seems to end with the week-later reminder, but I think > I found the followup [1]. > > It links to the results on SurveyMonkey [2], which seem to be viewable > if one whitelists https://urldefense.com/v3/__http://www.surveymonkey.com__;!!GqivPVa7Brio!PQjV64chVEWfRM5VPM45uJ1dPiIsGzyukEkPp1I8jCoJWUg65dwS9cshHXnCziOu$ , cdnjs.cloudflare.com, and > prod.smassets.net. Those results are very incomplete (it says there were only 16 responses when there were more). I don't know what happened to the rest of the responses, perhaps SurveyMonkey deleted many of them over time for some reason. The page should probably be deleted as it is no longer accurate. I do have a PDF of all the results that I saved locally, but I have no plans to go over that again or post that right now. > It also refers to a blog post [3], no longer a good link; also the only > occurrence of that URL in the Wayback Machine is a November 2020 archive > of its "The content that you're looking [sic] is no longer on this page" > page [4]. It was automatically deleted, probably because I didn't post enough ... > Is it possible the blogs.oracle.com URL structure just got rearranged? > Is there a currently usable link? (My search there for "security manager > survey" produces 742 results, six at a time; I haven't found it yet.) > > Ironically, I easily found a March 2021 blog post [5] "Quiz yourself: > Using the SecurityManager class in Java", from which a reader might > have come away confident the thing was a going concern. This is just a quiz about how to use some of the SecurityManager APIs by some people who write about Java technology. --Sean > > Regards, > -Chap > > > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000929.html > [2] https://urldefense.com/v3/__https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/__;!!GqivPVa7Brio!PQjV64chVEWfRM5VPM45uJ1dPiIsGzyukEkPp1I8jCoJWUg65dwS9cshHeuKhBql$ > [3] https://blogs.oracle.com/mullan/securitymanager-survey-results > [4] > https://urldefense.com/v3/__https://web.archive.org/web/20201121023702/https:/*blogs.oracle.com/mullan/securitymanager-survey-results__;Lw!!GqivPVa7Brio!PQjV64chVEWfRM5VPM45uJ1dPiIsGzyukEkPp1I8jCoJWUg65dwS9cshHUl1Q8D8$ > [5] > https://blogs.oracle.com/javamagazine/quiz-yourself-using-the-securitymanager-class-in-java > From fguallini at openjdk.java.net Tue Jun 1 19:13:25 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 1 Jun 2021 19:13:25 GMT Subject: Integrated: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures In-Reply-To: References: Message-ID: On Tue, 18 May 2021 13:19:53 GMT, Fernando Guallini wrote: > Refactor the following shell tests to Java: > - security/pkcs11/KeyStore/Basic.sh > - security/pkcs11/KeyStore/ClientAuth.sh > - security/pkcs11/KeyStore/SecretKeysBasic.sh > - security/pkcs11/Provider/ConfigQuotedString.sh > - security/pkcs11/Provider/Login.sh > - security/pkcs11/Config/ReadConfInUTF16Env.sh > > Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR. > > Additionally, further changes are introduced in the following test: > > - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired. > > - Basic: Remove redundant X509Certificate casting > > - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue. > > All the mentioned tests were run many times in multiple platforms to ensure stability This pull request has now been integrated. Changeset: ccfcd926 Author: Fernando Guallini Committer: Xue-Lei Andrew Fan URL: https://git.openjdk.java.net/jdk/commit/ccfcd926674ee0bd88f34b16b489abe008169b11 Stats: 1076 lines in 18 files changed: 195 ins; 820 del; 61 mod 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4092 From valeriep at openjdk.java.net Tue Jun 1 19:47:43 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:43 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v7] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 21:13:56 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > Remove GCTR reset() calls because GCTR is released after the operation > some variable name consistency > other small cleanup Most of the updates look fine, but some of my review comments in GaloisCounterMode didn't get a reply, just want to be sure that you saw them? Thanks, Valerie src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 156: > 154: } > 155: } > 156: */ Remove? src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 96: > 94: > 95: // Default value is 128bits, this is in bytes. > 96: int tagLenBytes = 16; nit: use DEFAULT_TAG_LEN instead of 16 src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 744: > 742: int resultLen = 0; > 743: > 744: int bLen = getBufferedLength(); Well, it seems strange to calculate bLen based on 'ibuffer' instead of the specified 'buffer'. For code clarity, it seems better to just use 'buffer'? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 19:47:45 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:45 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v3] In-Reply-To: References: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com> Message-ID: <9c9yXMU1bDrCZUQ1kST-ShC_2ifv0Q4kS42uuoIt4eg=.109ab634-fc07-4b9f-81e5-b648a4793c82@github.com> On Mon, 24 May 2021 16:37:05 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 189: >> >>> 187: ct.position(ct.position()); >>> 188: return processed; >>> 189: } else if (!ct.isReadOnly()) { >> >> Maybe you meant "ct.hasArray()" instead of "!ct.isReadOnly()"? > > hasArray() checks both isReadonly() and isDirect(). Since I already did isDirect() in the previous if, I just need to check readonly here I see. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 259: >> >>> 257: @Override >>> 258: protected void engineInit(int opmode, Key key, >>> 259: AlgorithmParameterSpec params, SecureRandom random) >> >> The specified "random" is not saved to internal "random". Perhaps an oversight? > > Yeah, I changed this code long ago, i suspect I didn't realize engineGetParameters() used it It seems that you still have not saved the specified 'random' into the instance 'random' field? Did I miss something? >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 279: >> >>> 277: if (iv.length == 0) { >>> 278: throw new InvalidAlgorithmParameterException("IV is empty"); >>> 279: } >> >> Why separating the validation of iv and tag length in separate methods, i.e. engineInit() vs init()? Consider consolidating them? > > I think I had a reason for this where I didn't know what the exact error was. I'd rather keep them separate so it throws the right message for the error. It's not a performance critical area. Ok, it's more for code robustness, not for performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 19:47:46 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:46 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v3] In-Reply-To: <5bTZnp3tlrgGIqsD9zCO-ER22fOWrUkEBfDAqE8j7ag=.d0005d10-504a-45db-a917-fbc1d4da4764@github.com> References: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com> <5bTZnp3tlrgGIqsD9zCO-ER22fOWrUkEBfDAqE8j7ag=.d0005d10-504a-45db-a917-fbc1d4da4764@github.com> Message-ID: On Fri, 21 May 2021 03:07:15 GMT, Anthony Scarpino wrote: >> yeah these checks are a bit all over the place.. I'll rework them > > So I think I only need to add a check to the engineDoFinal() that did not have a check before. for engineUpdate(...) impl, the ArrayUtil.nullAndBoundsCheck() calls are deferred to GCMEngine.doUpdate(...). In the case of engineUpdate(byte[] input, int inputOffset, int inputLen, byte[] output, int outputOffset) method, the inputLen is already used to calculate the needed output size before the check takes place. For consistency and correctness, shouldn't the check be done before the values are used, as in engineDoFinal() case? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 19:47:47 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:47 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 04:15:44 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 628: >> >>> 626: } >>> 627: >>> 628: int mergeBlock(byte[] buffer, int bufOfs, byte[] in, int inOfs, >> >> Can be made 'static'? No javadoc for this one, maybe move the javadoc for the other one up and use "Methods" in the javadoc to cover both? > > I just copied it and made a slight change to explain the difference Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 19:47:49 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:49 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 00:57:42 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 874: > >> 872: } else if (!src.isDirect() && !dst.isDirect()) { >> 873: // if src is read only, then we need a copy >> 874: if (!src.isReadOnly()) { > > Do you mean if (src.hasArray() && dst.hasArray())? Even if src is not read only, but array()/arrayOffset() methods are optional and can only be safely invoked after the hasArray() call. I assume this is again the case of !isDirect()&&!isReadOnly => hasArray()? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 19:47:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 19:47:53 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:36:49 GMT, Anthony Scarpino wrote: >> test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 34: >> >>> 32: /* >>> 33: * @test >>> 34: * @summary Call decrypt doFinal() with different output values to see if the >> >> Missing bug id? > > Here is my logic > It's not a regression test to verify a specific bug id, it's just a general functionality test. Therefore the bug id does not point to a previous failure. Hmm, alright. >> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 90: >> >>> 88: i++; >>> 89: } >>> 90: return b; >> >> The generated data seems too similar, all starts with 0 and increment. Maybe use i = len to start with? Or take some additional argument for starting value? > > I wanted consistent data because it's harder to solve crypto failures when you cannot see consistent pattern in the data. For example, the GCM case where the ciphertext is correct, but the tag is wrong. It is easier to know that the problem is in GHASH and not GCTR. > I don't see any negatives to having similar data. Might as well just hardcode the data then. Saves time to re-generate the similar bytes over and over. Not seeing much benefit of this method. Not a big deal if you intentionally use similar data. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Tue Jun 1 19:58:25 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 1 Jun 2021 19:58:25 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v7] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 16:34:44 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove GCTR reset() calls because GCTR is released after the operation >> some variable name consistency >> other small cleanup > > src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 156: > >> 154: } >> 155: } >> 156: */ > > Remove? Yeah.. probably part of testing and never deleted it ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Tue Jun 1 20:12:32 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 1 Jun 2021 20:12:32 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v9] In-Reply-To: References: Message-ID: On Sun, 30 May 2021 07:25:54 GMT, Valerie Peng wrote: >> This change updates SunJCE provider as below: >> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. >> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. >> >> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. >> >> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update to address review feedbacks and minor optimizations. In the latest commit, I have made some minor optimizations regrading the in-place encryption as suggested in Mike's earlier comments. However, the optimizations are limited to when the output offset == 0 case. ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From ascarpino at openjdk.java.net Tue Jun 1 20:27:27 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 1 Jun 2021 20:27:27 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v3] In-Reply-To: <9c9yXMU1bDrCZUQ1kST-ShC_2ifv0Q4kS42uuoIt4eg=.109ab634-fc07-4b9f-81e5-b648a4793c82@github.com> References: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com> <9c9yXMU1bDrCZUQ1kST-ShC_2ifv0Q4kS42uuoIt4eg=.109ab634-fc07-4b9f-81e5-b648a4793c82@github.com> Message-ID: On Tue, 1 Jun 2021 18:54:19 GMT, Valerie Peng wrote: >> Yeah, I changed this code long ago, i suspect I didn't realize engineGetParameters() used it > > It seems that you still have not saved the specified 'random' into the instance 'random' field? Did I miss something? yeah.. i think i got confused with the "random" vs "this.random" ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From xuelei at openjdk.java.net Tue Jun 1 21:36:43 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 1 Jun 2021 21:36:43 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v9] In-Reply-To: References: Message-ID: On Sun, 30 May 2021 07:25:54 GMT, Valerie Peng wrote: >> This change updates SunJCE provider as below: >> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. >> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. >> >> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. >> >> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update to address review feedbacks and minor optimizations. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From ascarpino at openjdk.java.net Wed Jun 2 01:57:39 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 01:57:39 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 22:05:16 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 741: > >> 739: } else { >> 740: // If the remaining in buffer + data does not fill a >> 741: // block, complete the gctr operation > > This comment seems more suited for the else block below at line 753. In addition, the criteria for completing the gctr operation should be whether src still has remaining bytes left. It's possible that the (src.remaining() == blockSize - over) and happen to fill up the block, right? The current flow for this particular case would be an op.update(...) then continue down to line 770-778, maybe you can adjust the if-check on line748 so this would go through line 754-759 and return, i.e. the else block? I changed the comment, but I also changed the code which will be in the next update > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 752: > >> 750: if (dst != null) { >> 751: dst.put(block, 0, blockSize); >> 752: } > > not counting this blockSize value into "processed"? code is now changed ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 02:04:40 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 02:04:40 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: <-oXFBqI7qMpekgB5REvTir6MTus6Z3AcTH7c7klHF0g=.88599e7b-d334-4d8a-b61a-d0de4e827d06@github.com> On Wed, 19 May 2021 23:10:07 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 757: > >> 755: if (dst != null) { >> 756: dst.put(block, 0, Math.min(block.length, len)); >> 757: } > > Would this method work correctly if dst is null? Shouldn't this be checked in the beginning of this method? Because this is a general purpose methods, the check for dst == null is when op is only ghash. Null is not an exception situation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 02:08:40 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 02:08:40 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 23:59:36 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 805: > >> 803: /** >> 804: * This segments large data into smaller chunks so hotspot will start >> 805: * using CTR and GHASH intrinsics sooner. This is a problem for app > > nit: typo: CTR->GCTR? This is to improve performance rather than a problem, no? Same comment applies to the other throttleData() method above. Yes, this is for apps or perf tests that send large input data and cause the hotspot compiler to be slower to start using the intrinsics.. This is just a new version of what was in the old code in doLastBlock() around line 400. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 03:14:43 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 03:14:43 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 19:28:44 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 874: >> >>> 872: } else if (!src.isDirect() && !dst.isDirect()) { >>> 873: // if src is read only, then we need a copy >>> 874: if (!src.isReadOnly()) { >> >> Do you mean if (src.hasArray() && dst.hasArray())? Even if src is not read only, but array()/arrayOffset() methods are optional and can only be safely invoked after the hasArray() call. > > I assume this is again the case of !isDirect()&&!isReadOnly => hasArray()? hasArray() would not be appropriate here. The code needs to get into this if, being a heap bytebuffer. If I use hasArray() it will skip to the ending else and cause a test failure. Having the isReadOnly checked inside the if(isDirect) causes it to create the necessary copy ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 03:21:48 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 03:21:48 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 00:37:44 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 942: > >> 940: >> 941: System.arraycopy(out, originalOutOfs, originalOut, originalOutOfs, >> 942: len); > > Don't you need to do `originalOut = null;` after copying the bytes over? Otherwise, if you have two overlapping calls with the same engine, the 2nd restoreOut(...) call may lead to data corruption, i.e. it will duplicate the output bytes to the original output buffer (in the 1st overlapping call). > Same applies for the ByteBuffer case, i.e. restoreDst(...). > If time permits, please add a regression test to cover this. A engine is a one time use, so setting originalOut to null isn't necessary. engineDoFinal() sets engine = null. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 03:29:39 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 03:29:39 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 01:17:14 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 975: > >> 973: doUpdate(in, inOff, inLen, output, 0); >> 974: } catch (ShortBufferException e) { >> 975: // update decryption has no output > > The comment does not seems to make sense? This is GCMEncrypt class. The right reason should be that the output array is allocated by the provider and should have the right size. However, it seems safer to throw AssertionException() instead of swallowing the SBE... Yeah the comment isn't right. I think it's excessive to throw an exception that should never happen, but I'll add a ProviderException. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 03:44:43 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 03:44:43 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 18:05:48 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1014: > >> 1012: len += gctrghash.update(buffer, 0, bLen, out, outOfs); >> 1013: outOfs += bLen; >> 1014: } > > For encryption, would the ibuffer contain more than one blocksize of data? Isn't the existing impl only put the remaining input (less than a block) into it? Line 1013: the `outOfs += bLen;`, shouldn't 'bLen' be 'len'? Actually this is related to one of your code review comments from the previous change that went into jdk16 for the code to be safe. It sounds like you are comfortable removing this check? I will remove it. Yes, it should be 'len', proving the code never gets run ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From aph at redhat.com Wed Jun 2 09:35:01 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Jun 2021 10:35:01 +0100 Subject: JEP 411 - Secure Java Distribution In-Reply-To: References: Message-ID: <18a63621-c003-540d-f9c7-aa97da97d48e@redhat.com> On 6/1/21 10:06 AM, Peter Firmstone wrote: > If a vendor were to continue supporting SecurityManager and was > backporting from OpenJDK, if it passes the JCK with SecurityManager > disabled, that's still acceptable right? Look at the licence agreement in conjunction with the JCK users' guide. See the definition of ?Compatible Licensee Implementation?. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From peter.firmstone at zeus.net.au Wed Jun 2 10:32:24 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 2 Jun 2021 20:32:24 +1000 Subject: JEP 411 - Secure Java Distribution In-Reply-To: <18a63621-c003-540d-f9c7-aa97da97d48e@redhat.com> References: <18a63621-c003-540d-f9c7-aa97da97d48e@redhat.com> Message-ID: <7527fcce-4b4e-ace2-3018-d1df8a2fa4ca@zeus.net.au> Thanks Andrew, I've been thinking about how to do this in a compatible manner. The Guard.check call checks whether SecurityManager is enabled. All permission checks in the JDK could be changed to call the Guard.check method.? Unfortunately other permission checks in user code will be broken, if they don't utilise this method, but often the most important permissions are those defined in JDK code. If we modify this method to look for a provider that's outside the java.* namespace. Then we have a point in the code where we can do something like SecurityManager, without requiring SecurityManager. Next step will be to replace all AccessController and AccessControlContext uses in JDK code with another class outside the java.* namespace. In the first instance, we allow SecurityManager, AccessController and AccessControlContext to behave in their degraded state, passing all JCK tests. But then we can create providers to replace their functionality. This is my current line of thought, as other classes will remain. Subject.doAs could be an issue, so would need to consider how to manage that. This seems the easiest way. Then for backward compatibility, we make a tool that rewrites java bytecode, to replace the calls to AccessController and AccessControlContext with compatible equivalents outside the java.* namespace in client code.? Then there's the case of removing any references to SecurityManager and looking for SecurityManager permission checks and replacing them with Guard.check. Then we could potentially continue to support this functionality on later versions of Java without detonation. Cheers, Peter. On 2/06/2021 7:35 pm, Andrew Haley wrote: > On 6/1/21 10:06 AM, Peter Firmstone wrote: >> If a vendor were to continue supporting SecurityManager and was >> backporting from OpenJDK, if it passes the JCK with SecurityManager >> disabled, that's still acceptable right? > Look at the licence agreement in conjunction with the JCK users' guide. > See the definition of ?Compatible Licensee Implementation?. > From mcimadamore at openjdk.java.net Wed Jun 2 10:55:38 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 10:55:38 GMT Subject: Integrated: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 This pull request has now been integrated. Changeset: a223189b Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab Stats: 14500 lines in 219 files changed: 8847 ins; 3642 del; 2011 mod 8264774: Implementation of Foreign Function and Memory API (Incubator) Co-authored-by: Paul Sandoz Co-authored-by: Jorn Vernee Co-authored-by: Vladimir Ivanov Co-authored-by: Athijegannathan Sundararajan Co-authored-by: Chris Hegarty Reviewed-by: psandoz, chegar, mchung, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From weijun at openjdk.java.net Wed Jun 2 12:01:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v9] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - copyright years - merge from master, resolve one conflict - Merge branch 'master' - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed Jun 2 12:01:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:33 GMT Subject: Integrated: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. This pull request has now been integrated. Changeset: 6765f902 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Co-authored-by: Sean Mullan Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Wed Jun 2 12:02:39 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Wed, 2 Jun 2021 12:02:39 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang wrote: >> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > one more change The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout 8266459 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Wed Jun 2 12:02:38 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Wed, 2 Jun 2021 12:02:38 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout 8266459 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From fguallini at openjdk.java.net Wed Jun 2 14:18:53 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 2 Jun 2021 14:18:53 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" Message-ID: The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization ------------- Commit messages: - replace thread.sleep with countdownlatch - Merge branch 'master' into 8262409 - SocketExceptions is not wrapped into SSLExceptions Changes: https://git.openjdk.java.net/jdk/pull/4308/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4308&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262409 Stats: 14 lines in 2 files changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4308/head:pull/4308 PR: https://git.openjdk.java.net/jdk/pull/4308 From rhalade at openjdk.java.net Wed Jun 2 15:15:30 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 2 Jun 2021 15:15:30 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) > > Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From weijun at openjdk.java.net Wed Jun 2 15:40:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:40:55 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v4] In-Reply-To: References: Message-ID: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8267521: Post JEP 411 refactoring: maximum covering > 50K ------------- Changes: https://git.openjdk.java.net/jdk/pull/4138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=03 Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/4138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138 PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Wed Jun 2 15:51:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:49 GMT Subject: RFR: 8267543: Post JEP 411 refactoring: security [v3] In-Reply-To: References: Message-ID: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8267543: Post JEP 411 refactoring: security ------------- Changes: https://git.openjdk.java.net/jdk/pull/4172/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=02 Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/4172.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172 PR: https://git.openjdk.java.net/jdk/pull/4172 From weijun at openjdk.java.net Wed Jun 2 15:51:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:33 GMT Subject: Integrated: 8267521: Post JEP 411 refactoring: maximum covering > 50K In-Reply-To: References: Message-ID: On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang wrote: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. > > I'll add a copyright year update commit before integration. This pull request has now been integrated. Changeset: 508cec75 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod 8267521: Post JEP 411 refactoring: maximum covering > 50K Reviewed-by: dfuchs, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From weijun at openjdk.java.net Wed Jun 2 15:51:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:49 GMT Subject: Integrated: 8267543: Post JEP 411 refactoring: security In-Reply-To: References: Message-ID: On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang wrote: > For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target. > > I'll add a copyright year update commit before integration. This pull request has now been integrated. Changeset: 40d23a0c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/40d23a0c0b955ae4636800be183da7a71665f79f Stats: 116 lines in 19 files changed: 37 ins; 36 del; 43 mod 8267543: Post JEP 411 refactoring: security Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4172 From ascarpino at openjdk.java.net Wed Jun 2 16:22:48 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 16:22:48 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 18:38:35 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1030: > >> 1028: inOfs += inLenUsed; >> 1029: inLen -= inLenUsed; >> 1030: outOfs += blockSize; > > 'blockSize' should be 'len'? Either is fine because len and blockSize will be the same. > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1033: > >> 1031: ibuffer.reset(); >> 1032: // Code below will write the remainder from 'in' to ibuffer >> 1033: } else if (remainder > 0) { > > If bLen == 0, there is no need to put the rest of 'buffer' into 'ibuffer'. > It looks strange that the remaining buffer data is stored back into 'ibuffer', then the code proceeds to encrypt 'in' from line 1043-1046. This looks incorrect as all prior buffered input should be processed before process current input. code has changed. not applicable anymore ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From xuelei at openjdk.java.net Wed Jun 2 16:24:29 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 2 Jun 2021 16:24:29 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) > > Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From ascarpino at openjdk.java.net Wed Jun 2 16:30:42 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 16:30:42 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 19:06:31 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1055: > >> 1053: // remainder offset is based on original buffer length >> 1054: ibuffer.write(in, inOfs + inLen, remainder); >> 1055: } > > I wonder if these update(byte[], int, int, byte[], int) calls (such as the one on line 1045) should take ibuffer and stores the unprocessed bytes into it. This way seems more robust and you won't need separate logic. Same comment for the doUpdate() taking ByteBuffer arguments. Do you mean having all the GCM interface implementations have an argument that takes ibuffer and adds any unprocessed data into? Maybe it would save a copy of the code, but I'm not sure I like GCTR or GHASH adding data into the ibuffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 17:11:42 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 17:11:42 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 19:46:51 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1163: > >> 1161: r = doUpdate(buffer, 0, bufLen, out, outOfs); >> 1162: bufLen -= r; >> 1163: inOfs += r; > > Would bufLen >= blockSize? Regardless, 'inOfs' should not be touched as 'in' is not used in the above doUpdate() call. removing it ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Wed Jun 2 17:13:38 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 17:13:38 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v3] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 14:31:25 GMT, Sean Coffey wrote: >> Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. >> >> New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. >> >> Reviewer request @valeriepeng > > Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - whitespace > - Further 8240256 test clean up > - Merge branch 'master' into JDK-8240256-pkcs11 > - Initial corrections from RFR > - 8240256: Better resource cleaning for SunPKCS11 Provider Changes look fine. Thanks, Valerie ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3544 From mcimadamore at openjdk.java.net Wed Jun 2 17:30:09 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 17:30:09 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Some notes on how the *system* lookup is implemented (see class SystemLookup): * On Linux and MacOS, we generate, at build time, an empty shim library. Since this library depends on the C standard libraries, we can, at runtime, load this shim library, and use `dlsym` to lookup symbols in it (since `dlsym` will also look at the dependencies). * Since Windows does not allow for library symbols in dependent libraries to be re-exported, Windows uses a different approach - which loads either `ucrtbase.dll` or `msvcrt.dll` (the former is preferred, if available), and returns a lookup object based on that. In both cases, the required libraries are loaded in a classloader-independent fashion, by taking advantage of the support available in NativeLibraries. Class loader lookups are built on top of ClassLoader::findNative (which is also the method used by JNI to find JNI methods). This patch removes all the native code which was required to support the default lookup abstraction. The implementation changes are relatively straightforward - but several test and microbenchmark updates were required. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 17:30:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 17:30:08 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Message-ID: This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. ------------- Commit messages: - Improve javadoc - Initial push Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268129 Stats: 1278 lines in 44 files changed: 569 ins; 617 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From cverghese at openjdk.java.net Wed Jun 2 17:32:32 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 2 Jun 2021 17:32:32 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: References: Message-ID: <1r2IGwcVVD-eQEvIHeMIuIikGvwEYGvye7o47ZtKBOA=.588a0e1c-7173-4a8b-9e80-019ebba5c78e@github.com> On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) > > Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization Thank you @fguallini for fixing this test. Should the SocketException be expected by the client logic as well? https://github.com/openjdk/jdk/blob/3631a39a4797919acbc7862cb94fa7f7be7f4f8a/test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java#L135 ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From valeriep at openjdk.java.net Wed Jun 2 17:52:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 17:52:07 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v10] In-Reply-To: References: Message-ID: > This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. > > Thanks, > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Add AESWrapPad alias for AES with KWP mode for better interoperability and updated tests accordingly. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2404/files - new: https://git.openjdk.java.net/jdk/pull/2404/files/cfe66d54..e24282c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=08-09 Stats: 138 lines in 6 files changed: 130 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404 PR: https://git.openjdk.java.net/jdk/pull/2404 From ascarpino at openjdk.java.net Wed Jun 2 17:56:45 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 17:56:45 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 20:00:07 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1174: > >> 1172: inLen -= r; >> 1173: r = gctrghash.update(block, 0, blockSize, out, >> 1174: outOfs + resultLen); > > I don't follow why you don't update the 'outOfs' after the line 1161 doUpdate() call and then add the resultLen when calling gctrhash.update(...) here. Seems fragile and difficult to maintain? i cleaned it up.. all the += or -+ are annoying, but not there is much i can do > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1213: > >> 1211: >> 1212: // copy the tag to the end of the buffer >> 1213: System.arraycopy(block, 0, out, resultLen + outOfs, tagLenBytes); > > Now that the tag is copied to the output, why not increment resultLen w/ tagLenBytes? This way, you don't have to keep repeating the (resultLen + tagLenBytes) for another two times? yeah, that got changed after this comment ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From wetmore at openjdk.java.net Wed Jun 2 17:58:46 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Jun 2021 17:58:46 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java Message-ID: The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. ------------- Commit messages: - Merge branch 'master' into JDK-8267485 - Updated copyright date. - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267485 Stats: 19 lines in 1 file changed: 9 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From chap at anastigmatix.net Wed Jun 2 18:07:06 2021 From: chap at anastigmatix.net (Chapman Flack) Date: Wed, 2 Jun 2021 14:07:06 -0400 Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: <60B7C8CA.9010903@anastigmatix.net> On 06/02/21 13:30, Maurizio Cimadamore wrote: > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` > abstraction, a functional interface. Crucially, `SymbolLookup` does not > concern with library loading, only symbol lookup. For this reason, two > factories are added: Hi, While I am thinking about this, what will be the behavior when the JVM itself has been dynamically loaded into an embedding application, and launched with the JNI invocation API? Will there be a *Lookup flavor that is able to find any exported symbol known in the embedding environment the JVM was loaded into? (This is the sort of condition the Mac OS linker checks when given the -bundle_loader option.) Regards, Chapman Flack (maintainer of a project that happens to work that way) From ascarpino at openjdk.java.net Wed Jun 2 18:06:40 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 18:06:40 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 23:27:51 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1317: > >> 1315: * If tagOfs = 0, 'in' contains only the tag >> 1316: * if tagOfs = blockSize, there is no data in 'in' and all the tag >> 1317: * is in ibuffer > > Is this correct? mergeBlock() returns the number of used bytes from 'in', if no data is in 'in' and all the tag is from 'ibuffer', tagOfs should equal to -tagLenBytes. The next line should be moved up as the tag position gradually shifts from 'in' toward 'ibuffer'. The tagOfs for the next line should be -tagLenBytes < tagOfs < 0? Yeah, I reworkded it > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1401: > >> 1399: ShortBufferException { >> 1400: GHASH save = null; >> 1401: > > Should do ArrayUtil.nullAndBoundsCheck() on 'in'? that was done in engineDoFinal ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Wed Jun 2 18:12:33 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 18:12:33 GMT Subject: RFR: 8248268: Support KWP in addition to KW [v10] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 17:52:07 GMT, Valerie Peng wrote: >> This change updates SunJCE provider as below: >> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. >> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. >> >> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. >> >> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. >> >> Thanks, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Add AESWrapPad alias for AES with KWP mode for better interoperability and updated tests accordingly. Hi Mike, Lastly, regarding the naming, I am not too inclined toward the AES/KW/KWPPadding suggestion since the general concept of padding is that it's general, not mode-specific and are applied before data is processed by crypto operations. The mode can just process data without knowing whether padding is applied as long as the data has the right length. Thus, I'd keep KWP as a mode which does internal padding instead of a generic padding scheme. The AutoPadding suggestion is interesting and can be easily built on top of KW and KWP modes if desired. Thanks for the feedbacks, Valerie ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From ascarpino at openjdk.java.net Wed Jun 2 18:17:38 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 18:17:38 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 22:59:18 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1412: > >> 1410: } >> 1411: >> 1412: checkDataLength(len - tagLenBytes); > > The impl of checkDataLength(...) is based on the "processed" variable which is always 0 for doUpdate() calls. This suits encryption better, but does not suit decryption? It seems that the doUpdate() calls would just keep buffering the data into 'ibuffer' without checking the size. It seems to me that this checkDataLength() call on line 1412 would always pass. checkDataLength is subtracting the length's from the max. The check at 1422 would fail because the max would be negative and the processed would be 0. I don't see it always passing ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From dfuchs at openjdk.java.net Wed Jun 2 18:22:29 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 18:22:29 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java In-Reply-To: References: Message-ID: <6iOfQ7_D1wWlWXvI5bfZreE-dyJhqkfc3qqhDoWP-y8=.437e61d6-ce46-491f-8602-8419f8c2caaf@github.com> On Sat, 22 May 2021 00:20:11 GMT, Bradford Wetmore wrote: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 107: > 105: List stack = StackWalker.getInstance( > 106: StackWalker.Option.RETAIN_CLASS_REFERENCE) > 107: .walk((s) -> s.collect(Collectors.toList())); StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE) will require a permission check. As long as the SecurityManager is still functional, doesn't this mean that creating the StackWalker should be performed in a doPrivileged? If so maybe it should be done in a (possibly static) initializer. Or is it intentional to check that the caller (and the whole calling stack) posses the `RuntimePermission("getStackWalkerWithClassReference")`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From jvernee at openjdk.java.net Wed Jun 2 18:32:27 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 18:32:27 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: <8PJV-HbcaTXWsbafEWbY3XXSICXLl4YCByOAF0Hypeo=.d1c3ff61-3cda-40cf-aa40-22e4661c9879@github.com> On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. LGTM, minor nit inline test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java line 62: > 60: ); > 61: MH_distance_ptrs = abi.downcallHandle( > 62: lookup.lookup("distance_ptrs").get(), Spurious white space Suggestion: lookup.lookup("distance_ptrs").get(), ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4316 From fguallini at openjdk.java.net Wed Jun 2 18:41:28 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 2 Jun 2021 18:41:28 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: <1r2IGwcVVD-eQEvIHeMIuIikGvwEYGvye7o47ZtKBOA=.588a0e1c-7173-4a8b-9e80-019ebba5c78e@github.com> References: <1r2IGwcVVD-eQEvIHeMIuIikGvwEYGvye7o47ZtKBOA=.588a0e1c-7173-4a8b-9e80-019ebba5c78e@github.com> Message-ID: On Wed, 2 Jun 2021 17:29:51 GMT, Clive Verghese wrote: > Thank you @fguallini for fixing this test. > > Should the SocketException be expected by the client logic as well? > https://github.com/openjdk/jdk/blob/3631a39a4797919acbc7862cb94fa7f7be7f4f8a/test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java#L135 Thanks, I did look at this but the SocketException was not thrown in the client side in any of the thousands of times I executed the test with the current PR fix, it does not seem to be necessary to expect the exception there ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From ascarpino at openjdk.java.net Wed Jun 2 18:55:30 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 18:55:30 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 00:05:17 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1442: > >> 1440: throw new ShortBufferException("Output buffer too small, must" + >> 1441: "be at least " + (len - tagLenBytes) + " bytes long"); >> 1442: } > > This looks like a half-baked save/restore functionality? This one forgot to restore the saved object > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1475: > >> 1473: >> 1474: // Length of the input >> 1475: ByteBuffer tag; > > Is the comment obsolete? I don't quite follow how it's related to 'tag'. sounds obsolete ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Wed Jun 2 19:10:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 19:10:17 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:53:51 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 741: >> >>> 739: } else { >>> 740: // If the remaining in buffer + data does not fill a >>> 741: // block, complete the gctr operation >> >> This comment seems more suited for the else block below at line 753. In addition, the criteria for completing the gctr operation should be whether src still has remaining bytes left. It's possible that the (src.remaining() == blockSize - over) and happen to fill up the block, right? The current flow for this particular case would be an op.update(...) then continue down to line 770-778, maybe you can adjust the if-check on line748 so this would go through line 754-759 and return, i.e. the else block? > > I changed the comment, but I also changed the code which will be in the next update Ok, will wait for the update then. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 752: >> >>> 750: if (dst != null) { >>> 751: dst.put(block, 0, blockSize); >>> 752: } >> >> not counting this blockSize value into "processed"? > > code is now changed Ok, also in the next update? >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 805: >> >>> 803: /** >>> 804: * This segments large data into smaller chunks so hotspot will start >>> 805: * using CTR and GHASH intrinsics sooner. This is a problem for app >> >> nit: typo: CTR->GCTR? This is to improve performance rather than a problem, no? Same comment applies to the other throttleData() method above. > > Yes, this is for apps or perf tests that send large input data and cause the hotspot compiler to be slower to start using the intrinsics.. This is just a new version of what was in the old code in doLastBlock() around line 400. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 19:13:09 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 19:13:09 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 00:03:40 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1437: > >> 1435: } catch (ArrayIndexOutOfBoundsException aiobe) { >> 1436: throw new ShortBufferException("Output buffer invalid"); >> 1437: } > > I think this should be moved to the very beginning before all the processing and if the output capacity is less than 'len-tagLenBytes' value, then no need to proceed? IIRC, the save/restore is more for algorithms which use padding, may not be needed for GCM? I had this down here because it's not needed until gctr ops are done and ghash doesn't use an output, but I can move it up. I remember Sean C having to do save/restore work for GCM.. The tag can create the similar padding issues. It felt safe to keep it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From cverghese at openjdk.java.net Wed Jun 2 19:21:41 2021 From: cverghese at openjdk.java.net (Clive Verghese) Date: Wed, 2 Jun 2021 19:21:41 GMT Subject: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) > > Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization Thank you for verifying. ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From valeriep at openjdk.java.net Wed Jun 2 19:43:49 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 19:43:49 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 03:26:03 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 975: >> >>> 973: doUpdate(in, inOff, inLen, output, 0); >>> 974: } catch (ShortBufferException e) { >>> 975: // update decryption has no output >> >> The comment does not seems to make sense? This is GCMEncrypt class. The right reason should be that the output array is allocated by the provider and should have the right size. However, it seems safer to throw AssertionException() instead of swallowing the SBE... > > Yeah the comment isn't right. I think it's excessive to throw an exception that should never happen, but I'll add a ProviderException. Sure. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1030: >> >>> 1028: inOfs += inLenUsed; >>> 1029: inLen -= inLenUsed; >>> 1030: outOfs += blockSize; >> >> 'blockSize' should be 'len'? > > Either is fine because len and blockSize will be the same. Hmm, re-reading the code, I see why you chose to use blockSize since line 1055 uses "len += ..." so whether len==blockSize depends on the code in line 1022-1054. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1055: >> >>> 1053: // remainder offset is based on original buffer length >>> 1054: ibuffer.write(in, inOfs + inLen, remainder); >>> 1055: } >> >> I wonder if these update(byte[], int, int, byte[], int) calls (such as the one on line 1045) should take ibuffer and stores the unprocessed bytes into it. This way seems more robust and you won't need separate logic. Same comment for the doUpdate() taking ByteBuffer arguments. > > Do you mean having all the GCM interface implementations have an argument that takes ibuffer and adds any unprocessed data into? Maybe it would save a copy of the code, but I'm not sure I like GCTR or GHASH adding data into the ibuffer. Maybe there are other alternatives than making GCTR/GHASH to write into ibuffer. Or, perhaps we can figure out the right input length when passing them to GCTR or GHASH? This is again more for readability and robustness. What you have works, just need to be very careful and require detailed tracking/knowledge on GCTR/GHASH level since all inputs are passed down, but not all are used. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1163: >> >>> 1161: r = doUpdate(buffer, 0, bufLen, out, outOfs); >>> 1162: bufLen -= r; >>> 1163: inOfs += r; >> >> Would bufLen >= blockSize? Regardless, 'inOfs' should not be touched as 'in' is not used in the above doUpdate() call. > > removing it Ok. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1174: >> >>> 1172: inLen -= r; >>> 1173: r = gctrghash.update(block, 0, blockSize, out, >>> 1174: outOfs + resultLen); >> >> I don't follow why you don't update the 'outOfs' after the line 1161 doUpdate() call and then add the resultLen when calling gctrhash.update(...) here. Seems fragile and difficult to maintain? > > i cleaned it up.. all the += or -+ are annoying, but not there is much i can do Ok, will wait for the commit. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1213: >> >>> 1211: >>> 1212: // copy the tag to the end of the buffer >>> 1213: System.arraycopy(block, 0, out, resultLen + outOfs, tagLenBytes); >> >> Now that the tag is copied to the output, why not increment resultLen w/ tagLenBytes? This way, you don't have to keep repeating the (resultLen + tagLenBytes) for another two times? > > yeah, that got changed after this comment Ok. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1317: >> >>> 1315: * If tagOfs = 0, 'in' contains only the tag >>> 1316: * if tagOfs = blockSize, there is no data in 'in' and all the tag >>> 1317: * is in ibuffer >> >> Is this correct? mergeBlock() returns the number of used bytes from 'in', if no data is in 'in' and all the tag is from 'ibuffer', tagOfs should equal to -tagLenBytes. The next line should be moved up as the tag position gradually shifts from 'in' toward 'ibuffer'. The tagOfs for the next line should be -tagLenBytes < tagOfs < 0? > > Yeah, I reworkded it Ok, will wait for the commit. >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1401: >> >>> 1399: ShortBufferException { >>> 1400: GHASH save = null; >>> 1401: >> >> Should do ArrayUtil.nullAndBoundsCheck() on 'in'? > > that was done in engineDoFinal Right. Would be nice to place the same checks at the same level for consistency. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From mcimadamore at openjdk.java.net Wed Jun 2 20:17:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:17:20 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v2] In-Reply-To: References: Message-ID: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/01d9c198..2b668f7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 20:17:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:17:22 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > _Mailing list message from [Chapman Flack](mailto:chap at anastigmatix.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_ > > On 06/02/21 13:30, Maurizio Cimadamore wrote: > > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` > > abstraction, a functional interface. Crucially, `SymbolLookup` does not > > concern with library loading, only symbol lookup. For this reason, two > > factories are added: > > Hi, > > While I am thinking about this, what will be the behavior when the JVM > itself has been dynamically loaded into an embedding application, and > launched with the JNI invocation API? > > Will there be a *Lookup flavor that is able to find any exported symbol > known in the embedding environment the JVM was loaded into? (This is the > sort of condition the Mac OS linker checks when given the -bundle_loader > option.) > > Regards, > Chapman Flack (maintainer of a project that happens to work that way) Hi, at the moment we don't have plans to add such a lookup, but I believe it should be possible to build such a lookup using `dlopen` and the linker API. I have provided an example elsewhere of how easy it easy to build a wrapper lookup around dlopen/dlsym: https://gist.github.com/mcimadamore/0883ea6f4836ae0c1d2a31c48197da1a Perhaps something like that could be useful in the use case you mention? ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From ascarpino at openjdk.java.net Wed Jun 2 20:26:50 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 20:26:50 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 01:19:44 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix perf problem by reorganizing doLastBlock() > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1610: > >> 1608: // update the input parameters for what was taken out of 'in' >> 1609: inOfs += inUsed; >> 1610: inLen -= inUsed; > > This merge block code won't be needed if inLen == 0, i.e. can just assign in to be buffer, inOfs to 0, and inLen to bufRemaining. You are correct, but it's not that simple to handle this case without adding more if()'s which I've found can slow down overall performance. I'm hesitant change this code for this case ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Wed Jun 2 20:31:50 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Jun 2021 20:31:50 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v5] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 20:33:33 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments update > > test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java line 673: > >> 671: >> 672: // Test update-update-doFinal with byte arrays and preset data sizes >> 673: t = new GCMBufferTest("AES/GCM/NoPadding", > > This change seems un-necessary? Why separating the declaration to line 631? I just decided it was better to have the declaration that is used more than once at the top. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From psandoz at openjdk.java.net Wed Jun 2 20:40:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 20:40:47 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v2] In-Reply-To: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> References: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> Message-ID: On Wed, 2 Jun 2021 20:17:20 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java > > Co-authored-by: Jorn Vernee Looks good. Just minor comments to accept/reject. The shim library is an interesting approach. I did wonder if the libvm library could be used, but it might have some weird side-effects or bring in more symbols than necessary. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 138: > 136: *

> 137: * This method is restricted. > 138: * Restricted method are unsafe, and, if used incorrectly, their use might crash Suggestion: * Restricted methods are unsafe, and, if used incorrectly, their use might crash src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 160: > 158: * to allocate structs returned by-value. > 159: * > 160: * @see SymbolLookup For JDK code it is more common for `@See` to occur after the parameters/return/throws, and before any `@Since`. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 418: > 416: private static class AllocHolder { > 417: > 418: private static final CLinker linker = getSystemLinker(); Suggestion: private static final CLinker SYS_LINKER = getSystemLinker(); test/jdk/java/foreign/SafeFunctionAccessTest.java line 53: > 51: ); > 52: > 53: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/StdLibTest.java line 158: > 156: static class StdLibHelper { > 157: > 158: final static SymbolLookup LOOKUP; Suggestion: static final SymbolLookup LOOKUP; test/jdk/java/foreign/TestDowncall.java line 60: > 58: } > 59: > 60: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestIllegalLink.java line 48: > 46: public class TestIllegalLink { > 47: > 48: private static final MemoryAddress dummyTarget = MemoryAddress.ofLong(1); Suggestion: private static final MemoryAddress DUMMY_TARGET = MemoryAddress.ofLong(1); test/jdk/java/foreign/TestIntrinsics.java line 60: > 58: } > 59: > 60: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestSymbolLookup.java line 50: > 48: } > 49: > 50: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestUpcall.java line 69: > 67: static CLinker abi = CLinker.getInstance(); > 68: > 69: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestVarArgs.java line 68: > 66: } > 67: > 68: static final MemoryAddress varargsAddr = Suggestion: static final MemoryAddress VARARGS_ADDR = test/jdk/java/foreign/valist/VaListTest.java line 74: > 72: } > 73: > 74: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 20:59:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:59:25 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v3] In-Reply-To: References: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> Message-ID: On Wed, 2 Jun 2021 18:40:48 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Update test/jdk/java/foreign/TestIntrinsics.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/valist/VaListTest.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestVarArgs.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestUpcall.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestIllegalLink.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestSymbolLookup.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestDowncall.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/StdLibTest.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/SafeFunctionAccessTest.java >> >> Co-authored-by: Paul Sandoz >> - Update src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java >> >> Co-authored-by: Paul Sandoz > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 138: > >> 136: *

>> 137: * This method is restricted. >> 138: * Restricted method are unsafe, and, if used incorrectly, their use might crash > > Suggestion: > > * Restricted methods are unsafe, and, if used incorrectly, their use might crash Ouch - this seems like an issue with _all_ restricted methods. > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 160: > >> 158: * to allocate structs returned by-value. >> 159: * >> 160: * @see SymbolLookup > > For JDK code it is more common for `@See` to occur after the parameters/return/throws, and before any `@Since`. I'll fix ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 20:59:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:59:20 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v3] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision: - Update test/jdk/java/foreign/TestIntrinsics.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestVarArgs.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestUpcall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestIllegalLink.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestSymbolLookup.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestDowncall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/StdLibTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/SafeFunctionAccessTest.java Co-authored-by: Paul Sandoz - Update src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/2b668f7c..41ab74b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=01-02 Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 21:09:24 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 21:09:24 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v4] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/41ab74b6..7be87eae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=02-03 Stats: 42 lines in 13 files changed: 6 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From valeriep at openjdk.java.net Wed Jun 2 21:34:49 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Jun 2021 21:34:49 GMT Subject: Integrated: 8248268: Support KWP in addition to KW In-Reply-To: References: Message-ID: On Thu, 4 Feb 2021 10:51:12 GMT, Valerie Peng wrote: > This change updates SunJCE provider as below: > - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. > - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding. > > Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. > > Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 136badb1 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/136badb1f7b0ba1d16fcf0deca5899e0d0186fc0 Stats: 2780 lines in 18 files changed: 2105 ins; 557 del; 118 mod 8248268: Support KWP in addition to KW Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/2404 From wetmore at openjdk.java.net Wed Jun 2 22:02:52 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Jun 2021 22:02:52 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v2] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Replace missing annotation - Merge branch 'master' into JDK-8267485 - Updated copyright date. - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java ------------- Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=01 Stats: 20 lines in 1 file changed: 10 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Wed Jun 2 22:08:38 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Jun 2021 22:08:38 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v2] In-Reply-To: <6iOfQ7_D1wWlWXvI5bfZreE-dyJhqkfc3qqhDoWP-y8=.437e61d6-ce46-491f-8602-8419f8c2caaf@github.com> References: <6iOfQ7_D1wWlWXvI5bfZreE-dyJhqkfc3qqhDoWP-y8=.437e61d6-ce46-491f-8602-8419f8c2caaf@github.com> Message-ID: On Wed, 2 Jun 2021 18:18:46 GMT, Daniel Fuchs wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Replace missing annotation >> - Merge branch 'master' into JDK-8267485 >> - Updated copyright date. >> - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java > > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 107: > >> 105: List stack = StackWalker.getInstance( >> 106: StackWalker.Option.RETAIN_CLASS_REFERENCE) >> 107: .walk((s) -> s.collect(Collectors.toList())); > > StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE) will require a permission check. > As long as the SecurityManager is still functional, doesn't this mean that creating the StackWalker should be performed in a doPrivileged? If so maybe it should be done in a (possibly static) initializer. Or is it intentional to check that the caller (and the whole calling stack) posses the `RuntimePermission("getStackWalkerWithClassReference")`? Good catch, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Wed Jun 2 23:15:46 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Jun 2021 23:15:46 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Address codereview comments - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Replace missing annotation - Merge branch 'master' into JDK-8267485 - Updated copyright date. - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java ------------- Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=02 Stats: 24 lines in 1 file changed: 14 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From peter.firmstone at zeus.net.au Wed Jun 2 23:41:46 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 3 Jun 2021 09:41:46 +1000 Subject: Authorization Layer post JEP 411 Message-ID: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> A comment from Ron highlites our issue: > the JDK contains only things that either only the JDK can technically do We have a need to distinguish between different sources of code, as well as user principles, and as well as Services.?? Our services are loaded by separate ClassLoaders and are to some extent sandboxed as Ron's example suggests. And we have a need to control access based on these entities. We have always strived to be cross platform and tested on other JVM's such as J9. It's just very hard to see any solutions without AccessController and AccessControlContext. We don't need SecurityManager (although we still need a Policy provider, because ProtectionDomain calls it, but we don't need a policy implementation, just the provider, feel free to remove Java's PolicyFile implementation), if we added a provider interface to Guard.check and changed all permission checks to call their superclass method Guard.check. That authorization layer provider could be called Authority and it can have one single method: Authority::confirm(Permission p) throws SecurityException; We need the power of AccessController's stack walk, StackWalker doesn't work with compiled code, only bytecode. AccessController and AccessControlContext allow backward compatiblity for JAAS.?? JAAS whether we like it or not, is the default authorisation layer framework. http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ We could create a new property that bypasses the AccessController's stack walk for those who don't need to control CodeSource access. (Just create a ProtectionDomain containing a Subject). Benefits: With SecurityManager gone, people will no longer assume it has sole responsible for Security and OpenJDK devs won't carry a significant burden for it's maintenance.? Any security issues will be the responsibility of third party implementations, like mine. The JDK won't provide an implementation, just the framework. Those of us using the Principle of Least Privilege can continue to do so and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. JAAS will continue to remain functional and it's performance will increase significantly (it performs very well with my Policy implementation, even with stack walks). -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chap at anastigmatix.net Thu Jun 3 00:04:43 2021 From: chap at anastigmatix.net (Chapman Flack) Date: Wed, 2 Jun 2021 20:04:43 -0400 Subject: Authorization Layer post JEP 411 In-Reply-To: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> Message-ID: <60B81C9B.70408@anastigmatix.net> On 06/02/21 19:41, Peter Firmstone wrote: > We need the power of AccessController's stack walk, StackWalker doesn't work > with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distinguish much between JITed and interpreted code. Even getByteCodeIndex does not mention any limitation when the frame is JITed Java code (though it does say it will return a negative number in the distinct case of an actual native method). Regards, -Chap From coffeys at openjdk.java.net Thu Jun 3 06:48:41 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 3 Jun 2021 06:48:41 GMT Subject: Integrated: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote: > Added capability to allow the PKCS11 Token to be destroyed once a session is logged out from. New configuration properties via pkcs11 config file. Cleaned up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng This pull request has now been integrated. Changeset: bdeaeb47 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/bdeaeb47d0155b9f233274cff90334e8dd761aae Stats: 573 lines in 11 files changed: 467 ins; 68 del; 38 mod 8240256: Better resource cleaning for SunPKCS11 Provider Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From Alan.Bateman at oracle.com Thu Jun 3 07:18:18 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Jun 2021 08:18:18 +0100 Subject: Authorization Layer post JEP 411 In-Reply-To: <60B81C9B.70408@anastigmatix.net> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <60B81C9B.70408@anastigmatix.net> Message-ID: <2118aae2-b0f5-6c53-e6f2-9e3f2134c0d2@oracle.com> On 03/06/2021 01:04, Chapman Flack wrote: > On 06/02/21 19:41, Peter Firmstone wrote: >> We need the power of AccessController's stack walk, StackWalker doesn't work >> with compiled code, only bytecode. > Is this correct? I have not tried it, but the apidocs had led me to > understand it did not distinguish much between JITed and interpreted code. > Even getByteCodeIndex does not mention any limitation when the frame is > JITed Java code (though it does say it will return a negative number in > the distinct case of an actual native method). > There should be no issue here. I suspect Peter meant that the stack walker is about walking Java frames, it's transparent whether there are interpreter frames, compiled frame, or a mix on the stack. -Alan From peter.firmstone at zeus.net.au Thu Jun 3 07:28:40 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 3 Jun 2021 17:28:40 +1000 Subject: Authorization Layer post JEP 411 In-Reply-To: <2118aae2-b0f5-6c53-e6f2-9e3f2134c0d2@oracle.com> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <60B81C9B.70408@anastigmatix.net> <2118aae2-b0f5-6c53-e6f2-9e3f2134c0d2@oracle.com> Message-ID: Apologies, I meant when compiled to native code, when you ship native binaries. Having said that, if it's necessary to use StackWalker behind AccessController.doPrivileged going forward then lets do so, and maybe the native binary is a later feature. Hopefully my proposal is getting some consideration. -- Regards, Peter. On 3/06/2021 5:18 pm, Alan Bateman wrote: > > > On 03/06/2021 01:04, Chapman Flack wrote: >> On 06/02/21 19:41, Peter Firmstone wrote: >>> We need the power of AccessController's stack walk, StackWalker >>> doesn't work >>> with compiled code, only bytecode. >> Is this correct? I have not tried it, but the apidocs had led me to >> understand it did not distinguish much between JITed and interpreted >> code. >> Even getByteCodeIndex does not mention any limitation when the frame is >> JITed Java code (though it does say it will return a negative number in >> the distinct case of an actual native method). >> > There should be no issue here. I suspect Peter meant that the stack > walker is about walking Java frames, it's transparent whether there > are interpreter frames, compiled frame, or a mix on the stack. > > -Alan From dfuchs at openjdk.java.net Thu Jun 3 08:30:39 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Jun 2021 08:30:39 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Address codereview comments > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Replace missing annotation > - Merge branch 'master' into JDK-8267485 > - Updated copyright date. > - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111: > 109: Option.RETAIN_CLASS_REFERENCE) > 110: .walk((s) -> s.collect(Collectors.toList()))); > 111: Note: StackWalker is a stateless capability object. It's not the walk() method that requires a permission, but the creation of the StackWalker itself (hence my suggestion to create it in the constructor, or in a static initializer). If you walk the stack from within a doPrivileged call then the doPrivileged frame will appear in the returned `List`; this may (or may not) be OK - depending on the logic that processes the stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From adinn at redhat.com Thu Jun 3 08:47:43 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 3 Jun 2021 09:47:43 +0100 Subject: Authorization Layer post JEP 411 In-Reply-To: References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <60B81C9B.70408@anastigmatix.net> <2118aae2-b0f5-6c53-e6f2-9e3f2134c0d2@oracle.com> Message-ID: On 03/06/2021 08:28, Peter Firmstone wrote: > Apologies, I meant when compiled to native code, when you ship native > binaries. I'm not sure what you mean here. Are you talking about native binaries as generated by the GraalVM Native Image Generator? If you are suggesting there is a disparity in behaviour between any such image and the original app running on the JVM - whether specifically with respect to how the stack walk APIs operate or more generally -- then I'd be very interested to know the full details. Note however that were any such disparity to exist then there is no onus on the OpenJDK project to react to it. OpenJDK is based on a well defined standard and is not beholden to decisions made by other projects about how to translate Java code into a delivered executable. > Having said that, if it's necessary to use StackWalker behind > AccessController.doPrivileged going forward then lets do so, and maybe > the native binary is a later feature. > > Hopefully my proposal is getting some consideration. If you are proposing a change to Java then I think recommend that you propose it relative to the current reference implementation of the Java Language (and JVM) standards i.e. OpenJDK. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From ron.pressler at oracle.com Thu Jun 3 09:33:10 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 3 Jun 2021 09:33:10 +0000 Subject: [External] : Authorization Layer post JEP 411 In-Reply-To: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> Message-ID: <65C57BDB-4F67-44C8-AA04-197788498626@oracle.com> > On 3 Jun 2021, at 00:41, Peter Firmstone wrote: > > > StackWalker doesn't work with compiled code, only bytecode. If you?re referring to GraalVM?s Native Image, I don?t know about that problem and there does seem to be a relevant patch (https://github.com/oracle/graal/pull/734), but Native Image is a separate project from OpenJDK. > > AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. > > http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ I don?t know how much a seven-year-old article, that predates Java 8 supports the use of the present tense, but in any event, the JEP says that JAAS will be preserved. > > With SecurityManager gone, people will no longer assume it has sole responsible for Security People don?t assume that now, as secure software doesn?t employ it even today. People do, however, assume that the mechanism, if used, is robust enough to be used for security purposes. > OpenJDK devs won't carry a significant burden for it's maintenance. While the number of places where the JDK *implements* some ?protected operation?, like opening a file or writing to a socket, is somewhat bounded ? and so keeping some hooks in those places *might* be reasonable ? the number of places that *use* those operations is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant burden. > Any security issues will be the responsibility of third party implementations, like mine. > The JDK won't provide an implementation, just the framework. But the correct use of doPrivileged, if you?re proposing that it?s kept, must still be tested against *some* implementation, and OpenJDK would still need to fix bugs related to it. > > Those of us using the Principle of Least Privilege can continue to do so Perhaps you believe that the only software in the world that applies Least Privilege is Java software that employs the Security Manager, but that is not how most people, including the person who had framed it two decades prior to the invention of the Security Manager, understand the principle. The original statement of the principle was: "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.? (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939) You are talking about applying the principle at a granularity of code units that are smaller than a program. It?s fine to believe that is worthwhile, but the principle certainly doesn?t require that every effort be expended to afford least privilege at any granularity. > and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. I think you?re underestimating the magnitude of this work, which potentially interacts with each and every change in the JDK (and in practice interacts with many of them, and today it?s done by those who are responsible for the relevant change), which you?ll need to monitor, not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, would still have to review that work. However, if you think that is an amount of work you could manage, perhaps it could be done outside the JDK using Java Agents. > > JAAS will continue to remain functional The JEP already intends to keep JAAS functional, as far as I can tell. ? Ron From peter.firmstone at zeus.net.au Thu Jun 3 09:43:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 3 Jun 2021 19:43:32 +1000 Subject: [External] : Authorization Layer post JEP 411 In-Reply-To: <65C57BDB-4F67-44C8-AA04-197788498626@oracle.com> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <65C57BDB-4F67-44C8-AA04-197788498626@oracle.com> Message-ID: <539284f6-d2a0-9d0b-2e94-ba58aeddcd38@zeus.net.au> Ok, thanks Ron, I think we are confirming that Java, post version 17, will not meet the security needs our software.? It's time I accepted that and moved on. Thanks for your time. Have you seen my latest article on foojay??? Feel free to comment and let me know what you think. https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/ Cheers, Peter. On 3/06/2021 7:33 pm, Ron Pressler wrote: > >> On 3 Jun 2021, at 00:41, Peter Firmstone wrote: >> >> >> StackWalker doesn't work with compiled code, only bytecode. > If you?re referring to GraalVM?s Native Image, I don?t know about that problem and > there does seem to be a relevant patch (https://github.com/oracle/graal/pull/734), but > Native Image is a separate project from OpenJDK. > >> AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. >> >> http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ > I don?t know how much a seven-year-old article, that predates Java 8 supports the use > of the present tense, but in any event, the JEP says that JAAS will be preserved. > >> With SecurityManager gone, people will no longer assume it has sole responsible for Security > People don?t assume that now, as secure software doesn?t employ it even today. People do, > however, assume that the mechanism, if used, is robust enough to be used for security > purposes. > >> OpenJDK devs won't carry a significant burden for it's maintenance. > While the number of places where the JDK *implements* some ?protected operation?, like > opening a file or writing to a socket, is somewhat bounded ? and so keeping some hooks > in those places *might* be reasonable ? the number of places that *use* those operations > is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant > burden. > > >> Any security issues will be the responsibility of third party implementations, like mine. >> The JDK won't provide an implementation, just the framework. > But the correct use of doPrivileged, if you?re proposing that it?s kept, must still be > tested against *some* implementation, and OpenJDK would still need to fix bugs related > to it. > >> Those of us using the Principle of Least Privilege can continue to do so > Perhaps you believe that the only software in the world that applies Least Privilege is > Java software that employs the Security Manager, but that is not how most people, including > the person who had framed it two decades prior to the invention of the Security Manager, > understand the principle. > > The original statement of the principle was: "Every program and every privileged user of > the system should operate using the least amount of privilege necessary to complete the > job.? (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939) > > You are talking about applying the principle at a granularity of code units that are > smaller than a program. It?s fine to believe that is worthwhile, but the principle > certainly doesn?t require that every effort be expended to afford least privilege at > any granularity. > >> and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. > I think you?re underestimating the magnitude of this work, which potentially interacts with > each and every change in the JDK (and in practice interacts with many of them, and today it?s > done by those who are responsible for the relevant change), which you?ll need to monitor, > not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, > would still have to review that work. > > However, if you think that is an amount of work you could manage, perhaps it could be done > outside the JDK using Java Agents. > >> JAAS will continue to remain functional > The JEP already intends to keep JAAS functional, as far as I can tell. > > ? Ron From ron.pressler at oracle.com Thu Jun 3 09:58:36 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 3 Jun 2021 09:58:36 +0000 Subject: [External] : Authorization Layer post JEP 411 In-Reply-To: <539284f6-d2a0-9d0b-2e94-ba58aeddcd38@zeus.net.au> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <65C57BDB-4F67-44C8-AA04-197788498626@oracle.com> <539284f6-d2a0-9d0b-2e94-ba58aeddcd38@zeus.net.au> Message-ID: <38EFE93E-9D3B-418A-950E-038B5BFF94A2@oracle.com> It is certainly time to accept that JEP 411 has been accepted, and so that those who use Security Manager will need to do some work to change their software. The purpose of this and upcoming discussions is to find reasonable approaches that might relieve some portion of the burden on those who use SM today while not placing an undue (indirect) burden on those who do not. ? Ron > On 3 Jun 2021, at 10:43, Peter Firmstone wrote: > > Ok, thanks Ron, > > I think we are confirming that Java, post version 17, will not meet the security needs our software. It's time I accepted that and moved on. > > Thanks for your time. > > Have you seen my latest article on foojay? Feel free to comment and let me know what you think. > > https://urldefense.com/v3/__https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$ > Cheers, > > Peter. > > > On 3/06/2021 7:33 pm, Ron Pressler wrote: >> >>> On 3 Jun 2021, at 00:41, Peter Firmstone wrote: >>> >>> >>> StackWalker doesn't work with compiled code, only bytecode. >> If you?re referring to GraalVM?s Native Image, I don?t know about that problem and >> there does seem to be a relevant patch (https://urldefense.com/v3/__https://github.com/oracle/graal/pull/734__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-DV8ldZw$ ), but >> Native Image is a separate project from OpenJDK. >> >>> AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. >>> >>> https://urldefense.com/v3/__http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-R7C-0Hg$ >> I don?t know how much a seven-year-old article, that predates Java 8 supports the use >> of the present tense, but in any event, the JEP says that JAAS will be preserved. >> >>> With SecurityManager gone, people will no longer assume it has sole responsible for Security >> People don?t assume that now, as secure software doesn?t employ it even today. People do, >> however, assume that the mechanism, if used, is robust enough to be used for security >> purposes. >> >>> OpenJDK devs won't carry a significant burden for it's maintenance. >> While the number of places where the JDK *implements* some ?protected operation?, like >> opening a file or writing to a socket, is somewhat bounded ? and so keeping some hooks >> in those places *might* be reasonable ? the number of places that *use* those operations >> is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant >> burden. >> >> >>> Any security issues will be the responsibility of third party implementations, like mine. >>> The JDK won't provide an implementation, just the framework. >> But the correct use of doPrivileged, if you?re proposing that it?s kept, must still be >> tested against *some* implementation, and OpenJDK would still need to fix bugs related >> to it. >> >>> Those of us using the Principle of Least Privilege can continue to do so >> Perhaps you believe that the only software in the world that applies Least Privilege is >> Java software that employs the Security Manager, but that is not how most people, including >> the person who had framed it two decades prior to the invention of the Security Manager, >> understand the principle. >> >> The original statement of the principle was: "Every program and every privileged user of >> the system should operate using the least amount of privilege necessary to complete the >> job.? (https://urldefense.com/v3/__https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-xd8krsA$ ) >> >> You are talking about applying the principle at a granularity of code units that are >> smaller than a program. It?s fine to believe that is worthwhile, but the principle >> certainly doesn?t require that every effort be expended to afford least privilege at >> any granularity. >> >>> and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. >> I think you?re underestimating the magnitude of this work, which potentially interacts with >> each and every change in the JDK (and in practice interacts with many of them, and today it?s >> done by those who are responsible for the relevant change), which you?ll need to monitor, >> not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, >> would still have to review that work. >> >> However, if you think that is an amount of work you could manage, perhaps it could be done >> outside the JDK using Java Agents. >> >>> JAAS will continue to remain functional >> The JEP already intends to keep JAAS functional, as far as I can tell. >> >> ? Ron > From peter.firmstone at zeus.net.au Thu Jun 3 10:13:43 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 3 Jun 2021 20:13:43 +1000 Subject: [External] : Authorization Layer post JEP 411 In-Reply-To: <38EFE93E-9D3B-418A-950E-038B5BFF94A2@oracle.com> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <65C57BDB-4F67-44C8-AA04-197788498626@oracle.com> <539284f6-d2a0-9d0b-2e94-ba58aeddcd38@zeus.net.au> <38EFE93E-9D3B-418A-950E-038B5BFF94A2@oracle.com> Message-ID: <15482570-3580-de2c-562b-e303f1459ec5@zeus.net.au> Yes, I think so too.? However I will encourage developers to continue to take advantage of SM for improved security now, there's no need to rush to abandon it. Maybe in future there will be better alternatives, but it's the best option for those who are security focused now. With time no doubt hardening that will occur to the Java platform as OpenJDK responds to vulnerabilities, it will become the most secure option again, but I think that's a number of years away and I'd rather be conservative than get burned. If SM deprecation doesn't impact your use case, then yes I would encourage you to upgrade, because that's the sensible thing to do. I'll still test on later versions, but I won't be removing our authorization system until I'm satisfied there are sufficiently hardened alternative technologies available. Thank you, Peter. On 3/06/2021 7:58 pm, Ron Pressler wrote: > It is certainly time to accept that JEP 411 has been accepted, and so that those > who use Security Manager will need to do some work to change their software. > > The purpose of this and upcoming discussions is to find reasonable approaches > that might relieve some portion of the burden on those who use SM today while > not placing an undue (indirect) burden on those who do not. > > ? Ron > >> On 3 Jun 2021, at 10:43, Peter Firmstone wrote: >> >> Ok, thanks Ron, >> >> I think we are confirming that Java, post version 17, will not meet the security needs our software. It's time I accepted that and moved on. >> >> Thanks for your time. >> >> Have you seen my latest article on foojay? Feel free to comment and let me know what you think. >> >> https://urldefense.com/v3/__https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$ >> Cheers, >> >> Peter. >> >> >> On 3/06/2021 7:33 pm, Ron Pressler wrote: >>>> On 3 Jun 2021, at 00:41, Peter Firmstone wrote: >>>> >>>> >>>> StackWalker doesn't work with compiled code, only bytecode. >>> If you?re referring to GraalVM?s Native Image, I don?t know about that problem and >>> there does seem to be a relevant patch (https://urldefense.com/v3/__https://github.com/oracle/graal/pull/734__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-DV8ldZw$ ), but >>> Native Image is a separate project from OpenJDK. >>> >>>> AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. >>>> >>>> https://urldefense.com/v3/__http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-R7C-0Hg$ >>> I don?t know how much a seven-year-old article, that predates Java 8 supports the use >>> of the present tense, but in any event, the JEP says that JAAS will be preserved. >>> >>>> With SecurityManager gone, people will no longer assume it has sole responsible for Security >>> People don?t assume that now, as secure software doesn?t employ it even today. People do, >>> however, assume that the mechanism, if used, is robust enough to be used for security >>> purposes. >>> >>>> OpenJDK devs won't carry a significant burden for it's maintenance. >>> While the number of places where the JDK *implements* some ?protected operation?, like >>> opening a file or writing to a socket, is somewhat bounded ? and so keeping some hooks >>> in those places *might* be reasonable ? the number of places that *use* those operations >>> is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant >>> burden. >>> >>> >>>> Any security issues will be the responsibility of third party implementations, like mine. >>>> The JDK won't provide an implementation, just the framework. >>> But the correct use of doPrivileged, if you?re proposing that it?s kept, must still be >>> tested against *some* implementation, and OpenJDK would still need to fix bugs related >>> to it. >>> >>>> Those of us using the Principle of Least Privilege can continue to do so >>> Perhaps you believe that the only software in the world that applies Least Privilege is >>> Java software that employs the Security Manager, but that is not how most people, including >>> the person who had framed it two decades prior to the invention of the Security Manager, >>> understand the principle. >>> >>> The original statement of the principle was: "Every program and every privileged user of >>> the system should operate using the least amount of privilege necessary to complete the >>> job.? (https://urldefense.com/v3/__https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-xd8krsA$ ) >>> >>> You are talking about applying the principle at a granularity of code units that are >>> smaller than a program. It?s fine to believe that is worthwhile, but the principle >>> certainly doesn?t require that every effort be expended to afford least privilege at >>> any granularity. >>> >>>> and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. >>> I think you?re underestimating the magnitude of this work, which potentially interacts with >>> each and every change in the JDK (and in practice interacts with many of them, and today it?s >>> done by those who are responsible for the relevant change), which you?ll need to monitor, >>> not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, >>> would still have to review that work. >>> >>> However, if you think that is an amount of work you could manage, perhaps it could be done >>> outside the JDK using Java Agents. >>> >>>> JAAS will continue to remain functional >>> The JEP already intends to keep JAAS functional, as far as I can tell. >>> >>> ? Ron -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From coffeys at openjdk.java.net Thu Jun 3 11:17:53 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 3 Jun 2021 11:17:53 GMT Subject: RFR: 8268167: MultipleLogins.java failure on macosx-aarch64 Message-ID: MultipleLogins.java should skip test where NSS support is not present ------------- Commit messages: - 8268167: MultipleLogins.java failure on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/4333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268167 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4333/head:pull/4333 PR: https://git.openjdk.java.net/jdk/pull/4333 From weijun at openjdk.java.net Thu Jun 3 13:36:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Jun 2021 13:36:33 GMT Subject: RFR: 8268167: MultipleLogins.java failure on macosx-aarch64 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:10:10 GMT, Sean Coffey wrote: > MultipleLogins.java should skip test where NSS support is not present Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4333 From coffeys at openjdk.java.net Thu Jun 3 13:50:42 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 3 Jun 2021 13:50:42 GMT Subject: Integrated: 8268167: MultipleLogins.java failure on macosx-aarch64 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:10:10 GMT, Sean Coffey wrote: > MultipleLogins.java should skip test where NSS support is not present This pull request has now been integrated. Changeset: eb385c0d Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/eb385c0de2026d6b184ce0c98ff421a4da95e1b1 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8268167: MultipleLogins.java failure on macosx-aarch64 Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/4333 From mullan at openjdk.java.net Thu Jun 3 14:27:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 3 Jun 2021 14:27:38 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Address codereview comments > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Replace missing annotation > - Merge branch 'master' into JDK-8267485 > - Updated copyright date. > - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 50: > 48: * @since 1.4 > 49: */ > 50: @SuppressWarnings("removal") You should remove this annotation now that the dependency on SecurityManager has been removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From mullan at openjdk.java.net Thu Jun 3 14:37:46 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 3 Jun 2021 14:37:46 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 23:15:46 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Address codereview comments > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Replace missing annotation > - Merge branch 'master' into JDK-8267485 > - Updated copyright date. > - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java I would remove line 44 from the comments as it is no longer applicable: *

Note that this security manager is never installed, only instantiated. Also, you may want to rename this class to something other than JceSecurityManager to avoid future confusion, maybe "JcePolicyManager". ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From sean.mullan at oracle.com Thu Jun 3 15:02:58 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 3 Jun 2021 11:02:58 -0400 Subject: Authorization Layer post JEP 411 In-Reply-To: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> Message-ID: <34dea374-9e22-ff29-952c-f5b183f63950@oracle.com> On 6/2/21 7:41 PM, Peter Firmstone wrote: > AccessController and AccessControlContext allow backward compatiblity > for JAAS.?? JAAS whether we like it or not, is the default authorisation > layer framework. > > http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ > I'm not sure why you referenced this blog which is actually advocating that JAAS has *less* dependency on Security Manager APIs such as AccessControlContext, whereas you seem to be advocating the opposite. In any case, I believe the first two issues in this blog will largely be addressed by the deprecation of the Security Manager and the JAAS related RFEs that we have filed as follow-on work to JEP 411 to remove the dependencies on the SM APIs: https://bugs.openjdk.java.net/browse/JDK-8266592 https://bugs.openjdk.java.net/browse/JDK-8267108 As for the 3rd issue in the blog, it is not related to the Security Manager, but I would need more time to understand the issues that were described. Also the blog was written by David Lloyd who has been participating in these discussions, so he may want to say more about it. --Sean From ascarpino at openjdk.java.net Thu Jun 3 16:04:19 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 3 Jun 2021 16:04:19 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: > Hi, > > I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. > > Thanks > > Tony Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: - missed resultLen and undo decrypt heap hasarray check - code review comments - fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4072/files - new: https://git.openjdk.java.net/jdk/pull/4072/files/d230e665..c5e19250 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=06-07 Stats: 199 lines in 3 files changed: 20 ins; 123 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/4072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072 PR: https://git.openjdk.java.net/jdk/pull/4072 From fguallini at openjdk.java.net Thu Jun 3 16:09:43 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 3 Jun 2021 16:09:43 GMT Subject: Integrated: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" In-Reply-To: References: Message-ID: <6WYDA6FSceA-JLMcxVU38SG2OsCT2QKxeW-8XV3AZjM=.d1a95eff-256e-439a-9bdd-4afd4f036e77@github.com> On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) > > Since SocketExceptions are not wrapped into SSLException, also need to be caught. Other tests that were expecting a SSLException to be thrown under certain condition were updated with a similar fix in the change previously mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for client/server synchronization This pull request has now been integrated. Changeset: 3aa7062c Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/3aa7062c3dd41e06df67b46473ee2ef5a9671cf9 Stats: 14 lines in 2 files changed: 0 ins; 3 del; 11 mod 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception" Reviewed-by: rhalade, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4308 From mcimadamore at openjdk.java.net Thu Jun 3 16:39:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:39:25 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v5] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Forgot to add makefile for building shim library ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/7be87eae..6480332c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=03-04 Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Thu Jun 3 16:43:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:43:51 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v6] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into symbolLookup - Forgot to add makefile for building shim library - Address review comments - Update test/jdk/java/foreign/TestIntrinsics.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestVarArgs.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestUpcall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestIllegalLink.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestSymbolLookup.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestDowncall.java Co-authored-by: Paul Sandoz - ... and 6 more: https://git.openjdk.java.net/jdk/compare/52d8215a...2545e2b6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=05 Stats: 1351 lines in 47 files changed: 626 ins; 621 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From wetmore at openjdk.java.net Thu Jun 3 17:47:46 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Jun 2021 17:47:46 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 14:20:37 GMT, Sean Mullan wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Address codereview comments >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Replace missing annotation >> - Merge branch 'master' into JDK-8267485 >> - Updated copyright date. >> - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java > > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 50: > >> 48: * @since 1.4 >> 49: */ >> 50: @SuppressWarnings("removal") > > You should remove this annotation now that the dependency on SecurityManager has been removed. Unfortunately, we are still calling AccessController, thus the annotation needs to remain. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Thu Jun 3 17:47:49 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Jun 2021 17:47:49 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: <4EZJ_OnKIWlbMJ7JalqKEBxALm-jEbcYh-wr9cyNexs=.0f93d4dd-9b88-48ea-bde2-41cca4d0ee9d@github.com> On Thu, 3 Jun 2021 08:27:14 GMT, Daniel Fuchs wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Address codereview comments >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Replace missing annotation >> - Merge branch 'master' into JDK-8267485 >> - Updated copyright date. >> - 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java > > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111: > >> 109: Option.RETAIN_CLASS_REFERENCE) >> 110: .walk((s) -> s.collect(Collectors.toList()))); >> 111: > > Note: StackWalker is a stateless capability object. It's not the walk() method that requires a permission, but the creation of the StackWalker itself (hence my suggestion to create it in the constructor, or in a static initializer). If you walk the stack from within a doPrivileged call then the doPrivileged frame will appear in the returned `List`; this may (or may not) be OK - depending on the logic that processes the stack. > > You could consider simplifying: > > > PrivilegedAction pa = () -> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); > final List stack = AccessController.doPrivileged(pa).walk(Stream::toList); Thanks. I was going to step through this code more thoroughly today, hopefully I would have caught that. This code is only needed in certain deployment and Cipher creation situations, so would rather not create a static CodeWalker that is not normally used. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From dfuchs at openjdk.java.net Thu Jun 3 18:01:38 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Jun 2021 18:01:38 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:44:42 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 50: >> >>> 48: * @since 1.4 >>> 49: */ >>> 50: @SuppressWarnings("removal") >> >> You should remove this annotation now that the dependency on SecurityManager has been removed. > > Unfortunately, we are still calling AccessController, thus the annotation needs to remain. But if you follow my suggestion you can simply apply it to this line: @SuppressWarnings("removal") final List stack = AccessController.doPrivileged(pa).walk(Stream::toList); ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From dfuchs at openjdk.java.net Thu Jun 3 18:07:39 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Jun 2021 18:07:39 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: <4EZJ_OnKIWlbMJ7JalqKEBxALm-jEbcYh-wr9cyNexs=.0f93d4dd-9b88-48ea-bde2-41cca4d0ee9d@github.com> References: <4EZJ_OnKIWlbMJ7JalqKEBxALm-jEbcYh-wr9cyNexs=.0f93d4dd-9b88-48ea-bde2-41cca4d0ee9d@github.com> Message-ID: On Thu, 3 Jun 2021 17:44:22 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 111: >> >>> 109: Option.RETAIN_CLASS_REFERENCE) >>> 110: .walk((s) -> s.collect(Collectors.toList()))); >>> 111: >> >> Note: StackWalker is a stateless capability object. It's not the walk() method that requires a permission, but the creation of the StackWalker itself (hence my suggestion to create it in the constructor, or in a static initializer). If you walk the stack from within a doPrivileged call then the doPrivileged frame will appear in the returned `List`; this may (or may not) be OK - depending on the logic that processes the stack. >> >> You could consider simplifying: >> >> >> PrivilegedAction pa = () -> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE); >> final List stack = AccessController.doPrivileged(pa).walk(Stream::toList); > > Thanks. I was going to step through this code more thoroughly today, hopefully I would have caught that. > > This code is only needed in certain deployment and Cipher creation situations, so would rather not create a static CodeWalker that is not normally used. Fair enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From erikj at openjdk.java.net Thu Jun 3 18:24:43 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 18:24:43 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v6] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:43:51 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into symbolLookup > - Forgot to add makefile for building shim library > - Address review comments > - Update test/jdk/java/foreign/TestIntrinsics.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/valist/VaListTest.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestVarArgs.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestUpcall.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestIllegalLink.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestSymbolLookup.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestDowncall.java > > Co-authored-by: Paul Sandoz > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/52d8215a...2545e2b6 Looks pretty good, just a few comments. make/modules/jdk.incubator.foreign/Lib.gmk line 28: > 26: include LibCommon.gmk > 27: > 28: ifeq ($(call isTargetOs, linux), true) Please indent everything inside the ifeq-block 2 spaces. (See http://openjdk.java.net/groups/build/doc/code-conventions.html) make/modules/jdk.incubator.foreign/Lib.gmk line 34: > 32: CFLAGS := $(CFLAGS_JDKLIB), \ > 33: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ > 34: LDFLAGS := -Wl$(COMMA)--no-as-needed -lc -lm -ldl $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN), \ Unless you link with any other library in the JDK (typically libjava and/or libjvm), I don't think there is a need for adding SET_SHARED_LIBRARY_ORIGIN. Please put all the -l* flags in LIBS rather than LDFLAGS. I also recommend putting any additional flags after the general LDFLAGS_JDKLIB. That way you are guaranteed that your flag takes precedence over anything that may be added to LDFLAGS_JDKLIB in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From valeriep at openjdk.java.net Thu Jun 3 19:15:54 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 19:15:54 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: > > - missed resultLen and undo decrypt heap hasarray check > - code review comments > - fix src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 84: > 82: private static final int MAX_BUF_SIZE = Integer.MAX_VALUE; > 83: // data size when buffer is divided up to aid in intrinsics > 84: private static final int TRIGGERLEN = 4096; // 64k nit: comment should be 4k? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Thu Jun 3 20:49:13 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 3 Jun 2021 20:49:13 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 19:13:00 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: >> >> - missed resultLen and undo decrypt heap hasarray check >> - code review comments >> - fix > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 84: > >> 82: private static final int MAX_BUF_SIZE = Integer.MAX_VALUE; >> 83: // data size when buffer is divided up to aid in intrinsics >> 84: private static final int TRIGGERLEN = 4096; // 64k > > nit: comment should be 4k? Ack.. I changed it to test something and forgot to change it back.. I'll put it back to 64k with the merge-conflict ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From mcimadamore at openjdk.java.net Thu Jun 3 20:49:44 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 20:49:44 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments on shim lib makefile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/2545e2b6..23d66faf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=05-06 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From wetmore at openjdk.java.net Thu Jun 3 20:51:57 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Jun 2021 20:51:57 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: Message-ID: <6x9J3vIJYIRF5zT7_mKnKvJXihlfPtgfpI4h3Pbox3Q=.e8df709e-b799-466f-80d1-7110ee3dba81@github.com> On Thu, 3 Jun 2021 17:58:45 GMT, Daniel Fuchs wrote: >> Unfortunately, we are still calling AccessController, thus the annotation needs to remain. > > But if you follow my suggestion you can simply apply it to this line: > > > @SuppressWarnings("removal") > final List stack = AccessController.doPrivileged(pa).walk(Stream::toList); For the static initializer that needs updating: I could move the code out of the initializer up to the declaration, or I could create a dummy declaration and then assign to INSTANCE. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From peter.firmstone at zeus.net.au Thu Jun 3 21:39:44 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 4 Jun 2021 07:39:44 +1000 Subject: Authorization Layer post JEP 411 In-Reply-To: <34dea374-9e22-ff29-952c-f5b183f63950@oracle.com> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <34dea374-9e22-ff29-952c-f5b183f63950@oracle.com> Message-ID: <348b796f-df35-e3ea-5e21-131e6e33c109@zeus.net.au> Hi Sean, Developers are still going to need single points of control, where we can attach our agents to Java's API's.?? We can't be playing a game of whack a mole trying to lock down the JDK. It's fair enough that OpenJDK no longer wishes to maintain SecurityManager, however there are those of us who have to implement authorization layers and access controls and we don't have the luxury of choice. So we've established that we need to use Agents and StackWalker now to implement our authorization layer. It will be some years before we are able to keep up to date with Java releases again, but now we need to focus on how to achieve that. Regarding your questions, the performance problems, were related to Java's FilePolicy implementation, I solved those issues by replacing it, but you're already aware of that, I was highlighting the struggle that developers have with Java security, but also that JAAS is a common foundation for user authorisation, so I hope that it will be improved, rather than removed.? I of course also use JAAS to establish TLS connections. If there's anything else OpenJDK is thinking about, thinking about removing, then we need to know, so we don't use them in our new authorization layer. -- Regards, Peter Firmstone On 4/06/2021 1:02 am, Sean Mullan wrote: > > > On 6/2/21 7:41 PM, Peter Firmstone wrote: >> AccessController and AccessControlContext allow backward compatiblity >> for JAAS.?? JAAS whether we like it or not, is the default >> authorisation layer framework. >> >> http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ >> >> > > I'm not sure why you referenced this blog which is actually advocating > that JAAS has *less* dependency on Security Manager APIs such as > AccessControlContext, whereas you seem to be advocating the opposite. > > In any case, I believe the first two issues in this blog will largely > be addressed by the deprecation of the Security Manager and the JAAS > related RFEs that we have filed as follow-on work to JEP 411 to remove > the dependencies on the SM APIs: > > https://bugs.openjdk.java.net/browse/JDK-8266592 > https://bugs.openjdk.java.net/browse/JDK-8267108 > > As for the 3rd issue in the blog, it is not related to the Security > Manager, but I would need more time to understand the issues that were > described. > > Also the blog was written by David Lloyd who has been participating in > these discussions, so he may want to say more about it. > > --Sean From mullan at openjdk.java.net Thu Jun 3 21:43:56 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 3 Jun 2021 21:43:56 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: <6x9J3vIJYIRF5zT7_mKnKvJXihlfPtgfpI4h3Pbox3Q=.e8df709e-b799-466f-80d1-7110ee3dba81@github.com> References: <6x9J3vIJYIRF5zT7_mKnKvJXihlfPtgfpI4h3Pbox3Q=.e8df709e-b799-466f-80d1-7110ee3dba81@github.com> Message-ID: On Thu, 3 Jun 2021 20:49:27 GMT, Bradford Wetmore wrote: >> But if you follow my suggestion you can simply apply it to this line: >> >> >> @SuppressWarnings("removal") >> final List stack = AccessController.doPrivileged(pa).walk(Stream::toList); > > For the static initializer that needs updating: I could move the code out of the initializer up to the declaration, or I could create a dummy declaration and then assign to INSTANCE. The latter is probably better so you don't have to move the code; @wangweij used this technique quite a bit for JEP 411 refactoring, see https://github.com/openjdk/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From wetmore at openjdk.java.net Thu Jun 3 21:52:56 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Jun 2021 21:52:56 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: <6x9J3vIJYIRF5zT7_mKnKvJXihlfPtgfpI4h3Pbox3Q=.e8df709e-b799-466f-80d1-7110ee3dba81@github.com> Message-ID: On Thu, 3 Jun 2021 21:41:02 GMT, Sean Mullan wrote: >> For the static initializer that needs updating: I could move the code out of the initializer up to the declaration, or I could create a dummy declaration and then assign to INSTANCE. > > The latter is probably better so you don't have to move the code; @wangweij used this technique quite a bit for JEP 411 refactoring, see https://github.com/openjdk/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b @seanjmullan , that's what I ended up doing. I'll have a new revision out as soon as the mach5 finishes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From weijun at openjdk.java.net Thu Jun 3 21:56:01 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Jun 2021 21:56:01 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v3] In-Reply-To: References: <6x9J3vIJYIRF5zT7_mKnKvJXihlfPtgfpI4h3Pbox3Q=.e8df709e-b799-466f-80d1-7110ee3dba81@github.com> Message-ID: On Thu, 3 Jun 2021 21:50:32 GMT, Bradford Wetmore wrote: >> The latter is probably better so you don't have to move the code; @wangweij used this technique quite a bit for JEP 411 refactoring, see https://github.com/openjdk/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b > > @seanjmullan , that's what I ended up doing. I'll have a new revision out as soon as the mach5 finishes. In this case, I name the variable `tmp`. There are cases where the action is a `PrivlegedAction` and you still have to create a variable for the return value, and then I call it `dummy`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From valeriep at openjdk.java.net Thu Jun 3 21:56:13 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 21:56:13 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:23:38 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1610: >> >>> 1608: // update the input parameters for what was taken out of 'in' >>> 1609: inOfs += inUsed; >>> 1610: inLen -= inUsed; >> >> This merge block code won't be needed if inLen == 0, i.e. can just assign in to be buffer, inOfs to 0, and inLen to bufRemaining. > > You are correct, but it's not that simple to handle this case without adding more if()'s which I've found can slow down overall performance. I'm hesitant change this code for this case Ok, perhaps most often than not inLen != 0, so not worthwhile to check this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From peter.firmstone at zeus.net.au Thu Jun 3 21:59:40 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 4 Jun 2021 07:59:40 +1000 Subject: Authorization Layer post JEP 411 In-Reply-To: <348b796f-df35-e3ea-5e21-131e6e33c109@zeus.net.au> References: <15440ea3-5281-7a16-c409-2bc7a83934c5@zeus.net.au> <34dea374-9e22-ff29-952c-f5b183f63950@oracle.com> <348b796f-df35-e3ea-5e21-131e6e33c109@zeus.net.au> Message-ID: <64e61442-b439-a057-b562-faa6d30f14ef@zeus.net.au> Sean, Also moving forward we currently preserve AccessControlContext across threads, and we do this to establish TLS connections for call backs. Will there be a new way to preserve the calling Subject across threads, so we can perform callbacks over TLS? Regards, -- Regards, Peter Firmstone On 4/06/2021 7:39 am, Peter Firmstone wrote: > Hi Sean, > > Developers are still going to need single points of control, where we > can attach our agents to Java's API's.?? We can't be playing a game of > whack a mole trying to lock down the JDK. > > It's fair enough that OpenJDK no longer wishes to maintain > SecurityManager, however there are those of us who have to implement > authorization layers and access controls and we don't have the luxury > of choice. > > So we've established that we need to use Agents and StackWalker now to > implement our authorization layer. > > It will be some years before we are able to keep up to date with Java > releases again, but now we need to focus on how to achieve that. > > Regarding your questions, the performance problems, were related to > Java's FilePolicy implementation, I solved those issues by replacing > it, but you're already aware of that, I was highlighting the struggle > that developers have with Java security, but also that JAAS is a > common foundation for user authorisation, so I hope that it will be > improved, rather than removed.? I of course also use JAAS to establish > TLS connections. > > If there's anything else OpenJDK is thinking about, thinking about > removing, then we need to know, so we don't use them in our new > authorization layer. > From valeriep at openjdk.java.net Thu Jun 3 22:00:10 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 22:00:10 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:45:41 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 84: >> >>> 82: private static final int MAX_BUF_SIZE = Integer.MAX_VALUE; >>> 83: // data size when buffer is divided up to aid in intrinsics >>> 84: private static final int TRIGGERLEN = 4096; // 64k >> >> nit: comment should be 4k? > > Ack.. I changed it to test something and forgot to change it back.. I'll put it back to 64k with the merge-conflict Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Thu Jun 3 22:11:16 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 22:11:16 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: > > - missed resultLen and undo decrypt heap hasarray check > - code review comments > - fix src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 776: > 774: if (dst != null) { > 775: dst.put(block, 0, len); > 776: } Can this be "resultLen += op.doFinal(block, 0, len, dst)"? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From wetmore at openjdk.java.net Thu Jun 3 22:27:16 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Thu, 3 Jun 2021 22:27:16 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - More Codereview Comments - Merge branch 'master' into JDK-8267485 - Minor typo - Reduced SuppressWarnings scope - Codereview Comments #2 - Merge branch 'master' into JDK-8267485 - Address codereview comments - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9f05c411...a441778b ------------- Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=03 Stats: 30 lines in 1 file changed: 15 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From valeriep at openjdk.java.net Thu Jun 3 22:34:07 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 22:34:07 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 03:18:49 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 942: >> >>> 940: >>> 941: System.arraycopy(out, originalOutOfs, originalOut, originalOutOfs, >>> 942: len); >> >> Don't you need to do `originalOut = null;` after copying the bytes over? Otherwise, if you have two overlapping calls with the same engine, the 2nd restoreOut(...) call may lead to data corruption, i.e. it will duplicate the output bytes to the original output buffer (in the 1st overlapping call). >> Same applies for the ByteBuffer case, i.e. restoreDst(...). >> If time permits, please add a regression test to cover this. > > A engine is a one time use, so setting originalOut to null isn't necessary. engineDoFinal() sets engine = null. engine is one time use per encryption/decryption. But 'originalOut' is for overlap detection/protection which may be used multiple times during multi-part encryption/decrypion. For each overlapDetection()/restoreOut() pair, the 'originalOut' value should be cleared, otherwise there may be cases where the old value of 'originalOut' gets used? ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From valeriep at openjdk.java.net Thu Jun 3 22:42:11 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 3 Jun 2021 22:42:11 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:04:19 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. >> >> Thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: > > - missed resultLen and undo decrypt heap hasarray check > - code review comments > - fix Update changes look good. Just a nit and the issue with originalOut remains. Thanks, Valerie ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4072 From mchung at openjdk.java.net Thu Jun 3 22:52:00 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Jun 2021 22:52:00 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4] In-Reply-To: References: Message-ID: <92Z5Af2b59tgNDOjI2OjDc58GoM1E-44FLpHhufmM1I=.d3ed2f82-b73d-4a26-83ef-cc5bf5827235@github.com> On Thu, 3 Jun 2021 22:27:16 GMT, Bradford Wetmore wrote: >> The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. >> >> The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. >> >> I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. > > Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - More Codereview Comments > - Merge branch 'master' into JDK-8267485 > - Minor typo > - Reduced SuppressWarnings scope > - Codereview Comments #2 > - Merge branch 'master' into JDK-8267485 > - Address codereview comments > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - Merge branch 'master' into JDK-8267485 > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9f05c411...a441778b src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 109: > 107: @SuppressWarnings("removal") > 108: List stack = > 109: AccessController.doPrivileged(pa).walk(Stream::toList); You can replace line 108-125 with something like this: StackWalker walker = AccessController.doPrivileged(pa); Optional callerCodeBase = walker.walk(s -> { s.map(f -> JceSecurity.getCodeBase(f.getDeclaringClass())) .findFirst(); }); src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 245: > 243: @SuppressWarnings("removal") > 244: Optional stackFrame = AccessController.doPrivileged(pa) > 245: .walk((s) -> s.skip(2).findFirst()); You can use the same `StackWalker` instance in multiple places. `StackWalker::getCallerClass` is the API to get the caller class. You want to get the caller of the subclass of `Cipher` in this case. So `Cipher` constructor will call `walker.getCallerClass()` and then pass it to `isCallerTrusted` which will take an additional caller class parameter for validation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From ascarpino at openjdk.java.net Fri Jun 4 00:20:10 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 4 Jun 2021 00:20:10 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: References: Message-ID: <5oygqQ1JEDr6CBYurgqI7AEDQrkhclx9INQruwAcOw0=.98d194e5-f54b-45e7-80d8-3f4a46af8b5f@github.com> On Thu, 3 Jun 2021 22:07:34 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with three additional commits since the last revision: >> >> - missed resultLen and undo decrypt heap hasarray check >> - code review comments >> - fix > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 776: > >> 774: if (dst != null) { >> 775: dst.put(block, 0, len); >> 776: } > > Can this be "resultLen += op.doFinal(block, 0, len, dst)"? doFinal doesn't have a (byte[], int, int, ByteBuffer) method. While that's not a bad idea to have one, it would be a fair bit of code to do it because it's part of the GCM interface and I'd have to write methods for GCTRGHASH, GCTR, and GHASH. I think that's too much just for this one code segment that isn't broken. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From ascarpino at openjdk.java.net Fri Jun 4 01:33:12 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 4 Jun 2021 01:33:12 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 22:30:38 GMT, Valerie Peng wrote: >> A engine is a one time use, so setting originalOut to null isn't necessary. engineDoFinal() sets engine = null. > > engine is one time use per encryption/decryption. But 'originalOut' is for overlap detection/protection which may be used multiple times during multi-part encryption/decrypion. For each overlapDetection()/restoreOut() pair, the 'originalOut' value should be cleared, otherwise there may be cases where the old value of 'originalOut' gets used? Ok. I see what you are saying. I had not consider a situation where an update buffer overlapped and doFinal did not. I'll set originalDst and originalOut to null on their restore methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From peter.firmstone at zeus.net.au Fri Jun 4 04:22:14 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 4 Jun 2021 14:22:14 +1000 Subject: JEP 411: Documentation on the new way to establish TLS connections Message-ID: Could someone please advise the recommended way now to preserve the Subject in Executors to establish a TLS connection? I am unable to find the documentation. We use Executors and we preserve the calling Subject across them, to use for authentication our TLS endpoints. This is now deprecated in Java 17, because it uses AccessController and AccessControlContext? methods. I would like to do this in a way that's not deprecated? Just wondering if anyone has any suggestions? Ron mentioned on Reddit this morning that there are no new API's being developed. https://bugs.openjdk.java.net/browse/JDK-8267108 Is the assumption that the JDK will be a single user process, so the subject just needs to be stored in a Static variable and accessed from there instead? Just wondering what the use case scenario is? This really sux for us, because we authenticate TLS connections, then we run the users with their calling Subjects. Thank you. https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java I'm kinda getting the feeling that I'm no longer welcome here. I recognize that I'm pushing back, and people don't like that, however I'm doing so because I am impacted by the recent decision, I can assure you I have no personal grudges against anyone. I'm not looking for assurances that that isn't the case, I just want some guidance, I think our whole code base and how we use Java, just bit the dust. -- Regards, Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Fri Jun 4 04:53:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 4 Jun 2021 14:53:20 +1000 Subject: JEP 411: Documentation on the new way to establish TLS connections In-Reply-To: References: Message-ID: <057aa8a3-03d5-8184-1c5a-5a31d1446c9a@zeus.net.au> Don't bother replying. I found that it is actually on the TODO list. https://bugs.openjdk.java.net/browse/JDK-8266592 I've had enough now anyway, there is no fixing this mess. Sayonara. On 4/06/2021 2:22 pm, Peter Firmstone wrote: > Could someone please advise the recommended way now to preserve the > Subject in Executors to establish a TLS connection? > > I am unable to find the documentation. > > We use Executors and we preserve the calling Subject across them, to > use for authentication our TLS endpoints. > > This is now deprecated in Java 17, because it uses AccessController > and AccessControlContext? methods. > > I would like to do this in a way that's not deprecated? > > Just wondering if anyone has any suggestions? > > Ron mentioned on Reddit this morning that there are no new API's being > developed. > > https://bugs.openjdk.java.net/browse/JDK-8267108 > > Is the assumption that the JDK will be a single user process, so the > subject just needs to be stored in a Static variable and accessed from > there instead? > > Just wondering what the use case scenario is? > > This really sux for us, because we authenticate TLS connections, then > we run the users with their calling Subjects. > > Thank you. > > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/FilterX509TrustManager.java > > https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/ssl/SubjectCredentials.java > > > I'm kinda getting the feeling that I'm no longer welcome here. > > I recognize that I'm pushing back, and people don't like that, however > I'm doing so because I am impacted by the recent decision, I can > assure you I have no personal grudges against anyone. > > I'm not looking for assurances that that isn't the case, I just want > some guidance, I think our whole code base and how we use Java, just > bit the dust. > > -- > Regards, > > Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 4 06:39:27 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Jun 2021 07:39:27 +0100 Subject: JEP 411: Documentation on the new way to establish TLS connections In-Reply-To: References: Message-ID: On 04/06/2021 05:22, Peter Firmstone wrote: > Could someone please advise the recommended way now to preserve the > Subject in Executors to establish a TLS connection? > I think the primitive you are looking for is scope local variables. It's still in the exploration phase but there is a draft JEP [1]. I'm quite sure that if we did this 20 years ago then Subject.doAs and friends would be different. -Alan [1] http://openjdk.java.net/jeps/8263012 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ascarpino at openjdk.java.net Fri Jun 4 06:51:35 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 4 Jun 2021 06:51:35 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v9] In-Reply-To: References: Message-ID: <_gNn18fPzgItmImiBYueA6aPNCaTXtOcJn-jIKhNmhU=.c7c15dde-79aa-49c1-8e5d-94a253381a99@github.com> > Hi, > > I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. > > Thanks > > Tony Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - merge, and a few nits - Merge branch 'master' into perfphase1 - left 4k test length for trigger - missed resultLen and undo decrypt heap hasarray check - code review comments - fix - Remove GCTR reset() calls because GCTR is released after the operation some variable name consistency other small cleanup - Review comments update - Review comments update - Fix perf problem by reorganizing doLastBlock() - ... and 19 more: https://git.openjdk.java.net/jdk/compare/b9558655...d84d302b ------------- Changes: https://git.openjdk.java.net/jdk/pull/4072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=08 Stats: 2783 lines in 15 files changed: 1309 ins; 767 del; 707 mod Patch: https://git.openjdk.java.net/jdk/pull/4072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072 PR: https://git.openjdk.java.net/jdk/pull/4072 From michael.osipov at siemens.com Fri Jun 4 06:56:13 2021 From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM)) Date: Fri, 4 Jun 2021 08:56:13 +0200 Subject: Backporting [JDK-8160818] GssKrb5Client violates RFC 4752 Message-ID: <55d9adc1-e5b1-f3ec-52d7-759631f506a4@siemens.com> Hi Max, thank you for fixing my bug. I have finally verified it to properly work just as specified in the RFC with AdoptOpenJDK 16 on Windows. Do you see any chance to have this small change to be backported to 8 and 11? If this is the wrong list should this go to jdk8u-dev@? Regards, Michael From dfuchs at openjdk.java.net Fri Jun 4 10:19:03 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Jun 2021 10:19:03 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4] In-Reply-To: <92Z5Af2b59tgNDOjI2OjDc58GoM1E-44FLpHhufmM1I=.d3ed2f82-b73d-4a26-83ef-cc5bf5827235@github.com> References: <92Z5Af2b59tgNDOjI2OjDc58GoM1E-44FLpHhufmM1I=.d3ed2f82-b73d-4a26-83ef-cc5bf5827235@github.com> Message-ID: On Thu, 3 Jun 2021 22:48:45 GMT, Mandy Chung wrote: >> Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - More Codereview Comments >> - Merge branch 'master' into JDK-8267485 >> - Minor typo >> - Reduced SuppressWarnings scope >> - Codereview Comments #2 >> - Merge branch 'master' into JDK-8267485 >> - Address codereview comments >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - Merge branch 'master' into JDK-8267485 >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9f05c411...a441778b > > src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 109: > >> 107: @SuppressWarnings("removal") >> 108: List stack = >> 109: AccessController.doPrivileged(pa).walk(Stream::toList); > > You can replace line 108-125 with something like this: > > StackWalker walker = AccessController.doPrivileged(pa); > Optional callerCodeBase = walker.walk(s -> { > s.map(f -> JceSecurity.getCodeBase(f.getDeclaringClass())) > .findFirst(); > }); @mlchung Maybe there should be a `.filter(cb -> cb != null)` inserted before `.findFirst()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From ewhelan at openjdk.java.net Fri Jun 4 10:52:17 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Fri, 4 Jun 2021 10:52:17 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed Message-ID: Hi, Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. Regards, Evan ------------- Commit messages: - Remove othervm mode - 8255148: Confusing log output: SSLSocket duplex close failed Changes: https://git.openjdk.java.net/jdk/pull/4354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255148 Stats: 108 lines in 2 files changed: 104 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4354/head:pull/4354 PR: https://git.openjdk.java.net/jdk/pull/4354 From mcimadamore at openjdk.java.net Fri Jun 4 12:56:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 12:56:02 GMT Subject: Integrated: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. This pull request has now been integrated. Changeset: 59a539fe Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/59a539fef12dec6ba8af8a41000829402e7e9b72 Stats: 1351 lines in 47 files changed: 626 ins; 621 del; 104 mod 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Reviewed-by: jvernee, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mullan at openjdk.java.net Fri Jun 4 14:11:57 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Jun 2021 14:11:57 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 10:44:32 GMT, Evan Whelan wrote: > Hi, > > Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. > > Regards, > Evan src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 590: > 588: // ignore the exception > 589: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { > 590: SSLLogger.warning("SSLSocket duplex close failed. Debug info only. Exception details:", ioe); If this is a debug message, shouldn't we just use `SSLLogger.fine()` instead of `SSLLogger.warning()`, with the same message "SSLSocket duplex close failed"? @coffeys what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From weijun at openjdk.java.net Fri Jun 4 15:03:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 4 Jun 2021 15:03:58 GMT Subject: RFR: 8179880: Refactor javax/security shell tests to plain java tests In-Reply-To: <6D0YuwvankICr5b9piuXuWPHQNX7jpVqmcLsZvnNj_o=.0b8591a9-9cc1-4609-9e47-72b280089a65@github.com> References: <6D0YuwvankICr5b9piuXuWPHQNX7jpVqmcLsZvnNj_o=.0b8591a9-9cc1-4609-9e47-72b280089a65@github.com> Message-ID: On Thu, 27 May 2021 08:52:20 GMT, Sibabrata Sahoo wrote: > This change converts JTREG shell Test scripts to Java equivalent. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4220 From mchung at openjdk.java.net Fri Jun 4 16:42:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Jun 2021 16:42:59 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v4] In-Reply-To: References: <92Z5Af2b59tgNDOjI2OjDc58GoM1E-44FLpHhufmM1I=.d3ed2f82-b73d-4a26-83ef-cc5bf5827235@github.com> Message-ID: On Fri, 4 Jun 2021 10:14:21 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/javax/crypto/JceSecurityManager.java line 109: >> >>> 107: @SuppressWarnings("removal") >>> 108: List stack = >>> 109: AccessController.doPrivileged(pa).walk(Stream::toList); >> >> You can replace line 108-125 with something like this: >> >> StackWalker walker = AccessController.doPrivileged(pa); >> Optional callerCodeBase = walker.walk(s -> { >> s.map(f -> JceSecurity.getCodeBase(f.getDeclaringClass())) >> .findFirst(); >> }); > > @mlchung Maybe there should be a `.filter(cb -> cb != null)` inserted before `.findFirst()`? Daniel is right and it needs the filter to find the first non-null code base. ------------- PR: https://git.openjdk.java.net/jdk/pull/4150 From valeriep at openjdk.java.net Fri Jun 4 18:35:11 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 4 Jun 2021 18:35:11 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v8] In-Reply-To: <5oygqQ1JEDr6CBYurgqI7AEDQrkhclx9INQruwAcOw0=.98d194e5-f54b-45e7-80d8-3f4a46af8b5f@github.com> References: <5oygqQ1JEDr6CBYurgqI7AEDQrkhclx9INQruwAcOw0=.98d194e5-f54b-45e7-80d8-3f4a46af8b5f@github.com> Message-ID: On Fri, 4 Jun 2021 00:16:55 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 776: >> >>> 774: if (dst != null) { >>> 775: dst.put(block, 0, len); >>> 776: } >> >> Can this be "resultLen += op.doFinal(block, 0, len, dst)"? > > doFinal doesn't have a (byte[], int, int, ByteBuffer) method. While that's not a bad idea to have one, it would be a fair bit of code to do it because it's part of the GCM interface and I'd have to write methods for GCTRGHASH, GCTR, and GHASH. I think that's too much just for this one code segment that isn't broken. Sure, sounds reasonable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From svkamath at openjdk.java.net Fri Jun 4 23:49:31 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 4 Jun 2021 23:49:31 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: > I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4019/files - new: https://git.openjdk.java.net/jdk/pull/4019/files/433176d1..2ac209e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=00-01 Stats: 58 lines in 10 files changed: 3 ins; 28 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/4019.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019 PR: https://git.openjdk.java.net/jdk/pull/4019 From ssahoo at openjdk.java.net Sat Jun 5 08:00:05 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Sat, 5 Jun 2021 08:00:05 GMT Subject: Integrated: 8179880: Refactor javax/security shell tests to plain java tests In-Reply-To: <6D0YuwvankICr5b9piuXuWPHQNX7jpVqmcLsZvnNj_o=.0b8591a9-9cc1-4609-9e47-72b280089a65@github.com> References: <6D0YuwvankICr5b9piuXuWPHQNX7jpVqmcLsZvnNj_o=.0b8591a9-9cc1-4609-9e47-72b280089a65@github.com> Message-ID: On Thu, 27 May 2021 08:52:20 GMT, Sibabrata Sahoo wrote: > This change converts JTREG shell Test scripts to Java equivalent. This pull request has now been integrated. Changeset: 7f55dc15 Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/7f55dc15769bbab59024aa49671bced633de40ed Stats: 99 lines in 2 files changed: 11 ins; 80 del; 8 mod 8179880: Refactor javax/security shell tests to plain java tests Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/4220 From valeriep at openjdk.java.net Mon Jun 7 13:32:17 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 7 Jun 2021 13:32:17 GMT Subject: RFR: 8255557: Decouple GCM from CipherCore [v4] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 01:29:36 GMT, Anthony Scarpino wrote: >> engine is one time use per encryption/decryption. But 'originalOut' is for overlap detection/protection which may be used multiple times during multi-part encryption/decrypion. For each overlapDetection()/restoreOut() pair, the 'originalOut' value should be cleared, otherwise there may be cases where the old value of 'originalOut' gets used? > > Ok. I see what you are saying. I had not consider a situation where an update buffer overlapped and doFinal did not. I'll set originalDst and originalOut to null on their restore methods. Great. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From weijun at openjdk.java.net Mon Jun 7 21:06:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 7 Jun 2021 21:06:33 GMT Subject: RFR: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Message-ID: <3EV9-5XxjMjrMdcCz4xcHQf0rRoqgH0HBb4Ym3Qe3eY=.d5d15d83-769b-4121-92df-8cd4d09b01eb@github.com> The test must run with sudo but I forgot to mention it. New comment and a better error message is added. ------------- Commit messages: - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Changes: https://git.openjdk.java.net/jdk/pull/4401/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4401&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268093 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4401.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4401/head:pull/4401 PR: https://git.openjdk.java.net/jdk/pull/4401 From ascarpino at openjdk.java.net Mon Jun 7 22:26:37 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 7 Jun 2021 22:26:37 GMT Subject: Integrated: 8255557: Decouple GCM from CipherCore In-Reply-To: References: Message-ID: <202cXErHhdkTR938jBEZsOC0FmNC3ZrKb8AJO7qwk1Y=.76b6290b-0131-496f-928e-7f75c8e5a743@github.com> On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this rather large change to GCM. GCM will no longer use CipherCore, and AESCrypt to handle it's buffers and other objects. It is also a major code redesign limits the amount of data copies and make some performance-based decisions. > > Thanks > > Tony This pull request has now been integrated. Changeset: c7c77fd3 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/c7c77fd32b1b1bc736ef3523456a2968447fc627 Stats: 2783 lines in 15 files changed: 1309 ins; 767 del; 707 mod 8255557: Decouple GCM from CipherCore Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/4072 From alanb at openjdk.java.net Tue Jun 8 06:16:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 06:16:13 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. Changes requested by alanb (Reviewer). src/java.base/share/classes/java/lang/System.java line 331: > 329: > 330: // Remember original System.err. setSecurityManager() warning goes here > 331: private static PrintStream oldErrStream = null; I assume this should needs to be volatile and @Stable. I think we need a better name for it too. src/java.base/share/classes/java/lang/System.java line 336: > 334: // Remember callers of setSecurityManager() here so that warning > 335: // is only printed once for each different caller > 336: final static Map callersOfSSM = new WeakHashMap<>(); You can't use a WeakHashMap without synchronization but a big question here is whether a single caller frame is sufficient. If I were doing this then I think I would capture the hash of a number of stack frames to create a better filter. src/java.base/share/classes/java/lang/System.java line 2219: > 2217: WARNING: java.lang.SecurityManager is deprecated and will be removed in a future release > 2218: WARNING: -Djava.security.manager=%s will have no effect when java.lang.SecurityManager is removed > 2219: """, smProp); Raw strings may be useful here but means the lines length are inconsistent and makes it too hard to look at side by side diffs now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From dholmes at openjdk.java.net Tue Jun 8 06:33:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Jun 2021 06:33:18 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. There are a number of hotspot tests that will trigger this warning, so please ensure they work correctly with the extra output. You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From alanb at openjdk.java.net Tue Jun 8 06:44:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 06:44:19 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote: > You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. The uppercase "WARNING" is intentional here, it was the same with illegal reflective access warnings. I'm sure Max has or will run all tests to see if there are any issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From dfuchs at openjdk.java.net Tue Jun 8 11:16:15 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Jun 2021 11:16:15 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. Changes to LoggerFinderLoaderTest look reasonable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From weijun at openjdk.java.net Tue Jun 8 12:22:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 12:22:15 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: <8Con08J4o54RWaz5vK6omwhiLiLoPTkKooPHEqufJys=.40d6ea48-b98f-4376-aed1-76e3f44ed037@github.com> On Tue, 8 Jun 2021 06:41:11 GMT, Alan Bateman wrote: > > You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. > > The uppercase "WARNING" is intentional here, it was the same with illegal reflective access warnings. I'm sure Max has or will run all tests to see if there are any issues. Will definitely run all from tier1-tier9. I ran them multiple times while implementing JEP 411. I've seen warnings with "VM" word in the prefix and test methods that filter them out, but feel the warnings here are not related to VM. The new warnings do have impacts on some tests and I'll be very carefully not break them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From weijun at openjdk.java.net Tue Jun 8 12:28:16 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 12:28:16 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 06:11:17 GMT, Alan Bateman wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > src/java.base/share/classes/java/lang/System.java line 331: > >> 329: >> 330: // Remember original System.err. setSecurityManager() warning goes here >> 331: private static PrintStream oldErrStream = null; > > I assume this should needs to be volatile and @Stable. I think we need a better name for it too. Will add the modifiers. How about "originalErr"? > src/java.base/share/classes/java/lang/System.java line 336: > >> 334: // Remember callers of setSecurityManager() here so that warning >> 335: // is only printed once for each different caller >> 336: final static Map callersOfSSM = new WeakHashMap<>(); > > You can't use a WeakHashMap without synchronization but a big question here is whether a single caller frame is sufficient. If I were doing this then I think I would capture the hash of a number of stack frames to create a better filter. I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > src/java.base/share/classes/java/lang/System.java line 2219: > >> 2217: WARNING: java.lang.SecurityManager is deprecated and will be removed in a future release >> 2218: WARNING: -Djava.security.manager=%s will have no effect when java.lang.SecurityManager is removed >> 2219: """, smProp); > > Raw strings may be useful here but means the lines length are inconsistent and makes it too hard to look at side by side diffs now. I understand what you mean when I switch to Split View. While I can extract the lines to a method, I somehow think it's not worth doing because for each type of warning the method is only called once. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From akolarkunnu at openjdk.java.net Tue Jun 8 16:06:27 2021 From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu) Date: Tue, 8 Jun 2021 16:06:27 GMT Subject: RFR: 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java Message-ID: ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps. ------------- Commit messages: - 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java - Revert "8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java" - 8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java Changes: https://git.openjdk.java.net/jdk/pull/4413/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4413&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266182 Stats: 37 lines in 1 file changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4413.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4413/head:pull/4413 PR: https://git.openjdk.java.net/jdk/pull/4413 From alanb at openjdk.java.net Tue Jun 8 17:18:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 17:18:17 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote: > I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. > > As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. WeakHashMap access synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From weijun at openjdk.java.net Tue Jun 8 18:26:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 18:26:13 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> On Tue, 8 Jun 2021 17:15:29 GMT, Alan Bateman wrote: >> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >> >> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > >> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >> >> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > > WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary? For the cache, I'm OK to drop it at the moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From alanb at openjdk.java.net Tue Jun 8 18:31:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 18:31:18 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> References: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> Message-ID: On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote: >>> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >>> >>> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. >> >> WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? > > Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary? > > For the cache, I'm OK to drop it at the moment. I think it would be simpler to start out without the caller cache. Sorry the sentence got garbled, I was trying to repeat what I said above that WeakHashMap is not synchronized so you would need to add synchronization to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From github.com+44308314+jackh2000 at openjdk.java.net Tue Jun 8 19:23:31 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Tue, 8 Jun 2021 19:23:31 GMT Subject: RFR: 8240997: Remove more "hack" word in security codes Message-ID: This change is part of a larger code cleanup effort and removes the term "hack" out of several files in the jdk. JBS: [](https://bugs.openjdk.java.net/browse/JDK-8240997 ) ------------- Commit messages: - 8240997: Remove more hack word in security codes Changes: https://git.openjdk.java.net/jdk/pull/4148/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4148&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240997 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4148.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4148/head:pull/4148 PR: https://git.openjdk.java.net/jdk/pull/4148 From robilad at openjdk.java.net Tue Jun 8 19:23:31 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Tue, 8 Jun 2021 19:23:31 GMT Subject: RFR: 8240997: Remove more "hack" word in security codes In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:37:12 GMT, Jack Hartstein wrote: > This change is part of a larger code cleanup effort and removes the term "hack" out of several files in the jdk. > JBS: [](https://bugs.openjdk.java.net/browse/JDK-8240997 ) Hi, Please send me an e-mail at Dalibor.Topic at oracle.com so that I can mark your account as verified. ------------- PR: https://git.openjdk.java.net/jdk/pull/4148 From xuelei at openjdk.java.net Tue Jun 8 21:04:12 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 8 Jun 2021 21:04:12 GMT Subject: RFR: 8240997: Remove more "hack" word in security codes In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:37:12 GMT, Jack Hartstein wrote: > This change is part of a larger code cleanup effort and removes the term "hack" out of several files in the jdk. > JBS: [](https://bugs.openjdk.java.net/browse/JDK-8240997 ) Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4148 From peter.firmstone at zeus.net.au Wed Jun 9 01:35:25 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 9 Jun 2021 11:35:25 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. Message-ID: Apologies in advance if this seems like paranoid security. As you are likely now aware, we have been using SecurityManager a little differently than recommended as we adapted it to our requirements. Sometimes it's not always easy to explain or obvious why something is done in a certain way. It's clear we can use StackWalker to implement AccessController functionality.? And it's also clear we can use ThreadLocal or Scope Local's to preserve the user Subject across threads. Going forward we will need low level hooks in the JDK for our authentication layer, clearly this is an opportunity to further simplify and improve our authentication layer. Because we use a remote service architecture, with proxy's, the proxy's are dynamically granted permission's after Service Authentication, these permissions also require the user principal to be logged in, we may have a number of services on the stack, for example to participate in a transaction. We have a tool to generate least privilege policy files. There are two reasons we do this: 1. Simplicity of administration and auditing of policy files. 2. Limit the permissions of code, and grant certain permissions to users to ensure users are authenticated before allowing data parsing. An example of item two, is our services require users to be logged in to ensure that any data provided by the user is a trusted data source (we still check the data).?? We re-implemented a subset of Java Serialization and have a DeSerializationPermission, which is granted to Principals of users. If a user is not logged in, data cannot be de-serialized, because the code alone doesn't have permission to do so. Hopefully modules and packages will have strong encapsulation in future so we don't need permission's like java.lang.RuntimePermission "accessClassInPackage.*"? No doubt we will need to create our own Permission's. We would like to be able to limit data parsing, like XML or Java de-serialization, to logged in users only. We don't break encapsulation, in future we will only use reflection to call public methods and constructors (we are currently in the process of doing so).?? Our build systems use Maven, our build is modular. I would also like to request that all JDK modules be given ProtectionDomain's following SecurityManager deprecation. Currently some modules have null ProtectionDomain's to show they have AllPermission.? However we don't grant AllPermission to code in practise, we like to grant certain Permission's to Principal's, not code, where the Principal is the source of data, indicating the user has been authenticated and we only grant what's necessary and no more. Examples of permission's granted to JDK modules in POLP policy files, taken from a test harness: grant codebase "jrt:/jdk.security.jgss" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "jrt:/jdk.crypto.mscapi" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; ??? permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "jrt:/jdk.localedata" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "jrt:/jdk.security.auth" { ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; ??? permission javax.security.auth.AuthPermission "modifyPrincipals"; ??? permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; ??? permission javax.security.auth.AuthPermission "modifyPublicCredentials"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; ??? permission java.lang.RuntimePermission "getProtectionDomain"; }; Example of POLP grant to code with principal, code alone cannot access these, in case you are wondering, we use this to secure the RMI Registry using stateless TLSv1.3, it's used by our Service Watchdog, or Service Activation framework called Phoenix, it's the sole use we have of the Java RMI JRMP protocol, in cases where this isn't used we can disable Java Serialization completely: grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", ??? principal javax.security.auth.x500.X500Principal "CN=Phoenix" { ??? permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; ??? permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; ??? permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; ??? permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; ??? permission java.io.FilePermission "harness\\trust\\truststore", "read"; ??? permission java.net.SocketPermission "localhost:1098", "listen,resolve"; }; If we really want to get into detail, instances of GrantPermission shows the permissions that are granted dynamically, in this case you can see that provided the Mahalo Service is run with it's principal CN=Mahalo, it has permission to de-serialize a MarshalledObject (it doesn't actually unmarshall it though, it uses it for equals comparison), the GrantPermission shows that it grants permission to de-serialize (ATOMIC, which means atomic input validation, prior to object creation), after authenticating the proxy's service. grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/mahalo-service-3.1.1-SNAPSHOT.jar", ??? principal javax.security.auth.x500.X500Principal "CN=Mahalo" { ??? permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; ??? permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; ??? permission org.apache.river.phoenix.dl.MonitorPermission "net.jini.activation.arg.ActivationMonitor.inactiveObject"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "connect"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "listen"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Mahalo\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "accept,resolve"; ??? permission java.net.SocketPermission "localhost:0", "listen,resolve"; ??? permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Phoenix\\\"\", \"connect\";"; ??? permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\"; net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Outrigger\\\"\", \"connect\";"; ??? permission net.jini.security.GrantPermission "org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; org.apache.river.api.io.DeSerializationPermission \"MARSHALL\"; org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; java.lang.RuntimePermission \"accessClassInPackage.com.sun.proxy\", \"\";"; ??? permission javax.security.auth.AuthPermission "getSubject"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "delete"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "write"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\mahalo-dl-3.1.1-SNAPSHOT.jar", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\mahalo-service-3.1.1-SNAPSHOT.jar", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\mahalo.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\outrigger.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; ??? permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; ??? permission java.lang.RuntimePermission "getClassLoader"; ??? permission java.lang.RuntimePermission "modifyThread"; ??? permission net.jini.discovery.DiscoveryPermission "QATestDefaultGroup_DESKTOP-R0ORPA2_1623111918992"; }; -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+44308314+jackh2000 at openjdk.java.net Wed Jun 9 02:15:18 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Wed, 9 Jun 2021 02:15:18 GMT Subject: Integrated: 8240997: Remove more "hack" word in security codes In-Reply-To: References: Message-ID: On Fri, 21 May 2021 18:37:12 GMT, Jack Hartstein wrote: > This change is part of a larger code cleanup effort and removes the term "hack" out of several files in the jdk. > JBS: [](https://bugs.openjdk.java.net/browse/JDK-8240997 ) This pull request has now been integrated. Changeset: 58a59e3d Author: Jack Hartstein Committer: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/58a59e3dcb830211e1eef8122c9f7113c00ded4c Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8240997: Remove more "hack" word in security codes Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4148 From peter.firmstone at zeus.net.au Wed Jun 9 02:47:53 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 9 Jun 2021 12:47:53 +1000 Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> Message-ID: <265497c1-d885-e617-8432-d9a8c621e5aa@zeus.net.au> I can re-license some code that decorates Concurrent collections with references, so you can do this without blocking. https://pfirmstone.github.io/JGDMS/jgdms-collections/apidocs/index.html On 9/06/2021 4:31 am, Alan Bateman wrote: > On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote: > >>>> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >>>> >>>> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. >>> WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? >> Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary? >> >> For the cache, I'm OK to drop it at the moment. > I think it would be simpler to start out without the caller cache. Sorry the sentence got garbled, I was trying to repeat what I said above that WeakHashMap is not synchronized so you would need to add synchronization to use it. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4400 -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From dongbohe at openjdk.java.net Wed Jun 9 08:03:36 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Wed, 9 Jun 2021 08:03:36 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance Message-ID: Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. Baseline results before patch: Benchmark (algorithm) Mode Cnt Score Error Units AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op Benchmark results after patch: Benchmark (algorithm) Mode Cnt Score Error Units AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: Before patch: summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 After patch: summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 ------------- Commit messages: - 8268427: Improve AlgorithmConstraints:checkAlgorithm performance Changes: https://git.openjdk.java.net/jdk/pull/4424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268427 Stats: 114 lines in 4 files changed: 85 ins; 11 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424 PR: https://git.openjdk.java.net/jdk/pull/4424 From sean.mullan at oracle.com Wed Jun 9 14:33:53 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Jun 2021 10:33:53 -0400 Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: Message-ID: Nice, the benchmark results look impressive. I'll take a closer look at the patch a little later. --Sean On 6/9/21 4:03 AM, Dongbo He wrote: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op > > Benchmark results after patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op > > SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > ------------- > > Commit messages: > - 8268427: Improve AlgorithmConstraints:checkAlgorithm performance > > Changes: https://git.openjdk.java.net/jdk/pull/4424/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8268427 > Stats: 114 lines in 4 files changed: 85 ins; 11 del; 18 mod > Patch: https://git.openjdk.java.net/jdk/pull/4424.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424 > > PR: https://git.openjdk.java.net/jdk/pull/4424 > From github.com+34924738+mahendrachhipa at openjdk.java.net Wed Jun 9 14:51:21 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Wed, 9 Jun 2021 14:51:21 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, =?UTF-8?B?4oCm?= Message-ID: ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests ------------- Commit messages: - JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests Changes: https://git.openjdk.java.net/jdk/pull/4432/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268464 Stats: 1689 lines in 7 files changed: 118 ins; 1477 del; 94 mod Patch: https://git.openjdk.java.net/jdk/pull/4432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4432/head:pull/4432 PR: https://git.openjdk.java.net/jdk/pull/4432 From sean.mullan at oracle.com Wed Jun 9 15:07:33 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Jun 2021 11:07:33 -0400 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: On 6/8/21 9:35 PM, Peter Firmstone wrote: > I would also like to request that all JDK modules be given > ProtectionDomain's following SecurityManager deprecation. Currently some > modules have null ProtectionDomain's to show they have AllPermission. > However we don't grant AllPermission to code in practise, we like to > grant certain Permission's to Principal's, not code, where the Principal > is the source of data, indicating the user has been authenticated and we > only grant what's necessary and no more. As described in JEP 411, there are no plans to deprecate ProtectionDomain at this time. --Sean From dfuchs at openjdk.java.net Wed Jun 9 15:40:15 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Jun 2021 15:40:15 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests In-Reply-To: References: Message-ID: <2uMSjb_TwhYFZip0__438DViffECdZK3q49nr3vBUPU=.b715996b-3c3f-47be-9d8a-f331795dfbbb@github.com> On Wed, 9 Jun 2021 14:42:23 GMT, Mahendra Chhipa wrote: > ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 116: > 114: String reqbody = ""; > 115: try(InputStream inputStream = req.getRequestBody()) { > 116: if(inputStream != null) { I don't think inputStream can be null, ever. test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 117: > 115: try(InputStream inputStream = req.getRequestBody()) { > 116: if(inputStream != null) { > 117: reqbody = new String(inputStream.readAllBytes()); Please double check that client and server use the same charset. test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 138: > 136: break; > 137: case 2: /* test 3 */ > 138: reqbody = new String(req.getRequestBody().readAllBytes()); Please double check that client and server use the same charset. test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 150: > 148: req.getResponseHeaders().set("Connection", "close"); > 149: req.sendResponseHeaders(200, 0); > 150: try (PrintWriter pw = new PrintWriter(req.getResponseBody())) { It's dangerous to rely on the default charset when using PrintWriter. I'd suggest to change the client and server logic to use UTF-8 explicitly everywhere (when creating new strings, when obtaining string bytes, when using print writers or print streams, etc...) test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 161: > 159: case 4: /* test 7 */ > 160: case 5: /* test 8 */ > 161: reqbody = new String(req.getRequestBody().readAllBytes()); Please double check that client and server use the same charset, or better, explicitly use UTF-8 everywhere. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java line 218: > 216: // if the bug exsits, it'll send 2 GET commands > 217: // check 2nd GET here > 218: String duplicatedGet = trans.getRequestHeaders().getFirst(null); I'm not sure you will be testing the same thing here. You probably can't use the com.sun.net.httpserver.HttpServer for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4432 From coffeys at openjdk.java.net Wed Jun 9 16:21:17 2021 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 9 Jun 2021 16:21:17 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:08:58 GMT, Sean Mullan wrote: >> Hi, >> >> Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. >> >> Regards, >> Evan > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 590: > >> 588: // ignore the exception >> 589: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { >> 590: SSLLogger.warning("SSLSocket duplex close failed. Debug info only. Exception details:", ioe); > > If this is a debug message, shouldn't we just use `SSLLogger.fine()` instead of `SSLLogger.warning()`, with the same message "SSLSocket duplex close failed"? @coffeys what do you think? @seanjmullan - It's the exception stacktrace printed after the message that's causing issue for some. Some are reading it as a JDK functionality issue (when it's not) I've no strong preference whether this should be printed at warning() or fine() level. That granularity is largely broken since JDK 11 - people need to use -Djavax.net.debug=all to get any reasonable amount of data. It would be good to see https://bugs.openjdk.java.net/browse/JDK-8044609 worked on. I think the patch looks ok as ie. Evan has fixed up some issues with the test - we should expect a new version shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From ewhelan at openjdk.java.net Wed Jun 9 17:46:42 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 9 Jun 2021 17:46:42 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. > > Regards, > Evan Evan Whelan has updated the pull request incrementally with two additional commits since the last revision: - Added new line at end of file - Cleaned up test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4354/files - new: https://git.openjdk.java.net/jdk/pull/4354/files/8bf9b687..c4ad5abb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4354&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4354&range=00-01 Stats: 20 lines in 1 file changed: 5 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4354/head:pull/4354 PR: https://git.openjdk.java.net/jdk/pull/4354 From ewhelan at openjdk.java.net Wed Jun 9 17:46:43 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 9 Jun 2021 17:46:43 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:08:58 GMT, Sean Mullan wrote: >> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Added new line at end of file >> - Cleaned up test case > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 590: > >> 588: // ignore the exception >> 589: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { >> 590: SSLLogger.warning("SSLSocket duplex close failed. Debug info only. Exception details:", ioe); > > If this is a debug message, shouldn't we just use `SSLLogger.fine()` instead of `SSLLogger.warning()`, with the same message "SSLSocket duplex close failed"? @coffeys what do you think? Hi @seanjmullan @coffeys I also don't have a logging level preference, so if there's merit to changing it, I'll be happy to do so. I've updated the test case and verified it passes on all platforms. Looking forward to any further feedback :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From xuelei at openjdk.java.net Wed Jun 9 17:55:15 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Jun 2021 17:55:15 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: Message-ID: <2qd_pRLlun7mk9Fzfs2qVZJRjkVAofhGu2GT9m_P0Zc=.5362d1dd-9241-4000-a42a-bfad0af55611@github.com> On Wed, 9 Jun 2021 07:53:43 GMT, Dongbo He wrote: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op > > Benchmark results after patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op > > SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > > Testing: tier1, tier2 src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 130: > 128: AlgorithmDecomposer decomposer) { > 129: super(decomposer); > 130: List disabledAlgorithmsList = getAlgorithms(propertyName); Is it doable to have the getAlgorithms() method return a Set? ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From ascarpino at openjdk.java.net Wed Jun 9 18:52:15 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 9 Jun 2021 18:52:15 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: On Fri, 4 Jun 2021 23:49:31 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl With JDK-8255557 integrated, I'll provide you a merged copy of your java side changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From github.com+44308314+jackh2000 at openjdk.java.net Wed Jun 9 20:27:28 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Wed, 9 Jun 2021 20:27:28 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec Message-ID: The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs. Also the "authorized" part was probably referring to the RC5 patent but that has since expired. ------------- Commit messages: - fixed whitespace error in file header - 8209092: fixed RC5 specifications and updated copyright date Changes: https://git.openjdk.java.net/jdk/pull/4443/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4443&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209092 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4443/head:pull/4443 PR: https://git.openjdk.java.net/jdk/pull/4443 From mullan at openjdk.java.net Wed Jun 9 20:33:15 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Jun 2021 20:33:15 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 17:43:45 GMT, Evan Whelan wrote: >> src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 590: >> >>> 588: // ignore the exception >>> 589: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { >>> 590: SSLLogger.warning("SSLSocket duplex close failed. Debug info only. Exception details:", ioe); >> >> If this is a debug message, shouldn't we just use `SSLLogger.fine()` instead of `SSLLogger.warning()`, with the same message "SSLSocket duplex close failed"? @coffeys what do you think? > > Hi @seanjmullan @coffeys > > I also don't have a logging level preference, so if there's merit to changing it, I'll be happy to do so. > I've updated the test case and verified it passes on all platforms. > > Looking forward to any further feedback :) Ok, It sounds like whether it should be a different logging level (fine) or not can be handled separately as part of a more global effort across other SSL logging messages. So I am ok with the change as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From mullan at openjdk.java.net Wed Jun 9 20:33:15 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Jun 2021 20:33:15 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 17:46:42 GMT, Evan Whelan wrote: >> Hi, >> >> Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. >> >> Regards, >> Evan > > Evan Whelan has updated the pull request incrementally with two additional commits since the last revision: > > - Added new line at end of file > - Cleaned up test case Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From ewhelan at openjdk.java.net Wed Jun 9 20:33:15 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 9 Jun 2021 20:33:15 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:27:41 GMT, Sean Mullan wrote: >> Hi @seanjmullan @coffeys >> >> I also don't have a logging level preference, so if there's merit to changing it, I'll be happy to do so. >> I've updated the test case and verified it passes on all platforms. >> >> Looking forward to any further feedback :) > > Ok, It sounds like whether it should be a different logging level (fine) or not can be handled separately as part of a more global effort across other SSL logging messages. So I am ok with the change as-is. Thanks Sean! ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From xuelei at openjdk.java.net Wed Jun 9 20:36:14 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Jun 2021 20:36:14 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:19:12 GMT, Jack Hartstein wrote: > The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." > > The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs. Also the "authorized" part was probably referring to the RC5 patent but that has since expired. The update looks good to me. A CSR might be required as it is a spec update, although it is just a trivial update. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4443 From ewhelan at openjdk.java.net Wed Jun 9 20:42:21 2021 From: ewhelan at openjdk.java.net (Evan Whelan) Date: Wed, 9 Jun 2021 20:42:21 GMT Subject: Integrated: 8255148: Confusing log output: SSLSocket duplex close failed In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 10:44:32 GMT, Evan Whelan wrote: > Hi, > > Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. > > Regards, > Evan This pull request has now been integrated. Changeset: 408e0a9c Author: Evan Whelan Committer: Sean Mullan URL: https://git.openjdk.java.net/jdk/commit/408e0a9c696888d41809e35bf252869f09f735db Stats: 106 lines in 2 files changed: 102 ins; 0 del; 4 mod 8255148: Confusing log output: SSLSocket duplex close failed Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From wetmore at openjdk.java.net Wed Jun 9 20:52:19 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 9 Jun 2021 20:52:19 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:19:12 GMT, Jack Hartstein wrote: > The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." > > The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs. Also the "authorized" part was probably referring to the RC5 patent but that has since expired. I was also wondering about the CSR, check with the CSR folks. src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java line 39: > 37: * > 38: *

This class can be used to initialize a {@code Cipher} object that > 39: * implements the RC5 algorithm as specified in RFC 2040. Try to keep lines to <= 80 chars. Maybe break after "in" ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4443 From xuelei at openjdk.java.net Wed Jun 9 20:59:21 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Jun 2021 20:59:21 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 17:46:42 GMT, Evan Whelan wrote: >> Hi, >> >> Please review my fix for JDK-8255148 which clarifies when an exception contains debug information only. >> >> Regards, >> Evan > > Evan Whelan has updated the pull request incrementally with two additional commits since the last revision: > > - Added new line at end of file > - Cleaned up test case src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1332: > 1330: // ignore the exception > 1331: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { > 1332: SSLLogger.warning("output stream close failed. Debug info only. Exception details:", ioe); I may look at this bug report different. It is a problem that the user does not understand the debug log properly. Debug log is for debug information only, and the debug log level indicates the level of the message. It looks like there is too much duplicated information. A log message has already indicated that the message is debug information only. Otherwise, exception should has been thrown in application level. The adding of "Exception details:" adds unnecessary dependency of the exception logging format. It may be fine to keep it unchanged, as if the users understand the logging message and logging levels. This kind of information normally means there is something that an application should take care of. That why we use a warning level log, rather than a fine level log message. It we really want an update, may be we could have a documentation enhancement instead. Similar comments for other update. ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From github.com+44308314+jackh2000 at openjdk.java.net Wed Jun 9 21:01:36 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Wed, 9 Jun 2021 21:01:36 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec [v2] In-Reply-To: References: Message-ID: > The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." > > The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs. Also the "authorized" part was probably referring to the RC5 patent but that has since expired. Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision: added line break ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4443/files - new: https://git.openjdk.java.net/jdk/pull/4443/files/ee75475e..bf6b9096 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4443&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4443&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4443/head:pull/4443 PR: https://git.openjdk.java.net/jdk/pull/4443 From github.com+44308314+jackh2000 at openjdk.java.net Wed Jun 9 21:01:37 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Wed, 9 Jun 2021 21:01:37 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:48:29 GMT, Bradford Wetmore wrote: >> Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision: >> >> added line break > > src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java line 39: > >> 37: * >> 38: *

This class can be used to initialize a {@code Cipher} object that >> 39: * implements the RC5 algorithm as specified in RFC 2040. > > Try to keep lines to <= 80 chars. Maybe break after "in" Fixed. I'll check on the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/4443 From xuelei at openjdk.java.net Wed Jun 9 21:12:17 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 9 Jun 2021 21:12:17 GMT Subject: RFR: 8255148: Confusing log output: SSLSocket duplex close failed [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:56:32 GMT, Xue-Lei Andrew Fan wrote: >> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Added new line at end of file >> - Cleaned up test case > > src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java line 1332: > >> 1330: // ignore the exception >> 1331: if (SSLLogger.isOn && SSLLogger.isOn("ssl")) { >> 1332: SSLLogger.warning("output stream close failed. Debug info only. Exception details:", ioe); > > I may look at this bug report different. It is a problem that the user does not understand the debug log properly. Debug log is for debug information only, and the debug log level indicates the level of the message. > > It looks like there is too much duplicated information. A log message has already indicated that the message is debug information only. Otherwise, exception should has been thrown in application level. The adding of "Exception details:" adds unnecessary dependency of the exception logging format. > > It may be fine to keep it unchanged, as if the users understand the logging message and logging levels. This kind of information normally means there is something that an application should take care of. That why we use a warning level log, rather than a fine level log message. > > It we really want an update, may be we could have a documentation enhancement instead. > > Similar comments for other update. Sorry that I did not have my comment earlier, and while I was typing the comment the update was integrated. Please just ignore this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4354 From mullan at openjdk.java.net Wed Jun 9 21:20:18 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Wed, 9 Jun 2021 21:20:18 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 20:55:42 GMT, Jack Hartstein wrote: >> src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java line 39: >> >>> 37: * >>> 38: *

This class can be used to initialize a {@code Cipher} object that >>> 39: * implements the RC5 algorithm as specified in RFC 2040. >> >> Try to keep lines to <= 80 chars. Maybe break after "in" > > Fixed. I'll check on the CSR. This class already references RFC 2040 (see line 32) so on that basis a CSR for this specific change is probably not required. But the "RC5" algorithm is listed as a standard algorithm in the Java Security Standard Algorithm Names specification but the definition does not reference RFC 2040: https://docs.oracle.com/en/java/javase/16/docs/specs/security/standard-names.html#cipher-algorithm-names Instead it has this description: "Variable-key-size encryption algorithms developed by Ron Rivest for RSA Data Security, Inc.". That definition is somewhat dated and I think we should just replace this with "The RC5 algorithm as specified in RFC 2040" to match what you have in the javadoc. But that type of change probably requires a CSR since it would be modifying that specification. I think you could either tackle that change as part of this, or file a follow-on issue to update the RC5 algorithm in the Standard Algorithm Names specification. ------------- PR: https://git.openjdk.java.net/jdk/pull/4443 From github.com+44308314+jackh2000 at openjdk.java.net Wed Jun 9 22:50:38 2021 From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein) Date: Wed, 9 Jun 2021 22:50:38 GMT Subject: RFR: 8209092: Remove outdated wording from RC5ParameterSpec [v3] In-Reply-To: References: Message-ID: > The RC5ParameterSpec class description contains the following sentence: "This class can be used to initialize a Cipher object that implements the RC5 algorithm as supplied by RSA Security LLC, or any parties authorized by RSA Security." > > The part "as supplied by RSA Security LLC, or any parties authorized by RSA Security." should be removed. We don't generally include information about 3rd-party JCA providers in the standard javadocs. Also the "authorized" part was probably referring to the RC5 patent but that has since expired. Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision: remove extra reference to RFC 2040 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4443/files - new: https://git.openjdk.java.net/jdk/pull/4443/files/bf6b9096..1d20ebc9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4443&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4443&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4443.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4443/head:pull/4443 PR: https://git.openjdk.java.net/jdk/pull/4443 From peter.firmstone at zeus.net.au Thu Jun 10 02:49:09 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jun 2021 12:49:09 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: Hi Sean, Sorry I've confused you. What I should have said is a ProtectionDomain with a null CodeSource. What I mean to ask is, where ProtectionDomain is created with a null CodeSource, in Class::getProtectionDomain() can we have CodeSource's that represents system modules instead of null? A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system modules? Hopefully my comments below will make a little more sense now. Regards, Peter. On 10/06/2021 1:07 am, Sean Mullan wrote: > > > On 6/8/21 9:35 PM, Peter Firmstone wrote: >> I would also like to request that all JDK modules be given >> ProtectionDomain's following SecurityManager deprecation. Currently >> some modules have null ProtectionDomain's to show they have >> AllPermission.? However we don't grant AllPermission to code in >> practise, we like to grant certain Permission's to Principal's, not >> code, where the Principal is the source of data, indicating the user >> has been authenticated and we only grant what's necessary and no more. > > As described in JEP 411, there are no plans to deprecate > ProtectionDomain at this time. > > --Sean From Alan.Bateman at oracle.com Thu Jun 10 06:22:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jun 2021 07:22:24 +0100 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: On 10/06/2021 03:49, Peter Firmstone wrote: > Hi Sean, > > Sorry I've confused you. > > What I should have said is a ProtectionDomain with a null CodeSource. > > What I mean to ask is, where ProtectionDomain is created with a null > CodeSource, in Class::getProtectionDomain() can we have CodeSource's > that represents system modules instead of null? > > A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system > modules? This is already the case for system modules that are mapped to the platform or application class loaders. I think your question is about modules that are mapped to the boot loader and whether they should get a unique PD that includes a useful code source rather than using a "shared" PD. That would be changing long standing behavior and would require careful analysis to see if anything would break. -Alan From peter.firmstone at zeus.net.au Thu Jun 10 06:37:04 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jun 2021 16:37:04 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: Thanks Alan, You've hit the nail on the head. In policy implementations, a null CodeSource in PD, is assigned AllPermission.?? So it would require adding grant statements for these modules in the default policy file that ships with the JVM. I thought it's an opportunity to make ProtectionDomain a little more useful if it maps to modules. Gut feel is it would be relatively low risk, but as you correctly state, would require testing. I'm not able to lodge on Jira, but I thought this would be worthy update. Regards, Peter. On 10/06/2021 4:22 pm, Alan Bateman wrote: > On 10/06/2021 03:49, Peter Firmstone wrote: >> Hi Sean, >> >> Sorry I've confused you. >> >> What I should have said is a ProtectionDomain with a null CodeSource. >> >> What I mean to ask is, where ProtectionDomain is created with a null >> CodeSource, in Class::getProtectionDomain() can we have CodeSource's >> that represents system modules instead of null? >> >> A CodeSource with URL's like jrt:/jdk.* or jrt:/java.*? for system >> modules? > > This is already the case for system modules that are mapped to the > platform or application class loaders. I think your question is about > modules that are mapped to the boot loader and whether they should get > a unique PD that includes a useful code source rather than using a > "shared" PD. That would be changing long standing behavior and would > require careful analysis to see if anything would break. > > -Alan From peter.firmstone at zeus.net.au Thu Jun 10 06:40:14 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 10 Jun 2021 16:40:14 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> Just a quick question, would it be possible that some JFR hooks might also be useable for an authorisation layer? Regards, Peter. On 9/06/2021 11:35 am, Peter Firmstone wrote: > > Apologies in advance if this seems like paranoid security. > > As you are likely now aware, we have been using SecurityManager a > little differently than recommended as we adapted it to our requirements. > > Sometimes it's not always easy to explain or obvious why something is > done in a certain way. > > It's clear we can use StackWalker to implement AccessController > functionality.? And it's also clear we can use ThreadLocal or Scope > Local's to preserve the user Subject across threads. > > Going forward we will need low level hooks in the JDK for our > authentication layer, clearly this is an opportunity to further > simplify and improve our authentication layer. > > Because we use a remote service architecture, with proxy's, the > proxy's are dynamically granted permission's after Service > Authentication, these permissions also require the user principal to > be logged in, we may have a number of services on the stack, for > example to participate in a transaction. > > We have a tool to generate least privilege policy files. > > There are two reasons we do this: > > 1. Simplicity of administration and auditing of policy files. > 2. Limit the permissions of code, and grant certain permissions to > users to ensure users are authenticated before allowing data parsing. > > An example of item two, is our services require users to be logged in > to ensure that any data provided by the user is a trusted data source > (we still check the data).?? We re-implemented a subset of Java > Serialization and have a DeSerializationPermission, which is granted > to Principals of users. > > If a user is not logged in, data cannot be de-serialized, because the > code alone doesn't have permission to do so. > > Hopefully modules and packages will have strong encapsulation in > future so we don't need permission's like java.lang.RuntimePermission > "accessClassInPackage.*"? No doubt we will need to create our own > Permission's. > > We would like to be able to limit data parsing, like XML or Java > de-serialization, to logged in users only. > > We don't break encapsulation, in future we will only use reflection to > call public methods and constructors (we are currently in the process > of doing so).?? Our build systems use Maven, our build is modular. > > I would also like to request that all JDK modules be given > ProtectionDomain's with CodeSource's for modules with > meaningful URL's jrt:java.* or jrt:jdk.* following > SecurityManager deprecation.? Currently some modules have null > ProtectionDomain's to show they have AllPermission. However we don't > grant AllPermission to code in practise, we like to grant certain > Permission's to Principal's, not code, where the Principal is the > source of data, indicating the user has been authenticated and we only > grant what's necessary and no more. > > Examples of permission's granted to JDK modules in POLP policy files, > taken from a test harness: > > grant codebase "jrt:/jdk.security.jgss" > { > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.util"; > ??? permission java.security.SecurityPermission > "putProviderProperty.JdkSASL"; > }; > > grant codebase "jrt:/jdk.crypto.mscapi" > { > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.util"; > ??? permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; > ??? permission java.security.SecurityPermission > "putProviderProperty.SunMSCAPI"; > }; > > grant codebase "jrt:/jdk.localedata" > { > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.util.locale.provider"; > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.util.resources"; > }; > > grant codebase "jrt:/jdk.security.auth" > { > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", > "read"; > ??? permission javax.security.auth.AuthPermission "modifyPrincipals"; > ??? permission javax.security.auth.AuthPermission > "modifyPrivateCredentials"; > ??? permission javax.security.auth.AuthPermission > "modifyPublicCredentials"; > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.krb5"; > ??? permission java.lang.RuntimePermission > "accessClassInPackage.sun.security.util"; > ??? permission java.lang.RuntimePermission "getProtectionDomain"; > }; > > Example of POLP grant to code with principal, code alone cannot access > these, in case you are wondering, we use this to secure the RMI > Registry using stateless TLSv1.3, it's used by our Service Watchdog, > or Service Activation framework called Phoenix, it's the sole use we > have of the Java RMI JRMP protocol, in cases where this isn't used we > can disable Java Serialization completely: > > grant codebase > "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", > ??? principal javax.security.auth.x500.X500Principal "CN=Phoenix" > { > ??? permission java.util.PropertyPermission > "javax.net.ssl.trustStore", "read"; > ??? permission java.util.PropertyPermission > "javax.net.ssl.trustStorePassword", "read"; > ??? permission java.util.PropertyPermission > "javax.net.ssl.trustStoreType", "read"; > ??? permission java.util.PropertyPermission > "org.apache.river.jeri.ssl.jceProvider", "read"; > ??? permission java.util.PropertyPermission > "org.apache.river.jeri.ssl.jsseProvider", "read"; > ??? permission java.util.PropertyPermission > "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; > ??? permission java.util.PropertyPermission > "org.apache.river.jeri.ssl.sslProtocol", "read"; > ??? permission java.util.PropertyPermission > "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; > ??? permission java.io.FilePermission "harness\\trust\\truststore", > "read"; > ??? permission java.net.SocketPermission "localhost:1098", > "listen,resolve"; > }; > > If we really want to get into detail, instances of GrantPermission > shows the permissions that are granted dynamically, in this case you > can see that provided the Mahalo Service is run with it's principal > CN=Mahalo, it has permission to de-serialize a MarshalledObject (it > doesn't actually unmarshall it though, it uses it for equals > comparison), the GrantPermission shows that it grants permission to > de-serialize (ATOMIC, which means atomic input validation, prior to > object creation), after authenticating the proxy's service. > > grant codebase > "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/mahalo-service-3.1.1-SNAPSHOT.jar", > ??? principal javax.security.auth.x500.X500Principal "CN=Mahalo" > { > ??? permission org.apache.river.api.io.DeSerializationPermission > "MARSHALL"; > ??? permission java.util.PropertyPermission > "org.apache.river.qa.home", "read"; > ??? permission org.apache.river.phoenix.dl.MonitorPermission > "net.jini.activation.arg.ActivationMonitor.inactiveObject"; > ??? permission net.jini.security.AuthenticationPermission > "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "connect"; > ??? permission net.jini.security.AuthenticationPermission > "javax.security.auth.x500.X500Principal \"CN=Mahalo\"", "listen"; > ??? permission net.jini.security.AuthenticationPermission > "javax.security.auth.x500.X500Principal \"CN=Mahalo\" peer > javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; > ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; > ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; > ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", > "connect,resolve"; > ??? permission java.net.SocketPermission > "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "connect,resolve"; > ??? permission java.net.SocketPermission > "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1024-", "accept,resolve"; > ??? permission java.net.SocketPermission "localhost:0", "listen,resolve"; > ??? permission net.jini.security.GrantPermission > "net.jini.security.AuthenticationPermission > \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer > javax.security.auth.x500.X500Principal \\\"CN=Phoenix\\\"\", > \"connect\";"; > ??? permission net.jini.security.GrantPermission > "net.jini.security.AuthenticationPermission > \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer > javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", > \"connect\"; net.jini.security.AuthenticationPermission > \"javax.security.auth.x500.X500Principal \\\"CN=Mahalo\\\" peer > javax.security.auth.x500.X500Principal \\\"CN=Outrigger\\\"\", > \"connect\";"; > ??? permission net.jini.security.GrantPermission > "org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; > org.apache.river.api.io.DeSerializationPermission \"MARSHALL\"; > org.apache.river.api.io.DeSerializationPermission \"ATOMIC\"; > java.lang.RuntimePermission \"accessClassInPackage.com.sun.proxy\", > \"\";"; > ??? permission javax.security.auth.AuthPermission "getSubject"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "delete"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\AppData\\Local\\Temp\\-", "write"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\mahalo-dl-3.1.1-SNAPSHOT.jar", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\mahalo-service-3.1.1-SNAPSHOT.jar", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\mahalo.keystore", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\outrigger.keystore", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", > "read"; > ??? permission java.io.FilePermission > "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", > "read"; > ??? permission java.lang.RuntimePermission "getClassLoader"; > ??? permission java.lang.RuntimePermission "modifyThread"; > ??? permission net.jini.discovery.DiscoveryPermission > "QATestDefaultGroup_DESKTOP-R0ORPA2_1623111918992"; > }; > > -- > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dongbohe at openjdk.java.net Thu Jun 10 07:02:18 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Thu, 10 Jun 2021 07:02:18 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: <2qd_pRLlun7mk9Fzfs2qVZJRjkVAofhGu2GT9m_P0Zc=.5362d1dd-9241-4000-a42a-bfad0af55611@github.com> References: <2qd_pRLlun7mk9Fzfs2qVZJRjkVAofhGu2GT9m_P0Zc=.5362d1dd-9241-4000-a42a-bfad0af55611@github.com> Message-ID: On Wed, 9 Jun 2021 17:52:37 GMT, Xue-Lei Andrew Fan wrote: >> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. >> >> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. >> Baseline results before patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op >> >> Benchmark results after patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op >> >> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. >> >> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: >> Before patch: >> >> summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> After patch: >> >> summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> >> Testing: tier1, tier2 > > src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 130: > >> 128: AlgorithmDecomposer decomposer) { >> 129: super(decomposer); >> 130: List disabledAlgorithmsList = getAlgorithms(propertyName); > > Is it doable to have the getAlgorithms() method return a Set? The collection required when new Constraints() should retain the default case of the elements, because some code will depend on this, for example, . [entry.startsWith("keySize")](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L383). But the set required by the permits should unify the case of the elements, because algorithm may be uppercase or lowercase, but the Set:contains() cannot handle this situation. So we need to create a new Set that ignores the default case of elements. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From Alan.Bateman at oracle.com Thu Jun 10 13:55:10 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jun 2021 14:55:10 +0100 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> Message-ID: <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> On 10/06/2021 07:40, Peter Firmstone wrote: > > Just a quick question, would it be possible that some JFR hooks might > also be useable for an authorisation layer? > > JFR events can't be used to intercept/veto operations, assuming that is what you are asking. However, it might be that JFR events are monitored as part of some overall security approach that takes into account events recorded for health, performance, or troubleshooting purposes. -Alan From weijun at openjdk.java.net Thu Jun 10 16:18:37 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Jun 2021 16:18:37 GMT Subject: RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Message-ID: Remove newly leaked memory. ------------- Commit messages: - 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Changes: https://git.openjdk.java.net/jdk/pull/4466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268525 Stats: 88 lines in 5 files changed: 45 ins; 19 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4466/head:pull/4466 PR: https://git.openjdk.java.net/jdk/pull/4466 From weijun at openjdk.java.net Thu Jun 10 17:11:54 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Jun 2021 17:11:54 GMT Subject: Withdrawn: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 15:40:56 GMT, Weijun Wang wrote: > Remove newly leaked memory. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4466 From weijun at openjdk.java.net Thu Jun 10 17:18:31 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Jun 2021 17:18:31 GMT Subject: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Message-ID: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> Remove newly leaked memory. ------------- Commit messages: - 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Changes: https://git.openjdk.java.net/jdk17/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268525 Stats: 88 lines in 5 files changed: 45 ins; 19 del; 24 mod Patch: https://git.openjdk.java.net/jdk17/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk17/pull/3 From mullan at openjdk.java.net Thu Jun 10 18:13:50 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 10 Jun 2021 18:13:50 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 07:53:43 GMT, Dongbo He wrote: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op > > Benchmark results after patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op > > SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > > Testing: tier1, tier2 I think it would be worthwhile to see if we can take this a step further, and leverage the `Constraint` objects that are already created and stored in the `Constraints` object in a `HashMap>`. The key is the algorithm `String`, and the value is a `List` of `Constraint` objects that apply to it. If the algorithm is completely disabled, the `List` would contain one entry `Constraint.DisabledConstraint` (which has a `permits` method that always returns `false`). This way we could potentially eliminate the List/Set cache entirely and just use the HashMap to check if the algorithm is disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From valeriep at openjdk.java.net Thu Jun 10 18:42:56 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Jun 2021 18:42:56 GMT Subject: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 In-Reply-To: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> References: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> Message-ID: On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. Marked as reviewed by valeriep (Reviewer). Changes look good to me. Thanks for catching these. Valerie ------------- PR: https://git.openjdk.java.net/jdk17/pull/3 From ascarpino at openjdk.java.net Thu Jun 10 19:38:50 2021 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 10 Jun 2021 19:38:50 GMT Subject: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 In-Reply-To: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> References: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> Message-ID: On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. They look fine ------------- Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/3 From weijun at openjdk.java.net Thu Jun 10 20:04:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Jun 2021 20:04:13 GMT Subject: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 [v2] In-Reply-To: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> References: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> Message-ID: <0JTyTEkWeOsO-T5CPK2qdnAn8wyKPkVmZ_30Km_nSoI=.d31dc7c2-9325-4af0-affc-30edec7fb0d6@github.com> > Remove newly leaked memory. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: clean up one class ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/3/files - new: https://git.openjdk.java.net/jdk17/pull/3/files/92375608..81d14efd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=3&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=3&range=00-01 Stats: 71 lines in 1 file changed: 7 ins; 50 del; 14 mod Patch: https://git.openjdk.java.net/jdk17/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk17/pull/3 From valeriep at openjdk.java.net Thu Jun 10 20:10:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Jun 2021 20:10:53 GMT Subject: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 [v2] In-Reply-To: <0JTyTEkWeOsO-T5CPK2qdnAn8wyKPkVmZ_30Km_nSoI=.d31dc7c2-9325-4af0-affc-30edec7fb0d6@github.com> References: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> <0JTyTEkWeOsO-T5CPK2qdnAn8wyKPkVmZ_30Km_nSoI=.d31dc7c2-9325-4af0-affc-30edec7fb0d6@github.com> Message-ID: On Thu, 10 Jun 2021 20:04:13 GMT, Weijun Wang wrote: >> Remove newly leaked memory. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > clean up one class Update looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/3 From weijun at openjdk.java.net Thu Jun 10 22:21:57 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 10 Jun 2021 22:21:57 GMT Subject: [jdk17] Integrated: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 In-Reply-To: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> References: <_9sdpSe5-zBPG6Rd516vXDrqJXe4OKC5Kiozr1Bm2hM=.d0dd5db4-72ef-4f88-920e-44b856fd956b@github.com> Message-ID: On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. This pull request has now been integrated. Changeset: 7b2e7d8b Author: Weijun Wang URL: https://git.openjdk.java.net/jdk17/commit/7b2e7d8bab890bd655093976cc9c3b0b6d00c034 Stats: 158 lines in 5 files changed: 52 ins; 69 del; 37 mod 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 Reviewed-by: valeriep, ascarpino ------------- PR: https://git.openjdk.java.net/jdk17/pull/3 From weijun at openjdk.java.net Fri Jun 11 01:49:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 01:49:50 GMT Subject: Withdrawn: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE In-Reply-To: <3EV9-5XxjMjrMdcCz4xcHQf0rRoqgH0HBb4Ym3Qe3eY=.d5d15d83-769b-4121-92df-8cd4d09b01eb@github.com> References: <3EV9-5XxjMjrMdcCz4xcHQf0rRoqgH0HBb4Ym3Qe3eY=.d5d15d83-769b-4121-92df-8cd4d09b01eb@github.com> Message-ID: On Mon, 7 Jun 2021 20:57:52 GMT, Weijun Wang wrote: > The test must run with sudo but I forgot to mention it. New comment and a better error message is added. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4401 From weijun at openjdk.java.net Fri Jun 11 01:53:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 01:53:03 GMT Subject: [jdk17] RFR: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Message-ID: <6W1MSKVZMm4PK-8ty0b7-I_IBfCzSUnupGesFKFLy94=.1b51e256-57e9-4235-a62b-89a873c6ab77@github.com> The test must run with sudo but I forgot to mention it. New comment and a better error message is added. ------------- Commit messages: - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Changes: https://git.openjdk.java.net/jdk17/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=12&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268093 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/12/head:pull/12 PR: https://git.openjdk.java.net/jdk17/pull/12 From weijun at openjdk.java.net Fri Jun 11 01:56:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 01:56:55 GMT Subject: Withdrawn: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From weijun at openjdk.java.net Fri Jun 11 02:07:58 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 02:07:58 GMT Subject: [jdk17] RFR: 8268349: Provide more detail in JEP 411 warning messages Message-ID: More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. ------------- Commit messages: - no cache, new warning, enhance one test, fix one test - 8268349: Provide more detail in JEP 411 warning messages Changes: https://git.openjdk.java.net/jdk17/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268349 Stats: 105 lines in 6 files changed: 64 ins; 19 del; 22 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13 From dongbohe at openjdk.java.net Fri Jun 11 03:42:49 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 11 Jun 2021 03:42:49 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: Message-ID: <3zYaRyf2dulqMdeSHnzbRwMeQ24mGHFZ5oRpqyM904M=.4af6b8b1-317a-4d10-8a12-aa463cd1f777@github.com> On Thu, 10 Jun 2021 18:10:37 GMT, Sean Mullan wrote: > I think it would be worthwhile to see if we can take this a step further, and leverage the `Constraint` objects that are already created and stored in the `Constraints` object in a `HashMap>`. The key is the algorithm `String`, and the value is a `List` of `Constraint` objects that apply to it. If the algorithm is completely disabled, the `List` would contain one entry `Constraint.DisabledConstraint` (which has a `permits` method that always returns `false`). > > This way we could potentially eliminate the List/Set cache entirely and just use the HashMap to check if the algorithm is disabled. Thanks for the suggestion, `Constraints` is a private inner class in `DisabledAlgorithmConstraints.java` and cannot be accessed in `AbstractAlgorithmConstraints.java:checkAlgorithm`. Moreover, this method does not seem to be applicable to class `LegacyAlgorithmConstraints.java`, because there is no `Constraints` object in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From xuelei at openjdk.java.net Fri Jun 11 04:23:50 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Fri, 11 Jun 2021 04:23:50 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: <2qd_pRLlun7mk9Fzfs2qVZJRjkVAofhGu2GT9m_P0Zc=.5362d1dd-9241-4000-a42a-bfad0af55611@github.com> Message-ID: On Thu, 10 Jun 2021 06:59:25 GMT, Dongbo He wrote: >> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 130: >> >>> 128: AlgorithmDecomposer decomposer) { >>> 129: super(decomposer); >>> 130: List disabledAlgorithmsList = getAlgorithms(propertyName); >> >> Is it doable to have the getAlgorithms() method return a Set? > > The collection required when new Constraints() should retain the default case of the elements, because some code will depend on this, for example, . > [entry.startsWith("keySize")](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L383). > But the set required by the permits should unify the case of the elements, because algorithm may be uppercase or lowercase, but the Set:contains() cannot handle this situation. > So we need to create a new Set that ignores the default case of elements. For the entry.startsWith("keySize") example, I don't think keySize is an algorithm that could be listed individually in the list. The "keySize" may be just a part one algorithm, for example "RSA keySize < 1024". It's a good point about the lowercase and upper case. Did you check how constraints like the "keySize" are expressed in the list or set? ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From dongbohe at openjdk.java.net Fri Jun 11 08:00:51 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 11 Jun 2021 08:00:51 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance In-Reply-To: References: <2qd_pRLlun7mk9Fzfs2qVZJRjkVAofhGu2GT9m_P0Zc=.5362d1dd-9241-4000-a42a-bfad0af55611@github.com> Message-ID: <3F0GGxIho-YJjqrVxVUNBqOhspRuuoMoqYiL5CSssr0=.602acd5b-6bd5-4f72-b2f8-273d6765cce5@github.com> On Fri, 11 Jun 2021 04:21:15 GMT, Xue-Lei Andrew Fan wrote: >> The collection required when new Constraints() should retain the default case of the elements, because some code will depend on this, for example, . >> [entry.startsWith("keySize")](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L383). >> But the set required by the permits should unify the case of the elements, because algorithm may be uppercase or lowercase, but the Set:contains() cannot handle this situation. >> So we need to create a new Set that ignores the default case of elements. > > For the entry.startsWith("keySize") example, I don't think keySize is an algorithm that could be listed individually in the list. The "keySize" may be just a part one algorithm, for example "RSA keySize < 1024". > > It's a good point about the lowercase and upper case. Did you check how constraints like the "keySize" are expressed in the list or set? Yes, you're right. The "keySize" is not an independent algorithm listed in list, it exists in a form like "ec keysize <224". In the case of "keySize", the object in the list stored in `algorithmConstraints` is `KeySizeConstraint`, then keysize will be checked in [algorithmConstraints.permits(algorithm, parameters)](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L169) by `KeySizeConstraint:permits`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Jun 11 13:19:15 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Jun 2021 13:19:15 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v2] In-Reply-To: References: Message-ID: > ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4432/files - new: https://git.openjdk.java.net/jdk/pull/4432/files/b490e1ff..49965732 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=00-01 Stats: 36 lines in 2 files changed: 5 ins; 17 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4432/head:pull/4432 PR: https://git.openjdk.java.net/jdk/pull/4432 From github.com+34924738+mahendrachhipa at openjdk.java.net Fri Jun 11 13:38:14 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Fri, 11 Jun 2021 13:38:14 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v3] In-Reply-To: References: Message-ID: > ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Remove extra space. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4432/files - new: https://git.openjdk.java.net/jdk/pull/4432/files/49965732..db615030 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4432/head:pull/4432 PR: https://git.openjdk.java.net/jdk/pull/4432 From dfuchs at openjdk.java.net Fri Jun 11 14:04:50 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 11 Jun 2021 14:04:50 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v3] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 13:38:14 GMT, Mahendra Chhipa wrote: >> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra space. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java line 89: > 87: // created as it will use an ephemeral port. > 88: System.setProperty("https.proxyPort", > 89: Integer.toString(proxy.getLocalPort())); A potentially better alternative to setting system properties in main could be to set a ProxySelector (using ProxySelector.setDefault()); test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java line 184: > 182: HttpURLConnection uc = (HttpURLConnection)url.openConnection(); > 183: System.out.println(uc.getResponseCode()); > 184: if(uc.getResponseCode() == 400) { It could be better to use: `uc.getResponseCode() != 200` here - since anything but 200 should be an error? test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java line 186: > 184: if(uc.getResponseCode() == 400) { > 185: uc.disconnect(); > 186: throw new RuntimeException("Test failed : bad http request"); Maybe add the response code to the exception message. ------------- PR: https://git.openjdk.java.net/jdk/pull/4432 From mullan at openjdk.java.net Fri Jun 11 14:16:56 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 11 Jun 2021 14:16:56 GMT Subject: [jdk17] RFR: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE In-Reply-To: <6W1MSKVZMm4PK-8ty0b7-I_IBfCzSUnupGesFKFLy94=.1b51e256-57e9-4235-a62b-89a873c6ab77@github.com> References: <6W1MSKVZMm4PK-8ty0b7-I_IBfCzSUnupGesFKFLy94=.1b51e256-57e9-4235-a62b-89a873c6ab77@github.com> Message-ID: On Fri, 11 Jun 2021 01:46:46 GMT, Weijun Wang wrote: > The test must run with sudo but I forgot to mention it. New comment and a better error message is added. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/12 From weijun at openjdk.java.net Fri Jun 11 15:15:59 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 15:15:59 GMT Subject: [jdk17] Integrated: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE In-Reply-To: <6W1MSKVZMm4PK-8ty0b7-I_IBfCzSUnupGesFKFLy94=.1b51e256-57e9-4235-a62b-89a873c6ab77@github.com> References: <6W1MSKVZMm4PK-8ty0b7-I_IBfCzSUnupGesFKFLy94=.1b51e256-57e9-4235-a62b-89a873c6ab77@github.com> Message-ID: <8xzINEMUhx7aZZlRoNx-7xtzAacA5OXVd94Vq1zKPSs=.85bdef03-ecc6-4bd2-9a2c-bd3a5f7abdd5@github.com> On Fri, 11 Jun 2021 01:46:46 GMT, Weijun Wang wrote: > The test must run with sudo but I forgot to mention it. New comment and a better error message is added. This pull request has now been integrated. Changeset: e39346e7 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk17/commit/e39346e708a06cdee2b9a096f08c1cfe2e21dfc2 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk17/pull/12 From kvn at openjdk.java.net Fri Jun 11 16:04:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Jun 2021 16:04:53 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> Message-ID: <5M6_B0kvIXhODk0jhkVJytNJ5oobCsGAx71x9mQbGvU=.c93aad5d-5a3d-48c2-8c23-65d9b45fb3e3@github.com> On Fri, 4 Jun 2021 23:49:31 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl Do you plan to implement `decrypt` intrinsic too? src/hotspot/share/opto/library_call.cpp line 547: > 545: > 546: case vmIntrinsics::_galoisCounterMode_AESCrypt: > 547: return inline_galoisCounterMode_AESCrypt(intrinsic_id()); You don't need to pass `intrinsic_id()` for this implementation unless you plan to add decrypt intrinsic later. src/hotspot/share/opto/library_call.cpp line 6545: > 6543: top_out != NULL && top_out->klass() != NULL, "args are strange"); > 6544: > 6545: // checks are the responsibility of the caller Do you have all NULL for all objects and range checks in Java code for this intrinsic? src/hotspot/share/opto/library_call.cpp line 6564: > 6562: Node* subkeyHtbl = load_field_from_object(ghash_object, "subkeyHtbl", "[J"); > 6563: Node* state = load_field_from_object(ghash_object, "state", "[J"); > 6564: if (embeddedCipherObj == NULL || counter == NULL || subkeyHtbl == NULL || state == NULL) return false; Follow coding style for such long condition: if () { return false; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From svkamath at openjdk.java.net Fri Jun 11 17:22:51 2021 From: svkamath at openjdk.java.net (Smita Kamath) Date: Fri, 11 Jun 2021 17:22:51 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: <5M6_B0kvIXhODk0jhkVJytNJ5oobCsGAx71x9mQbGvU=.c93aad5d-5a3d-48c2-8c23-65d9b45fb3e3@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <5M6_B0kvIXhODk0jhkVJytNJ5oobCsGAx71x9mQbGvU=.c93aad5d-5a3d-48c2-8c23-65d9b45fb3e3@github.com> Message-ID: On Fri, 11 Jun 2021 15:45:02 GMT, Vladimir Kozlov wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267125:Updated intrinsic signature to remove copies of counter, state and subkeyHtbl > > src/hotspot/share/opto/library_call.cpp line 547: > >> 545: >> 546: case vmIntrinsics::_galoisCounterMode_AESCrypt: >> 547: return inline_galoisCounterMode_AESCrypt(intrinsic_id()); > > You don't need to pass `intrinsic_id()` for this implementation unless you plan to add decrypt intrinsic later. Thanks for your comments Vladimir. The intrinsic is called for encrypt as well as decrypt operation. > src/hotspot/share/opto/library_call.cpp line 6564: > >> 6562: Node* subkeyHtbl = load_field_from_object(ghash_object, "subkeyHtbl", "[J"); >> 6563: Node* state = load_field_from_object(ghash_object, "state", "[J"); >> 6564: if (embeddedCipherObj == NULL || counter == NULL || subkeyHtbl == NULL || state == NULL) return false; > > Follow coding style for such long condition: > > if () { > return false; > } I will make the change. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From kvn at openjdk.java.net Fri Jun 11 17:58:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Jun 2021 17:58:50 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: <5lSvX6Y5sMWA0SulDc3Z5ObaVV5M7G6_Zsb99AxWnv4=.1f610aa2-9124-4a46-8d83-c920de3e2a33@github.com> References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <5M6_B0kvIXhODk0jhkVJytNJ5oobCsGAx71x9mQbGvU=.c93aad5d-5a3d-48c2-8c23-65d9b45fb3e3@github.com> <5lSvX6Y5sMWA0SulDc3Z5ObaVV5M7G6_Zsb99AxWnv4=.1f610aa2-9124-4a46-8d83-c920de3e2a33@github.com> Message-ID: On Fri, 11 Jun 2021 17:54:02 GMT, Vladimir Kozlov wrote: >> Thanks for your comments Vladimir. The intrinsic is called for encrypt as well as decrypt operation. > > Only one intrinsic is declared in this change: `_galoisCounterMode_AESCrypt`. Other AES intrinsics have 2 that is why they have to pass intrinsic_id(). See lines before this. Note, _counterMode_AESCrypt is not example - it has the same issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From kvn at openjdk.java.net Fri Jun 11 17:58:50 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Jun 2021 17:58:50 GMT Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v2] In-Reply-To: References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com> <5M6_B0kvIXhODk0jhkVJytNJ5oobCsGAx71x9mQbGvU=.c93aad5d-5a3d-48c2-8c23-65d9b45fb3e3@github.com> Message-ID: <5lSvX6Y5sMWA0SulDc3Z5ObaVV5M7G6_Zsb99AxWnv4=.1f610aa2-9124-4a46-8d83-c920de3e2a33@github.com> On Fri, 11 Jun 2021 17:19:37 GMT, Smita Kamath wrote: >> src/hotspot/share/opto/library_call.cpp line 547: >> >>> 545: >>> 546: case vmIntrinsics::_galoisCounterMode_AESCrypt: >>> 547: return inline_galoisCounterMode_AESCrypt(intrinsic_id()); >> >> You don't need to pass `intrinsic_id()` for this implementation unless you plan to add decrypt intrinsic later. > > Thanks for your comments Vladimir. The intrinsic is called for encrypt as well as decrypt operation. Only one intrinsic is declared in this change: `_galoisCounterMode_AESCrypt`. Other AES intrinsics have 2 that is why they have to pass intrinsic_id(). See lines before this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4019 From weijun at openjdk.java.net Fri Jun 11 19:27:10 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 19:27:10 GMT Subject: [jdk17] RFR: 8268349: Provide more detail in JEP 411 warning messages [v2] In-Reply-To: References: Message-ID: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update warnings to match the new CSR ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/13/files - new: https://git.openjdk.java.net/jdk17/pull/13/files/a8fc259e..c62dff99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13 From valeriep at openjdk.java.net Fri Jun 11 21:29:03 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 11 Jun 2021 21:29:03 GMT Subject: [jdk17] RFR: 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers Message-ID: <2jITaJEEIZFJOmcta7W5ahERMHUyU_xI-J38sasQb3w=.552fffd0-ed00-4f73-a429-e307d15824c5@github.com> Could someone help review this straightforward fix? The current impl for AES KW and KWP cipher should check for possible null iv value in its CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated the regression test to cover this scenario as well as some other minor updates. Thanks! Valerie ------------- Commit messages: - 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers Changes: https://git.openjdk.java.net/jdk17/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268621 Stats: 50 lines in 4 files changed: 34 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk17/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/34/head:pull/34 PR: https://git.openjdk.java.net/jdk17/pull/34 From peter.firmstone at zeus.net.au Sat Jun 12 03:01:56 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 12 Jun 2021 13:01:56 +1000 Subject: JEP 411: Updates to alternatives Message-ID: Noticing the updates made to JEP 411 Alternatives, I think I might have a minimalist alternative, you may find interesting: Remove: 1. SecurityManager 2. Policy provider and implementation 3. Permission checks in JDK code addressed by improvements to encapsulation, eg RuntimePermission "access class in package" and? ReflectPermission, these are no longer necessary, however I would recommend retaining checks at System::getProperty and setProperty, as these may contain security sensitive information (eg keystore and truststore). 4. doPrivileged calls within the JVM other than those which preserve context across threads, most permissions that "leak" are addressed at #3 above, and POLP tooling can capture other permissions.? It would appear that doPrivileged is more appropriate for application code, rather than JDK code. 5. I'm not sure about removing doPrivileged calls intended to preserve context within OpenJDK. Changes (improvements): 1. Make Guard::check a default method, that delegates to a provider, with a single method (eg Authority::confirm(Guard)) that does nothing by default.? Remove all implementing instances of Permission::check. (this could be backported easily). SecurityManager methods are just permission checks, existing use cases of SecurityManager can be supported with this one method.?? This could be back ported to Java 8, so libraries that currently support all supported Java versions can continue to do so.? All calls to SecurityManager methods in JDK code can be replaced by the corresponding permission check. 2. Add permission checks to data parsers (eg deserialization), this allows implementations to grant these permissions only to users, if there is not an authenticated user, then the data received by the parser cannot be trusted. 3. "Modules that are mapped to the boot loader get a unique ProtectionDomain that includes a useful code source rather than using a "shared" PD."?? This allows permission to be granted to users, (not code) so certain privileged operations, such as data parsing cannot be performed without an authenticated user, eg deserialization.? When data can only be trusted from authenticated users. Removal of AccessController and AccessControlContext have greater impact.?? AccessController's stack walk is high scaling (I haven't observed any contention, I assume it's non blocking and thread confined?), it's certainly very performant, it could be replaced internally by StackWalker to reduce OpenJDK's maintenance burden, although it isn't clear what the performance impact might be, but it will no doubt performance improvement is possible. With SecurityManager gone, no implementation and no policy provider, it simply provides the mechanics for an authorization layer without all the baggage, allowing both simple and complex implementations.? It's not for sandboxing untrusted code. Improvements will allow it to be utilised by developers, to prevent consumption of untrusted code or data and to limit the privileges of trusted code and users to principles of least privilege. It should also simplifies many tests, as JDK code only need confirm Permission checks are made and functionality of the AccessController and AccessControlContext methods if these are retained (I would prefer to see that, at least for JAAS compatibility). -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.java.net Sat Jun 12 03:22:46 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 12 Jun 2021 03:22:46 GMT Subject: [jdk17] RFR: 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers In-Reply-To: <2jITaJEEIZFJOmcta7W5ahERMHUyU_xI-J38sasQb3w=.552fffd0-ed00-4f73-a429-e307d15824c5@github.com> References: <2jITaJEEIZFJOmcta7W5ahERMHUyU_xI-J38sasQb3w=.552fffd0-ed00-4f73-a429-e307d15824c5@github.com> Message-ID: On Fri, 11 Jun 2021 21:22:49 GMT, Valerie Peng wrote: > Could someone help review this straightforward fix? The current impl for AES KW and KWP cipher should check for possible null iv value in its CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated the regression test to cover this scenario as well as some other minor updates. > > Thanks! > Valerie Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/34 From valeriep at openjdk.java.net Sat Jun 12 05:52:00 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Sat, 12 Jun 2021 05:52:00 GMT Subject: [jdk17] RFR: 8267397: AlgorithmId's OID cache is never refreshed Message-ID: Could someone help review this small fix? This clears the static aliasOidsTable field in AlgorithmId class when provider list is changed. Enhanced existing regression test to cover the provider removal scenario. Thanks, Valerie ------------- Commit messages: - 8267397: AlgorithmId's OID cache is never refreshed Changes: https://git.openjdk.java.net/jdk17/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267397 Stats: 105 lines in 3 files changed: 76 ins; 20 del; 9 mod Patch: https://git.openjdk.java.net/jdk17/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk17/pull/36 From xuelei at openjdk.java.net Sat Jun 12 16:16:52 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sat, 12 Jun 2021 16:16:52 GMT Subject: [jdk17] RFR: 8267397: AlgorithmId's OID cache is never refreshed In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 05:45:35 GMT, Valerie Peng wrote: > Could someone help review this small fix? This clears the static aliasOidsTable field in AlgorithmId class when provider list is changed. Enhanced existing regression test to cover the provider removal scenario. > > Thanks, > Valerie Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/36 From peter.firmstone at zeus.net.au Sun Jun 13 10:34:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 13 Jun 2021 20:34:32 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> Message-ID: <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> Thanks Alan, I've been thinking that it may be preferable to have hooks that allowed us to inject our own permission checks, rather than retaining existing permission checks. An implementation can override Guard::check without requiring a provider mechanism. The other advantage is the ability to customize Permission implementations, such as allowing address ranges in a SocketPermission implementation and not consulting DNS to resolve host names. Cheers, Peter. On 10/06/2021 11:55 pm, Alan Bateman wrote: > On 10/06/2021 07:40, Peter Firmstone wrote: >> >> Just a quick question, would it be possible that some JFR hooks might >> also be useable for an authorisation layer? >> >> > JFR events can't be used to intercept/veto operations, assuming that > is what you are asking. However, it might be that JFR events are > monitored as part of some overall security approach that takes into > account events recorded for health, performance, or troubleshooting > purposes. > > -Alan -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sun Jun 13 23:56:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 09:56:20 +1000 Subject: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> References: <07a4cddc-916e-a0cc-5b6a-5a42d847ea90@zeus.net.au> <3bcc71f4-fc19-1fa0-4ede-ecd9d71ce3b9@oracle.com> <0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au> Message-ID: <96fe1baa-cc12-f16d-05e8-6e6549fd2f00@zeus.net.au> Some thoughts on hooks: * Utilize the Service Provider API, so as not to expose jdk implementation code.? META-INF/services/java.security.Guard * Allow existing Permission classes to remain backward compatible, declare them as services, so that SecurityManager can be degraded as planned and these services are gradually removed. (Removes dependencies on Permission instance types). * Guard implementation is required to have a constructor with two String arguments, (String name, String actions). * Service must implement Guard interface. * Doesn't depend on Permission or any existing implementation classes, completely customizable by the service implementation. * Application developers can also implement hooks using this service. Break up guard service providers into current Permission types: "AWT" "FILE" "SERIALIZABLE" "MANAGEMENT" "REFLECT" "RUNTIME" "NET" "SOCKET" "URL" "FILE-LINK" "SECURITY" "SQL" "LOGGING" "PROPERTY" "MBEAN" "MBEAN-SERVER" "MBEAN-TRUST" "SUBJECT-DELEGATION" "TLS" "AUTH" "KERBEROS-DELEGATION" "KERBEROS-SERVICE" "PRIVATE-CREDENTIAL" "AUDIO" "JAXB" "WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc.? Granted to users, so that it can only be performed after authentication. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 13/06/2021 8:34 pm, Peter Firmstone wrote: > Thanks Alan, > > I've been thinking that it may be preferable to have hooks that > allowed us to inject our own permission checks, rather than retaining > existing permission checks. > > An implementation can override Guard::check without requiring a > provider mechanism. > > The other advantage is the ability to customize Permission > implementations, such as allowing address ranges in a SocketPermission > implementation and not consulting DNS to resolve host names. > > Cheers, > > Peter. > > > On 10/06/2021 11:55 pm, Alan Bateman wrote: >> On 10/06/2021 07:40, Peter Firmstone wrote: >>> >>> Just a quick question, would it be possible that some JFR hooks >>> might also be useable for an authorisation layer? >>> >>> >> JFR events can't be used to intercept/veto operations, assuming that >> is what you are asking. However, it might be that JFR events are >> monitored as part of some overall security approach that takes into >> account events recorded for health, performance, or troubleshooting >> purposes. >> >> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 14 05:54:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jun 2021 06:54:51 +0100 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: Message-ID: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> cc'ing security-dev as that is the mailing list to use for this JEP. This JEP is the first of several in a multi-release/multi-year effort. It's way too early to give any guess as to when the APIs will be removed. As the JEP says, future releases may degrade the SM APIs so that System.getSM returns always returns null or AccessController::doPriv just runs the action. This should mean that libraries that are compiling to older releases should continue to compile and run on those releases. When they run on some future release that degrades the implementation then it will be as if there is no SM.? So I would say the impact is little to none for libraries for the foreseeable future. -Alan On 13/06/2021 21:28, Rafael Winterhalter wrote: > I am currently looking into how I should address JEP 411 in my library Byte > Buddy and I find it rather challenging. The problem I am facing is that I > know of several users who rely on the security manager in their Java 8/11 > applications. I would like to continue to support those users' use cases as > long as I support Java versions that contain the security manager, which > will be for many years to come. At the same time, I would like to address > the announced removal of the API and make sure that Byte Buddy can work > without it prior to the deadline when the library in its current state > would no longer link. > > From my understanding of the intention of JEP 411, the API was supposed to > be stubbed ? similar to Android?s stubbing of the API - rather than being > removed. However, with the announced deprecation for removal of > AccessController and SecurityManager, I understand that I would need to > fully remove the dispatching to work with future Java versions. > > Furthermore, it is difficult to create a working facade for dispatching to > the security manager only if it is available. Methods like > AccessController.doPrivileged are caller sensitive and by adding a utility > to a library, this utility would leak to any potential user. It would > therefore require package-private dispatchers for any relevant package, > which would lead to a lot of copy-paste to retain backwards compatibility > (given that a library cannot assume to be run as a module). > > Finally, removing the API would mean that Byte Buddy versions of the last > ten years would no longer link in future JDKs. For Byte Buddy where new > Java versions often require an update, that might not be a big issue but > many other libraries do support the API, I don?t feel it would be a rather > severe restriction and cause unnecessary breakage if API is removed, rather > than stubbed. I am thinking of libraries like Netty here which are rather > omnipresent and would suddenly no longer link, a concept that is unlikely > intuitive to a lot of developers. > > Therefore, my question is: should SecurityManager, AccessController and the > Policy APIs really be deprecated for removal? Rather, I think that the APIs > should be deprecated, but be retained with stubbed implementations. > System.getSecurityMananger would then always return null. > System.setSecurityManager on the other hand could be deprecated for > removal. This way, existing code could continue to work as if the security > manager is not active, which already is the common scenario and would not > cause any disruption at the small price of keeping a handful of some > stubbed classes. > > Thanks for advice on how this is intended to be handled by library > developers like me. > Best regards, Rafael From peter.firmstone at zeus.net.au Mon Jun 14 06:19:04 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 16:19:04 +1000 Subject: Fwd: Low level hooks in JDK for instrumentation of permission checks. In-Reply-To: References: Message-ID: Forgot to cc. -------- Forwarded Message -------- Subject: Re: Low level hooks in JDK for instrumentation of permission checks. Date: Mon, 14 Jun 2021 15:13:15 +1000 From: Peter Firmstone To: jdk-dev at openjdk.java.net Clarification, utilize java.security.Provider. So this might use a module declaration or META-INF/services/java.security.Provider, sorry got muddled with typical ServiceLoader usage below. The reason for choosing Provider is that it allows constructor parameters, it's also security related and can require code signing, not sure if that should be a requirement. Another reason for using security provider is to avoid deadlock during Provider initialization, it must be listed as a provider in the java.security file or if security.overridePropertiesFile=true and -Djava.security.properties=file://path/additional.security defines providers, which would be useful for testing. Dynamic loading a provider using Security.addProvider or insertProviderAt causes security checks, each Guard::check call would try to initiate "SECURITY" Provider loading causing deadlock.? To avoid deadlock at the very least the "SECURITY" and "PROPERTY" java.security.Guard services would need to be loaded by java.security at startup. grant codebase "jrt:/java.xml.crypto" { ??? permission java.util.PropertyPermission "java.specification.version", "read"; ??? permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; }; Need to be careful with loading and recursive permission checks, it's ok if a permission check fires off permission checks that cause loading of other providers, we just can't ask the provider that is being dynamically loaded to perform permission checks on itself, or any circular relationship between providers. Basically it's good to have separate providers for each permission type as it helps avoid deadlocks. grant codebase "jrt:/jdk.crypto.cryptoki" { ??? permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; On 14/06/2021 9:56 am, Peter Firmstone wrote: > Some thoughts on hooks: > > ?* Utilize the Service Provider API, so as not to expose jdk > ?? implementation code.? META-INF/services/java.security.Guard > ?* Allow existing Permission classes to remain backward compatible, > ?? declare them as services, so that SecurityManager can be degraded as > ?? planned and these services are gradually removed. (Removes > ?? dependencies on Permission instance types). > ?* Guard implementation is required to have a constructor with two > ?? String arguments, (String name, String actions). > ?* Service must implement Guard interface. > ?* Doesn't depend on Permission or any existing implementation classes, > ?? completely customizable by the service implementation. > ?* Application developers can also implement hooks using this service. > > Break up guard service providers into current Permission types: > > "AWT" > "FILE" > "SERIALIZABLE" > "MANAGEMENT" > "REFLECT" > "RUNTIME" > "NET" > "SOCKET" > "URL" > "FILE-LINK" > "SECURITY" > "SQL" > "LOGGING" > "PROPERTY" > "MBEAN" > "MBEAN-SERVER" > "MBEAN-TRUST" > "SUBJECT-DELEGATION" > "TLS" > "AUTH" > "KERBEROS-DELEGATION" > "KERBEROS-SERVICE" > "PRIVATE-CREDENTIAL" > "AUDIO" > "JAXB" > "WEB-SERVICE" > > I would like to suggest adding a new provider type: > > "PARSE-DATA" - To be called by any code about to parse data, eg > deserialization, XML, JSON, SQL, etc.? Granted to users, so that it > can only be performed after authentication. > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon Jun 14 07:35:19 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 17:35:19 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> My thoughts on how to proceed with this is: 1. Develop authorization layer security provider services in OpenJDK, back port it to Java 8 and Java 11 (these provide most of the utilised functionality of SecurityManager, allowing developers to only implement those which they need, without enabling SecurityManager and editing policy files). 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. 3. Leave AccessController and AccessControlContext in place, provide a security property that allows the stack walk to be disabled (One ProtectionDomain to represent all code in JVM, without any permissions, later making it the default, while allowing it to be enabled) and continue to inject user Subject principles using SubjectDomainCombiner for JAAS compatibility. Developers can implement just the authorization they feel necessary for users and develop their own configuration, or adapt existing. 4. At some point, preferably when StackWalker has equivalent performance, replace the internals of AccessController. Gut feel is that removal of AccessController, AccessControlContext and DomainCombiner causes carnage with JAAS, it's a lot to deal with, SecurityManager and Policy, I don't need them if I've got authorization layer hooks in the JVM. I wouldn't want to see SecurityManager and Policy be neutralized, it's better to remove it and fail early so people update their software, there's a risk they may update without realizing it's no longer fully functional.?? Get rid of the baggage so people can start fresh with better practices. Note that I'll be implementing a full authorization layer based on least privilege principles, that still utilizes a stack walk. I won't use the standard Java Permission implementations, as I'd like to do things a little differently, for usability reasons, this will do everything I need at least.? If the authorization layer is back ported, then I can support all current versions. My policy files are generated, so I don't need permission implementations to remain compatible. Whatever happens with JAAS will need to be backported, so we can support all versions. Regards, Peter. On 14/06/2021 3:54 pm, Alan Bateman wrote: > cc'ing security-dev as that is the mailing list to use for this JEP. > > This JEP is the first of several in a multi-release/multi-year effort. > It's way too early to give any guess as to when the APIs will be > removed. As the JEP says, future releases may degrade the SM APIs so > that System.getSM returns always returns null or > AccessController::doPriv just runs the action. This should mean that > libraries that are compiling to older releases should continue to > compile and run on those releases. When they run on some future > release that degrades the implementation then it will be as if there > is no SM.? So I would say the impact is little to none for libraries > for the foreseeable future. > > -Alan > > > On 13/06/2021 21:28, Rafael Winterhalter wrote: >> I am currently looking into how I should address JEP 411 in my >> library Byte >> Buddy and I find it rather challenging. The problem I am facing is >> that I >> know of several users who rely on the security manager in their Java >> 8/11 >> applications. I would like to continue to support those users' use >> cases as >> long as I support Java versions that contain the security manager, which >> will be for many years to come. At the same time, I would like to >> address >> the announced removal of the API and make sure that Byte Buddy can work >> without it prior to the deadline when the library in its current state >> would no longer link. >> >> ?From my understanding of the intention of JEP 411, the API was >> supposed to >> be stubbed ? similar to Android?s stubbing of the API - rather than >> being >> removed. However, with the announced deprecation for removal of >> AccessController and SecurityManager, I understand that I would need to >> fully remove the dispatching to work with future Java versions. >> >> Furthermore, it is difficult to create a working facade for >> dispatching to >> the security manager only if it is available. Methods like >> AccessController.doPrivileged are caller sensitive and by adding a >> utility >> to a library, this utility would leak to any potential user. It would >> therefore require package-private dispatchers for any relevant package, >> which would lead to a lot of copy-paste to retain backwards >> compatibility >> (given that a library cannot assume to be run as a module). >> >> Finally, removing the API would mean that Byte Buddy versions of the >> last >> ten years would no longer link in future JDKs. For Byte Buddy where new >> Java versions often require an update, that might not be a big issue but >> many other libraries do support the API, I don?t feel it would be a >> rather >> severe restriction and cause unnecessary breakage if API is removed, >> rather >> than stubbed. I am thinking of libraries like Netty here which are >> rather >> omnipresent and would suddenly no longer link, a concept that is >> unlikely >> intuitive to a lot of developers. >> >> Therefore, my question is: should SecurityManager, AccessController >> and the >> Policy APIs really be deprecated for removal? Rather, I think that >> the APIs >> should be deprecated, but be retained with stubbed implementations. >> System.getSecurityMananger would then always return null. >> System.setSecurityManager on the other hand could be deprecated for >> removal. This way, existing code could continue to work as if the >> security >> manager is not active, which already is the common scenario and would >> not >> cause any disruption at the small price of keeping a handful of some >> stubbed classes. >> >> Thanks for advice on how this is intended to be handled by library >> developers like me. >> Best regards, Rafael > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon Jun 14 07:52:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 17:52:20 +1000 Subject: Low level hooks in JDK for permission checks. Message-ID: <3ebd4dba-84f4-d69c-c455-9c09fe37cc7d@zeus.net.au> Making things clearer if I can: Some thoughts on hooks: * Utilize java.security.Provider, so as not to expose jdk implementation code.? Eg: a module declaration or META-INF/services/java.security.Provider to obtain relevant instances of java.security.Guard, where Permission implementation types are currently used. * Allow existing Permission classes to remain backward compatible, declare them as services, so that SecurityManager can be degraded as planned and Permission implementations can be gradually removed as planned. (Removes dependencies on Permission instance types). * Guard implementation's are typically required to have a constructor with two String arguments, (String name, String actions), can be passed as new String[]{ name, actions} constructor parameter to java.security.Provider.Service::newInstance. * Service must implement Guard interface, with Guard::check method (current Permission implementations implement this method and call System.getSecurityManager). * Doesn't depend on Permission or any existing implementation classes, completely customizable by the service implementation. * Application developers can also implement hooks using this service. * Using security provider avoids deadlock during Provider initialization, it must be listed as a provider in the java.security file or if security.overridePropertiesFile=true and -Djava.security.properties=file://path/additional.security defines providers, which would be useful for testing. Break up guard service providers into current Permission types (independent instances to avoid circular deadlocks), developers only need implement those relevant to them and may only use checks for users if they wish: "AWT" "FILE" "SERIALIZABLE" "MANAGEMENT" "REFLECT" "RUNTIME" "NET" "SOCKET" "URL" "FILE-LINK" "SECURITY" "SQL" "LOGGING" "PROPERTY" "MBEAN" "MBEAN-SERVER" "MBEAN-TRUST" "SUBJECT-DELEGATION" "TLS" "AUTH" "KERBEROS-DELEGATION" "KERBEROS-SERVICE" "PRIVATE-CREDENTIAL" "AUDIO" "JAXB" "WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc.? Granted to users, so that it can only be performed after authentication. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 14 08:37:10 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jun 2021 09:37:10 +0100 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> On 14/06/2021 08:35, Peter Firmstone wrote: > > I wouldn't want to see SecurityManager and Policy be neutralized, it's > better to remove it and fail early so people update their software, > there's a risk they may update without realizing it's no longer fully > functional.?? Get rid of the baggage so people can start fresh with > better practices. > I think the context for the question is libraries that want to be able to compile to an older JDK release and work with a very wide range of JDK releases. Many libraries do not play well with a SM. They don't execute actions that require permission checks in privileged blocks and will often need to be granted AllPermission. This may have knock on impact to the components that call into these libraries, maybe they end up needing to be? granted AllPermission too. Add callbacks or hand-off between threads to the picture and it can become farcical. If the library code isn't calling System.getSM or invoking AccessController.doPrivileged then it probably won't care if these APIs are degraded or removed. There are some libraries where the maintainers have put effort into working with a SM. Code in the library may use System.getSM, or doPriv or limited-doPriv. It may document the permissions that it requires and be helpful to someone assembling an application and creating its policy file. This JEP is mildly disruptive in that there will be warnings at compile-time or testing JDK 17+. If some future JDK releases degrades some of these APIs then it may be a bit more disruptive, maybe tests that try to set a SM will fail or need to be skipped. It might be that a library uses an exotic API that doesn't degrade in a sensible way and maybe that will be a bit more disruptive. Further out again, if the APIs are actually removed then it will be disruptive for libraries that want to support the possibility of being deployed with a SM on an older release. That may require some refactoring and the use of a MR-JAR as Remi mentioned. -Alan From peter.firmstone at zeus.net.au Mon Jun 14 09:23:39 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 19:23:39 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> Message-ID: Binary compatibility only? Security.getSecurityManager() always returns null. Security.setSecurityManager() always throws a SecurityException (compatible because existing SecurityManager is allowed to prevent the call from succeeding). SecurityManager constructor always throws a SecurityException (compatible because existing SecurityManager is allowed to prevent the call from succeeding). Remove all methods from SecurityManager, no instances will be created, so methods will not be resolved, still binary compatible. For Policy, retain methods and constructor, throwing appropriate exceptions, eg SecurityException or NoSuchAlgorithmException. Note that constructor will throw no exception, the exception will be thrown when? attempting to set Policy. Remove PolicyFile implementation. Leave PolicySPI as is, but don't load them. The first step would be to provide low level JDK hooks that allow for equivalent functionality to be implemented, back-porting to all long term releases, while leaving SecurityManager unchanged. Then change SecurityManager prior to next LTS version (Java 23) to binary compatible only.? Then prior to the next LTS version (Java 29), remove it. Maintained software will have had plenty of time to update and be compatible across all supported Java releases, provided appropriate JDK hooks are provided, only unmaintained software will still require it and unmaintained software will still run on unmaintained Java releases in VM's with unmaintained OS's. Peter. On 14/06/2021 6:37 pm, Alan Bateman wrote: > On 14/06/2021 08:35, Peter Firmstone wrote: >> >> I wouldn't want to see SecurityManager and Policy be neutralized, >> it's better to remove it and fail early so people update their >> software, there's a risk they may update without realizing it's no >> longer fully functional.?? Get rid of the baggage so people can start >> fresh with better practices. >> > I think the context for the question is libraries that want to be able > to compile to an older JDK release and work with a very wide range of > JDK releases. > > Many libraries do not play well with a SM. They don't execute actions > that require permission checks in privileged blocks and will often > need to be granted AllPermission. This may have knock on impact to the > components that call into these libraries, maybe they end up needing > to be? granted AllPermission too. Add callbacks or hand-off between > threads to the picture and it can become farcical. If the library code > isn't calling System.getSM or invoking AccessController.doPrivileged > then it probably won't care if these APIs are degraded or removed. > > There are some libraries where the maintainers have put effort into > working with a SM. Code in the library may use System.getSM, or doPriv > or limited-doPriv. It may document the permissions that it requires > and be helpful to someone assembling an application and creating its > policy file. This JEP is mildly disruptive in that there will be > warnings at compile-time or testing JDK 17+. If some future JDK > releases degrades some of these APIs then it may be a bit more > disruptive, maybe tests that try to set a SM will fail or need to be > skipped. It might be that a library uses an exotic API that doesn't > degrade in a sensible way and maybe that will be a bit more > disruptive. Further out again, if the APIs are actually removed then > it will be disruptive for libraries that want to support the > possibility of being deployed with a SM on an older release. That may > require some refactoring and the use of a MR-JAR as Remi mentioned. > > -Alan From ron.pressler at oracle.com Mon Jun 14 09:26:12 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 14 Jun 2021 09:26:12 +0000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> The JEP addresses this: > In future JDK releases, we will degrade the Security Manager APIs so that they remain in place but have limited or no functionality. ... This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing so declines to an acceptable level. If your question is, when only few codebases will refer to the API and the compatibility impact is low enough for it to be removed, what if some of those few libraries still want to support versions prior to the removal, the answer is the same as with all removals (MR-JARs, or multiple artefacts). By definition, the impact of complete removal when the impact is low, would be low. ? Ron > On 14 Jun 2021, at 09:38, Rafael Winterhalter wrote: > > One example for a currently necessary "doPrivileged" are Java agents where > a class loading triggers agent code where the agent shares the stack with > any code that loads a class for the first time. Otherwise, Byte Buddy wraps > anything that might require privileges as privileged action to allow > setting a policy that gives Byte Buddy for example access to class loaders, > system properties or other things that the security manager currently > checks. There's many uses of the security manager throughout the library, > in the spirit of the API's invention. > > I could, of course, rip this code out of the library. But this would make > it impossible for users that choose to use the functionality for now to > update their dependency. This would certainly hinder a smooth transition as > library maintainers will always have people drag at both ends of the JDK > version range. After all, Java 8 is supported for another decade. > Multi-release jars are neither a feasible option. They are not globally > supported by all class loaders, and would require me to add a copy of an > adjusted class file for any Java version prior to the removal version or > upwards from there. I don't think that this should be addressed by tooling > if keeping deprecated skeletons of the API can so easily avoid this entire > problem for all libraries without the need to chase down maintainers. > > Therefore, I really think that the SecurityManager and AccessController > APIs should remain as skeletons and be deprecated, but not be marked > forRemoval, especially without a clear roadmap for the actual removal > forward. And while I appreciate the clean up effort - I do think the > SecurityManager deprecation and feature removal is a right decision - I > find the attempt to remove this API will cause unnecessary breakage and > cause thousands of libraries to become unlinkable on future VM, without a > clear need for it. Discovering this breakage would also require manually > scanning the content of each library and affect all the big names in the > industry. This would require big waves of dependency updates, where such > updates sometimes will be impossible if only a single (transitive) > dependency has not catched up, including major names such as Spring, > Hibernate or Mockito. From experience, such major updating waves are often > complex and therefore avoided, which will hinder adoption of future JVM > versions. This seems like a very high price to pay which could be easily > avoided by only keeping a handful of skeleton classes. > > Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < > Alan.Bateman at oracle.com>: > >> cc'ing security-dev as that is the mailing list to use for this JEP. >> >> This JEP is the first of several in a multi-release/multi-year effort. >> It's way too early to give any guess as to when the APIs will be >> removed. As the JEP says, future releases may degrade the SM APIs so >> that System.getSM returns always returns null or >> AccessController::doPriv just runs the action. This should mean that >> libraries that are compiling to older releases should continue to >> compile and run on those releases. When they run on some future release >> that degrades the implementation then it will be as if there is no SM. >> So I would say the impact is little to none for libraries for the >> foreseeable future. >> >> -Alan >> >> >> On 13/06/2021 21:28, Rafael Winterhalter wrote: >>> I am currently looking into how I should address JEP 411 in my library >> Byte >>> Buddy and I find it rather challenging. The problem I am facing is that I >>> know of several users who rely on the security manager in their Java 8/11 >>> applications. I would like to continue to support those users' use cases >> as >>> long as I support Java versions that contain the security manager, which >>> will be for many years to come. At the same time, I would like to address >>> the announced removal of the API and make sure that Byte Buddy can work >>> without it prior to the deadline when the library in its current state >>> would no longer link. >>> >>> From my understanding of the intention of JEP 411, the API was supposed >> to >>> be stubbed ? similar to Android?s stubbing of the API - rather than being >>> removed. However, with the announced deprecation for removal of >>> AccessController and SecurityManager, I understand that I would need to >>> fully remove the dispatching to work with future Java versions. >>> >>> Furthermore, it is difficult to create a working facade for dispatching >> to >>> the security manager only if it is available. Methods like >>> AccessController.doPrivileged are caller sensitive and by adding a >> utility >>> to a library, this utility would leak to any potential user. It would >>> therefore require package-private dispatchers for any relevant package, >>> which would lead to a lot of copy-paste to retain backwards compatibility >>> (given that a library cannot assume to be run as a module). >>> >>> Finally, removing the API would mean that Byte Buddy versions of the last >>> ten years would no longer link in future JDKs. For Byte Buddy where new >>> Java versions often require an update, that might not be a big issue but >>> many other libraries do support the API, I don?t feel it would be a >> rather >>> severe restriction and cause unnecessary breakage if API is removed, >> rather >>> than stubbed. I am thinking of libraries like Netty here which are rather >>> omnipresent and would suddenly no longer link, a concept that is unlikely >>> intuitive to a lot of developers. >>> >>> Therefore, my question is: should SecurityManager, AccessController and >> the >>> Policy APIs really be deprecated for removal? Rather, I think that the >> APIs >>> should be deprecated, but be retained with stubbed implementations. >>> System.getSecurityMananger would then always return null. >>> System.setSecurityManager on the other hand could be deprecated for >>> removal. This way, existing code could continue to work as if the >> security >>> manager is not active, which already is the common scenario and would not >>> cause any disruption at the small price of keeping a handful of some >>> stubbed classes. >>> >>> Thanks for advice on how this is intended to be handled by library >>> developers like me. >>> Best regards, Rafael >> >> From peter.firmstone at zeus.net.au Mon Jun 14 09:33:33 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 19:33:33 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> Message-ID: On 14/06/2021 6:37 pm, Alan Bateman wrote: > > There are some libraries where the maintainers have put effort into > working with a SM. Yes, I am one of them, very much so. At first it's a shock, but the show must go on, it could be an opportunity to address some long standing issues also. If Permission implementations are unmaintained, we are better off without them too and re implementing our own.?? It doesn't matter what they change to, I can generate my policy files. AccessController, AccessControlContext and DomainController are bigger fish, which will take longer, personally I wouldn't remove these classes, but it's not my choice. -- Regards, Peter. From jwilhelm at openjdk.java.net Mon Jun 14 14:36:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 14:36:59 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" - 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64 - 8268470: CDS dynamic dump asserts with JFR RecordingStream - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE - 8268602: a couple runtime/os tests don't check exit code - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 - 8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode - 8268565: runtime/records/RedefineRecord.java should be run in driver mode - 8268576: jdk/jfr/event/gc/collection/TestSystemGc.java fails - ... and 3 more: https://git.openjdk.java.net/jdk/compare/74007890...b3185354 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/4484/files Stats: 786 lines in 57 files changed: 593 ins; 73 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/4484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4484/head:pull/4484 PR: https://git.openjdk.java.net/jdk/pull/4484 From rafael.wth at gmail.com Mon Jun 14 08:38:05 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 14 Jun 2021 10:38:05 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: One example for a currently necessary "doPrivileged" are Java agents where a class loading triggers agent code where the agent shares the stack with any code that loads a class for the first time. Otherwise, Byte Buddy wraps anything that might require privileges as privileged action to allow setting a policy that gives Byte Buddy for example access to class loaders, system properties or other things that the security manager currently checks. There's many uses of the security manager throughout the library, in the spirit of the API's invention. I could, of course, rip this code out of the library. But this would make it impossible for users that choose to use the functionality for now to update their dependency. This would certainly hinder a smooth transition as library maintainers will always have people drag at both ends of the JDK version range. After all, Java 8 is supported for another decade. Multi-release jars are neither a feasible option. They are not globally supported by all class loaders, and would require me to add a copy of an adjusted class file for any Java version prior to the removal version or upwards from there. I don't think that this should be addressed by tooling if keeping deprecated skeletons of the API can so easily avoid this entire problem for all libraries without the need to chase down maintainers. Therefore, I really think that the SecurityManager and AccessController APIs should remain as skeletons and be deprecated, but not be marked forRemoval, especially without a clear roadmap for the actual removal forward. And while I appreciate the clean up effort - I do think the SecurityManager deprecation and feature removal is a right decision - I find the attempt to remove this API will cause unnecessary breakage and cause thousands of libraries to become unlinkable on future VM, without a clear need for it. Discovering this breakage would also require manually scanning the content of each library and affect all the big names in the industry. This would require big waves of dependency updates, where such updates sometimes will be impossible if only a single (transitive) dependency has not catched up, including major names such as Spring, Hibernate or Mockito. From experience, such major updating waves are often complex and therefore avoided, which will hinder adoption of future JVM versions. This seems like a very high price to pay which could be easily avoided by only keeping a handful of skeleton classes. Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > cc'ing security-dev as that is the mailing list to use for this JEP. > > This JEP is the first of several in a multi-release/multi-year effort. > It's way too early to give any guess as to when the APIs will be > removed. As the JEP says, future releases may degrade the SM APIs so > that System.getSM returns always returns null or > AccessController::doPriv just runs the action. This should mean that > libraries that are compiling to older releases should continue to > compile and run on those releases. When they run on some future release > that degrades the implementation then it will be as if there is no SM. > So I would say the impact is little to none for libraries for the > foreseeable future. > > -Alan > > > On 13/06/2021 21:28, Rafael Winterhalter wrote: > > I am currently looking into how I should address JEP 411 in my library > Byte > > Buddy and I find it rather challenging. The problem I am facing is that I > > know of several users who rely on the security manager in their Java 8/11 > > applications. I would like to continue to support those users' use cases > as > > long as I support Java versions that contain the security manager, which > > will be for many years to come. At the same time, I would like to address > > the announced removal of the API and make sure that Byte Buddy can work > > without it prior to the deadline when the library in its current state > > would no longer link. > > > > From my understanding of the intention of JEP 411, the API was supposed > to > > be stubbed ? similar to Android?s stubbing of the API - rather than being > > removed. However, with the announced deprecation for removal of > > AccessController and SecurityManager, I understand that I would need to > > fully remove the dispatching to work with future Java versions. > > > > Furthermore, it is difficult to create a working facade for dispatching > to > > the security manager only if it is available. Methods like > > AccessController.doPrivileged are caller sensitive and by adding a > utility > > to a library, this utility would leak to any potential user. It would > > therefore require package-private dispatchers for any relevant package, > > which would lead to a lot of copy-paste to retain backwards compatibility > > (given that a library cannot assume to be run as a module). > > > > Finally, removing the API would mean that Byte Buddy versions of the last > > ten years would no longer link in future JDKs. For Byte Buddy where new > > Java versions often require an update, that might not be a big issue but > > many other libraries do support the API, I don?t feel it would be a > rather > > severe restriction and cause unnecessary breakage if API is removed, > rather > > than stubbed. I am thinking of libraries like Netty here which are rather > > omnipresent and would suddenly no longer link, a concept that is unlikely > > intuitive to a lot of developers. > > > > Therefore, my question is: should SecurityManager, AccessController and > the > > Policy APIs really be deprecated for removal? Rather, I think that the > APIs > > should be deprecated, but be retained with stubbed implementations. > > System.getSecurityMananger would then always return null. > > System.setSecurityManager on the other hand could be deprecated for > > removal. This way, existing code could continue to work as if the > security > > manager is not active, which already is the common scenario and would not > > cause any disruption at the small price of keeping a handful of some > > stubbed classes. > > > > Thanks for advice on how this is intended to be handled by library > > developers like me. > > Best regards, Rafael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.wth at gmail.com Mon Jun 14 11:34:26 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 14 Jun 2021 13:34:26 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> Message-ID: Why not add the property once this is the case, though? As it is now, I read the 'forRemoval' property to indicate a problem that should be instantly addressed. With Java 8 being a common baseline for libraries and the version being supported until (at least) 2030, I don't see how this removal would have a low impact within the next decade, if ever. Shouldn't the property be set if the removal is within reach? To some degree, I would expect that any deprecated API could be removed once it is no longer used. As it is now, library maintainers face the choice of breaking their support for current users that are on Java 8/11 and rely on the security manager, or to remove their support to accommodate a Java release that might be many years in the future. For my part, supporting the security manager seems to be the right choice as things stand today. Over the years, I would expect that fewer and fewer people rely on the security manager, where this balance might shift. I would hope that the 'forRemoval' property would serve as an indicator at that time to tell library maintainers that usage of the security manager has decreased so much that it is time to remove the library support, too. I see the reason for a strong signal, deprecation already is such a signal, but if you give the full blow today, it is no longer available in the future where it might be more relevant to give. Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler < ron.pressler at oracle.com>: > The JEP addresses this: > > > In future JDK releases, we will degrade the Security Manager APIs so > that they > remain in place but have limited or no functionality. ... This will allow > libraries > that support the Security Manager and were compiled against previous Java > releases > to continue to work without change or even recompilation. We expect to > remove the > APIs once the compatibility risk of doing so declines to an acceptable > level. > > If your question is, when only few codebases will refer to the API and the > compatibility impact is low enough for it to be removed, what if some of > those > few libraries still want to support versions prior to the removal, the > answer is > the same as with all removals (MR-JARs, or multiple artefacts). By > definition, > the impact of complete removal when the impact is low, would be low. > > ? Ron > > > On 14 Jun 2021, at 09:38, Rafael Winterhalter > wrote: > > > > One example for a currently necessary "doPrivileged" are Java agents > where > > a class loading triggers agent code where the agent shares the stack with > > any code that loads a class for the first time. Otherwise, Byte Buddy > wraps > > anything that might require privileges as privileged action to allow > > setting a policy that gives Byte Buddy for example access to class > loaders, > > system properties or other things that the security manager currently > > checks. There's many uses of the security manager throughout the library, > > in the spirit of the API's invention. > > > > I could, of course, rip this code out of the library. But this would make > > it impossible for users that choose to use the functionality for now to > > update their dependency. This would certainly hinder a smooth transition > as > > library maintainers will always have people drag at both ends of the JDK > > version range. After all, Java 8 is supported for another decade. > > Multi-release jars are neither a feasible option. They are not globally > > supported by all class loaders, and would require me to add a copy of an > > adjusted class file for any Java version prior to the removal version or > > upwards from there. I don't think that this should be addressed by > tooling > > if keeping deprecated skeletons of the API can so easily avoid this > entire > > problem for all libraries without the need to chase down maintainers. > > > > Therefore, I really think that the SecurityManager and AccessController > > APIs should remain as skeletons and be deprecated, but not be marked > > forRemoval, especially without a clear roadmap for the actual removal > > forward. And while I appreciate the clean up effort - I do think the > > SecurityManager deprecation and feature removal is a right decision - I > > find the attempt to remove this API will cause unnecessary breakage and > > cause thousands of libraries to become unlinkable on future VM, without a > > clear need for it. Discovering this breakage would also require manually > > scanning the content of each library and affect all the big names in the > > industry. This would require big waves of dependency updates, where such > > updates sometimes will be impossible if only a single (transitive) > > dependency has not catched up, including major names such as Spring, > > Hibernate or Mockito. From experience, such major updating waves are > often > > complex and therefore avoided, which will hinder adoption of future JVM > > versions. This seems like a very high price to pay which could be easily > > avoided by only keeping a handful of skeleton classes. > > > > Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < > > Alan.Bateman at oracle.com>: > > > >> cc'ing security-dev as that is the mailing list to use for this JEP. > >> > >> This JEP is the first of several in a multi-release/multi-year effort. > >> It's way too early to give any guess as to when the APIs will be > >> removed. As the JEP says, future releases may degrade the SM APIs so > >> that System.getSM returns always returns null or > >> AccessController::doPriv just runs the action. This should mean that > >> libraries that are compiling to older releases should continue to > >> compile and run on those releases. When they run on some future release > >> that degrades the implementation then it will be as if there is no SM. > >> So I would say the impact is little to none for libraries for the > >> foreseeable future. > >> > >> -Alan > >> > >> > >> On 13/06/2021 21:28, Rafael Winterhalter wrote: > >>> I am currently looking into how I should address JEP 411 in my library > >> Byte > >>> Buddy and I find it rather challenging. The problem I am facing is > that I > >>> know of several users who rely on the security manager in their Java > 8/11 > >>> applications. I would like to continue to support those users' use > cases > >> as > >>> long as I support Java versions that contain the security manager, > which > >>> will be for many years to come. At the same time, I would like to > address > >>> the announced removal of the API and make sure that Byte Buddy can work > >>> without it prior to the deadline when the library in its current state > >>> would no longer link. > >>> > >>> From my understanding of the intention of JEP 411, the API was supposed > >> to > >>> be stubbed ? similar to Android?s stubbing of the API - rather than > being > >>> removed. However, with the announced deprecation for removal of > >>> AccessController and SecurityManager, I understand that I would need to > >>> fully remove the dispatching to work with future Java versions. > >>> > >>> Furthermore, it is difficult to create a working facade for dispatching > >> to > >>> the security manager only if it is available. Methods like > >>> AccessController.doPrivileged are caller sensitive and by adding a > >> utility > >>> to a library, this utility would leak to any potential user. It would > >>> therefore require package-private dispatchers for any relevant package, > >>> which would lead to a lot of copy-paste to retain backwards > compatibility > >>> (given that a library cannot assume to be run as a module). > >>> > >>> Finally, removing the API would mean that Byte Buddy versions of the > last > >>> ten years would no longer link in future JDKs. For Byte Buddy where new > >>> Java versions often require an update, that might not be a big issue > but > >>> many other libraries do support the API, I don?t feel it would be a > >> rather > >>> severe restriction and cause unnecessary breakage if API is removed, > >> rather > >>> than stubbed. I am thinking of libraries like Netty here which are > rather > >>> omnipresent and would suddenly no longer link, a concept that is > unlikely > >>> intuitive to a lot of developers. > >>> > >>> Therefore, my question is: should SecurityManager, AccessController and > >> the > >>> Policy APIs really be deprecated for removal? Rather, I think that the > >> APIs > >>> should be deprecated, but be retained with stubbed implementations. > >>> System.getSecurityMananger would then always return null. > >>> System.setSecurityManager on the other hand could be deprecated for > >>> removal. This way, existing code could continue to work as if the > >> security > >>> manager is not active, which already is the common scenario and would > not > >>> cause any disruption at the small price of keeping a handful of some > >>> stubbed classes. > >>> > >>> Thanks for advice on how this is intended to be handled by library > >>> developers like me. > >>> Best regards, Rafael > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jun 14 15:43:27 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jun 2021 11:43:27 -0400 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> Message-ID: <0bc2acc3-2086-ffc4-c5e6-53bdbbaeaef0@oracle.com> On 6/14/21 7:34 AM, Rafael Winterhalter wrote: > Why not add the property once this is the case, though? As it is now, I > read the 'forRemoval' property to indicate a problem that should be > instantly addressed. With Java 8 being a common baseline for libraries and > the version being supported until (at least) 2030, I don't see how this > removal would have a low impact within the next decade, if ever. Shouldn't > the property be set if the removal is within reach? To some degree, I would > expect that any deprecated API could be removed once it is no longer used. > > As it is now, library maintainers face the choice of breaking their support > for current users that are on Java 8/11 and rely on the security manager, > or to remove their support to accommodate a Java release that might be many > years in the future. For my part, supporting the security manager seems to > be the right choice as things stand today. Over the years, I would expect > that fewer and fewer people rely on the security manager, where this > balance might shift. I would hope that the 'forRemoval' property would > serve as an indicator at that time to tell library maintainers that usage > of the security manager has decreased so much that it is time to remove the > library support, too. I see the reason for a strong signal, deprecation > already is such a signal, but if you give the full blow today, it is no > longer available in the future where it might be more relevant to give. As Alan and others have mentioned, there is no immediate plan to remove the APIs that SM-enabled libraries are typically dependent on, i.e., AccessController.doPrivileged and System.getSecurityManager. The APIs, when degraded will behave as if the Security Manager was not enabled. It isn't clear to me why that plan would have a high compatibility impact for libraries. And in JDK 17, the Security Manager will still be fully supported. The 'forRemoval' property means that the API is earmarked for removal in a future release. This is important, as it provides a clear warning bell to those that are dependent on it that it will eventually be going away. On the other hand, if an API is only deprecated, there is no intention to remove it. Users usually can still expect the API to continue to work as specified. It isn't as strong enough of a signal that it should not be used and in my opinion would only delay the removal of the Security Manager for many more years. I also think it would be more confusing, and possibly wrong to degrade or "stub" a deprecated API (one that is not marked forRemoval) such that it is a no-op or basically no longer works as expected. --Sean > > Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler < > ron.pressler at oracle.com>: > >> The JEP addresses this: >> >>> In future JDK releases, we will degrade the Security Manager APIs so >> that they >> remain in place but have limited or no functionality. ... This will allow >> libraries >> that support the Security Manager and were compiled against previous Java >> releases >> to continue to work without change or even recompilation. We expect to >> remove the >> APIs once the compatibility risk of doing so declines to an acceptable >> level. >> >> If your question is, when only few codebases will refer to the API and the >> compatibility impact is low enough for it to be removed, what if some of >> those >> few libraries still want to support versions prior to the removal, the >> answer is >> the same as with all removals (MR-JARs, or multiple artefacts). By >> definition, >> the impact of complete removal when the impact is low, would be low. >> >> ? Ron >> >>> On 14 Jun 2021, at 09:38, Rafael Winterhalter >> wrote: >>> >>> One example for a currently necessary "doPrivileged" are Java agents >> where >>> a class loading triggers agent code where the agent shares the stack with >>> any code that loads a class for the first time. Otherwise, Byte Buddy >> wraps >>> anything that might require privileges as privileged action to allow >>> setting a policy that gives Byte Buddy for example access to class >> loaders, >>> system properties or other things that the security manager currently >>> checks. There's many uses of the security manager throughout the library, >>> in the spirit of the API's invention. >>> >>> I could, of course, rip this code out of the library. But this would make >>> it impossible for users that choose to use the functionality for now to >>> update their dependency. This would certainly hinder a smooth transition >> as >>> library maintainers will always have people drag at both ends of the JDK >>> version range. After all, Java 8 is supported for another decade. >>> Multi-release jars are neither a feasible option. They are not globally >>> supported by all class loaders, and would require me to add a copy of an >>> adjusted class file for any Java version prior to the removal version or >>> upwards from there. I don't think that this should be addressed by >> tooling >>> if keeping deprecated skeletons of the API can so easily avoid this >> entire >>> problem for all libraries without the need to chase down maintainers. >>> >>> Therefore, I really think that the SecurityManager and AccessController >>> APIs should remain as skeletons and be deprecated, but not be marked >>> forRemoval, especially without a clear roadmap for the actual removal >>> forward. And while I appreciate the clean up effort - I do think the >>> SecurityManager deprecation and feature removal is a right decision - I >>> find the attempt to remove this API will cause unnecessary breakage and >>> cause thousands of libraries to become unlinkable on future VM, without a >>> clear need for it. Discovering this breakage would also require manually >>> scanning the content of each library and affect all the big names in the >>> industry. This would require big waves of dependency updates, where such >>> updates sometimes will be impossible if only a single (transitive) >>> dependency has not catched up, including major names such as Spring, >>> Hibernate or Mockito. From experience, such major updating waves are >> often >>> complex and therefore avoided, which will hinder adoption of future JVM >>> versions. This seems like a very high price to pay which could be easily >>> avoided by only keeping a handful of skeleton classes. >>> >>> Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < >>> Alan.Bateman at oracle.com>: >>> >>>> cc'ing security-dev as that is the mailing list to use for this JEP. >>>> >>>> This JEP is the first of several in a multi-release/multi-year effort. >>>> It's way too early to give any guess as to when the APIs will be >>>> removed. As the JEP says, future releases may degrade the SM APIs so >>>> that System.getSM returns always returns null or >>>> AccessController::doPriv just runs the action. This should mean that >>>> libraries that are compiling to older releases should continue to >>>> compile and run on those releases. When they run on some future release >>>> that degrades the implementation then it will be as if there is no SM. >>>> So I would say the impact is little to none for libraries for the >>>> foreseeable future. >>>> >>>> -Alan >>>> >>>> >>>> On 13/06/2021 21:28, Rafael Winterhalter wrote: >>>>> I am currently looking into how I should address JEP 411 in my library >>>> Byte >>>>> Buddy and I find it rather challenging. The problem I am facing is >> that I >>>>> know of several users who rely on the security manager in their Java >> 8/11 >>>>> applications. I would like to continue to support those users' use >> cases >>>> as >>>>> long as I support Java versions that contain the security manager, >> which >>>>> will be for many years to come. At the same time, I would like to >> address >>>>> the announced removal of the API and make sure that Byte Buddy can work >>>>> without it prior to the deadline when the library in its current state >>>>> would no longer link. >>>>> >>>>> From my understanding of the intention of JEP 411, the API was supposed >>>> to >>>>> be stubbed ? similar to Android?s stubbing of the API - rather than >> being >>>>> removed. However, with the announced deprecation for removal of >>>>> AccessController and SecurityManager, I understand that I would need to >>>>> fully remove the dispatching to work with future Java versions. >>>>> >>>>> Furthermore, it is difficult to create a working facade for dispatching >>>> to >>>>> the security manager only if it is available. Methods like >>>>> AccessController.doPrivileged are caller sensitive and by adding a >>>> utility >>>>> to a library, this utility would leak to any potential user. It would >>>>> therefore require package-private dispatchers for any relevant package, >>>>> which would lead to a lot of copy-paste to retain backwards >> compatibility >>>>> (given that a library cannot assume to be run as a module). >>>>> >>>>> Finally, removing the API would mean that Byte Buddy versions of the >> last >>>>> ten years would no longer link in future JDKs. For Byte Buddy where new >>>>> Java versions often require an update, that might not be a big issue >> but >>>>> many other libraries do support the API, I don?t feel it would be a >>>> rather >>>>> severe restriction and cause unnecessary breakage if API is removed, >>>> rather >>>>> than stubbed. I am thinking of libraries like Netty here which are >> rather >>>>> omnipresent and would suddenly no longer link, a concept that is >> unlikely >>>>> intuitive to a lot of developers. >>>>> >>>>> Therefore, my question is: should SecurityManager, AccessController and >>>> the >>>>> Policy APIs really be deprecated for removal? Rather, I think that the >>>> APIs >>>>> should be deprecated, but be retained with stubbed implementations. >>>>> System.getSecurityMananger would then always return null. >>>>> System.setSecurityManager on the other hand could be deprecated for >>>>> removal. This way, existing code could continue to work as if the >>>> security >>>>> manager is not active, which already is the common scenario and would >> not >>>>> cause any disruption at the small price of keeping a handful of some >>>>> stubbed classes. >>>>> >>>>> Thanks for advice on how this is intended to be handled by library >>>>> developers like me. >>>>> Best regards, Rafael >>>> >>>> >> >> From dcubed at openjdk.java.net Mon Jun 14 15:49:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 14 Jun 2021 15:49:59 GMT Subject: RFR: Merge jdk17 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 Thumbs up! Thanks for doing this sync forward. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4484 From jwilhelm at openjdk.java.net Mon Jun 14 16:02:24 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 16:02:24 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4484/files - new: https://git.openjdk.java.net/jdk/pull/4484/files/b3185354..b3185354 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4484&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4484&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4484/head:pull/4484 PR: https://git.openjdk.java.net/jdk/pull/4484 From dfuchs at openjdk.java.net Mon Jun 14 16:02:28 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Jun 2021 16:02:28 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: <2daAOoP8hnt5nqsZJasI5g1_QUovwyTwY3JutixTGik=.0bf9118f-8348-4f28-ba59-220c51a8732e@github.com> On Mon, 14 Jun 2021 15:58:15 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. Looked at this two changesets and they were fine. - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4484 From jwilhelm at openjdk.java.net Mon Jun 14 16:02:33 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 16:02:33 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 17295b1b Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea Stats: 721 lines in 30 files changed: 573 ins; 73 del; 75 mod Merge Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4484 From david.lloyd at redhat.com Mon Jun 14 16:23:13 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 14 Jun 2021 11:23:13 -0500 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone wrote: > 1. Develop authorization layer security provider services in OpenJDK, > back port it to Java 8 and Java 11 (these provide most of the > utilised functionality of SecurityManager, allowing developers to > only implement those which they need, without enabling > SecurityManager and editing policy files). > 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. The SecurityManager class itself already is *exactly* an authorization provider. I don't think it makes sense to consider removing the security manager class to replace it with something that has basically exactly the same API (specifically, a single method for each general authorization check that can be called without constructing any new objects, if and only if the authorization provider is installed). See my other proposal where, post-"removal", SecurityManager (the class) is retained but made abstract (and sans a few methods). All of the existing code which performs authorization checks would be retained and the problem solved in essentially the way you're describing, just using existing APIs. The security manager implementation itself can implement any kind of authorization behavior whatsoever, based mainly on the Permission types (which work just fine for this purpose, and anyway are already retained by the current JEP). Policy and its supporting classes are completely unnecessary for implementing a security policy. In fact, this is the case today already. On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: > AccessController::doPriv just runs the action. TBH this should have always been the case. Implementation-wise, if one were constructing an access control context based on stack walking, one would stop at points where `AccessController` is on the stack (which is easily determinable) to do special work on assembling the access control context based on the method called at that frame. -- - DML ? he/him From jai.forums2013 at gmail.com Mon Jun 14 16:59:47 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 14 Jun 2021 22:29:47 +0530 Subject: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages? Message-ID: <59b5a36b-cfac-691f-5cf9-6c587b2e4d1d@gmail.com> While testing the Apache Ant project with the latest released EA of JDK 17[1] (build 26), at least one of our internal test case has started failing. The failure relates to the new "WARNING" message that gets printed out to System.err when some code at runtime sets the security manager. The test case we have expects that the System.err stream contains only specific content. However, with this change, it now finds the expected content plus this additional warning message: WARNING: java.lang.System::setSecurityManager is deprecated and will be removed in a future release. Given the way the test is written, it doesn't like the presence of this additional content on System.err and fails. "Fixing" this test itself is pretty trivial for us and given that it's just one such test, I plan to just go ahead and do that tomorrow. However, what I'm more interested in is what part of the code at runtime is setting the security manager. I think even that part I can probably easily narrow it down tomorrow once I look into the code. But from what I imagine, this is going to be much more difficult to narrow down if the security manager is being set at runtime from third party library code, deep in the ecosystem of the deployed application (imagine some code embedding Ant project and invoking it from their project). I understand that the -Djava.security.manager system property allows the values "allow" and "disallow", but additionally would it be possible to introduce a new (optional) system property which takes a value "debug"? When this system property is set to "debug" and the Java runtime detects that a WARNING needs to be issued because of runtime setting of security manager, then a stacktrace is dumped showing the call location of each such code which is setting the security manager? This would be similar to the --illegal-access flag (although not a system property) that had the "debug" option, which I thought proved to be very useful when narrowing down the reflective access calls. [1] https://jdk.java.net/17/ -Jaikiran From sean.mullan at oracle.com Mon Jun 14 18:49:43 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jun 2021 14:49:43 -0400 Subject: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages? In-Reply-To: <59b5a36b-cfac-691f-5cf9-6c587b2e4d1d@gmail.com> References: <59b5a36b-cfac-691f-5cf9-6c587b2e4d1d@gmail.com> Message-ID: <55e7eb81-8391-9745-2074-7e7342c442a6@oracle.com> We already are working on improvements to the warning message to show the class and the source of the code calling System::setSecurityManager. See https://bugs.openjdk.java.net/browse/JDK-8268392 If that is not sufficient and a stack trace is really still needed, my preference would be to leverage the existing java.security.debug system property, and add a new value, say "sm" and that would additionally print a stack trace. But let's see if this is really needed first. --Sean On 6/14/21 12:59 PM, Jaikiran Pai wrote: > While testing the Apache Ant project with the latest released EA of JDK > 17[1] (build 26), at least one of our internal test case has started > failing. The failure relates to the new "WARNING" message that gets > printed out to System.err when some code at runtime sets the security > manager. The test case we have expects that the System.err stream > contains only specific content. However, with this change, it now finds > the expected content plus this additional warning message: > > WARNING: java.lang.System::setSecurityManager is deprecated and will be > removed in a future release. > > Given the way the test is written, it doesn't like the presence of this > additional content on System.err and fails. > > "Fixing" this test itself is pretty trivial for us and given that it's > just one such test, I plan to just go ahead and do that tomorrow. > However, what I'm more interested in is what part of the code at runtime > is setting the security manager. I think even that part I can probably > easily narrow it down tomorrow once I look into the code. But from what > I imagine, this is going to be much more difficult to narrow down if the > security manager is being set at runtime from third party library code, > deep in the ecosystem of the deployed application (imagine some code > embedding Ant project and invoking it from their project). > > I understand that the -Djava.security.manager system property allows the > values "allow" and "disallow", but additionally would it be possible to > introduce a new (optional) system property which takes a value "debug"? > When this system property is set to "debug" and the Java runtime detects > that a WARNING needs to be issued because of runtime setting of security > manager, then a stacktrace is dumped showing the call location of each > such code which is setting the security manager? This would be similar > to the --illegal-access flag (although not a system property) that had > the "debug" option, which I thought proved to be very useful when > narrowing down the reflective access calls. > > > [1] https://jdk.java.net/17/ > > -Jaikiran > > From michael.osipov at siemens.com Mon Jun 14 19:21:49 2021 From: michael.osipov at siemens.com (Osipov, Michael (LDA IT PLM)) Date: Mon, 14 Jun 2021 21:21:49 +0200 Subject: Incorrect encoding of PKCS12 bag attributes Message-ID: <12842ec5-b129-b437-5897-9ef96a78dfab@siemens.com> Folks, can someone confirm the following bug or tell me I am too stupid to read the RFCs: I have recently created a PKCS12-based trust store and had one CA from Hungary with non-ASCII chars in the subject's CN RDN. RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1: > > friendlyName ATTRIBUTE ::= { > WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName)) > EQUALITY MATCHING RULE caseIgnoreMatch > SINGLE VALUE TRUE > ID pkcs-9-at-friendlyName > } So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that Java ignores the RFC and always creates an UTF8String regardless of the attribute OID, thus breaking the semantics of friendlyName. Who's wrong here? For some strange reason OpenSSL does it in a similar fashion: In pkcs12.h.in: > # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8 where the function contains: > if (X509at_add1_attr_by_NID(&bag->attrib, NID_friendlyName, > MBSTRING_UTF8, (unsigned char *)name, namelen) != NULL) [1] https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/security/PKCS12Attribute.java#L230-L245 Regards, Michael From valeriep at openjdk.java.net Mon Jun 14 20:42:22 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Jun 2021 20:42:22 GMT Subject: [jdk17] Integrated: 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers In-Reply-To: <2jITaJEEIZFJOmcta7W5ahERMHUyU_xI-J38sasQb3w=.552fffd0-ed00-4f73-a429-e307d15824c5@github.com> References: <2jITaJEEIZFJOmcta7W5ahERMHUyU_xI-J38sasQb3w=.552fffd0-ed00-4f73-a429-e307d15824c5@github.com> Message-ID: On Fri, 11 Jun 2021 21:22:49 GMT, Valerie Peng wrote: > Could someone help review this straightforward fix? The current impl for AES KW and KWP cipher should check for possible null iv value in its CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated the regression test to cover this scenario as well as some other minor updates. > > Thanks! > Valerie This pull request has now been integrated. Changeset: ee301596 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk17/commit/ee3015968d56ed6179b6bfbde3f004500dce2ce3 Stats: 50 lines in 4 files changed: 34 ins; 3 del; 13 mod 8268621: SunJCE provider may throw unexpected NPE for un-initialized AES KW/KWP Ciphers Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk17/pull/34 From valeriep at openjdk.java.net Mon Jun 14 20:43:18 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Jun 2021 20:43:18 GMT Subject: [jdk17] Integrated: 8267397: AlgorithmId's OID cache is never refreshed In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 05:45:35 GMT, Valerie Peng wrote: > Could someone help review this small fix? This clears the static aliasOidsTable field in AlgorithmId class when provider list is changed. Enhanced existing regression test to cover the provider removal scenario. > > Thanks, > Valerie This pull request has now been integrated. Changeset: f69e2d56 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk17/commit/f69e2d5651f239209543bc1daf707a1c1114f6e5 Stats: 105 lines in 3 files changed: 76 ins; 20 del; 9 mod 8267397: AlgorithmId's OID cache is never refreshed Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk17/pull/36 From weijun at openjdk.java.net Mon Jun 14 22:34:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 14 Jun 2021 22:34:03 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v3] In-Reply-To: References: Message-ID: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: new warning text again (6/14) ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/13/files - new: https://git.openjdk.java.net/jdk17/pull/13/files/c62dff99..cb732f99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=01-02 Stats: 17 lines in 2 files changed: 0 ins; 2 del; 15 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13 From peter.firmstone at zeus.net.au Mon Jun 14 23:47:38 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 15 Jun 2021 09:47:38 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On 15/06/2021 2:23 am, David Lloyd wrote: > On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone > wrote: >> 1. Develop authorization layer security provider services in OpenJDK, >> back port it to Java 8 and Java 11 (these provide most of the >> utilised functionality of SecurityManager, allowing developers to >> only implement those which they need, without enabling >> SecurityManager and editing policy files). >> 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. > The SecurityManager class itself already is *exactly* an authorization > provider. I don't think it makes sense to consider removing the > security manager class to replace it with something that has basically > exactly the same API Logic behind this choice: SecurityManager depends on Permission, currently there are Permission checks throughout the JVM, however Permission implementation classes will be removed, although the Permission class itself won't be. Permission references can be replaced with Guard references (which Permissions are instances of). The Permission implementations of Guard::check call SecurityManager, so checks will continue working as expected, but it allows us to intercept them and do something different. By replacing Permission references with Guard, it allows us to implement our own checks in these locations, and OpenJDK doesn't need to maintain Permission instances, and or, we don't need to make use of unmaintained Permission implementations. There are already issues with Permission implementations, take for example SocketPermission, it consults DNS and it isn't possible to enter a range of IP addresses (such as the local subnet, and a list of public IP addresses), for now, every single IP address must be entered and this isn't practical.?? The proposed API would allow us to re-implement SocketPermission functionality, as well as other Permission implementations. This proposal also allows every existing component of the SM architecture to be removed, while retaining the most important component, the checks themselves, such that you or I or anyone else for that matter can re-implement the functionality of SM. SM and friends will be removed eventually, so now is our opportunity to get something in place that has minimal impact on OpenJDK maintenance, that will remain. > (specifically, a single method for each general > authorization check that can be called without constructing any new > objects, if and only if the authorization provider is installed). See > my other proposal where, post-"removal", SecurityManager (the class) > is retained but made abstract (and sans a few methods). All of the > existing code which performs authorization checks would be retained > and the problem solved in essentially the way you're describing, just > using existing APIs. > > The security manager implementation itself can implement any kind of > authorization behavior whatsoever, based mainly on the Permission > types (which work just fine for this purpose, and anyway are already > retained by the current JEP). Policy and its supporting classes are > completely unnecessary for implementing a security policy. In fact, > this is the case today already. > > On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: >> AccessController::doPriv just runs the action. > TBH this should have always been the case. Implementation-wise, if > one were constructing an access control context based on stack > walking, one would stop at points where `AccessController` is on the > stack (which is easily determinable) to do special work on assembling > the access control context based on the method called at that frame. Yes, one can do that, but these classes will also eventually be removed. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From ecki at zusammenkunft.net Tue Jun 15 00:15:59 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 15 Jun 2021 00:15:59 +0000 Subject: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages? In-Reply-To: <55e7eb81-8391-9745-2074-7e7342c442a6@oracle.com> References: <59b5a36b-cfac-691f-5cf9-6c587b2e4d1d@gmail.com>, <55e7eb81-8391-9745-2074-7e7342c442a6@oracle.com> Message-ID: Is it possible to redirect those vm messages with unified logging or vm-error files or similar command line flags to the launcher to keep stdout/stderr clean? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Sean Mullan Gesendet: Monday, June 14, 2021 8:49:43 PM An: Jaikiran Pai ; security-dev at openjdk.java.net Betreff: Re: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages? We already are working on improvements to the warning message to show the class and the source of the code calling System::setSecurityManager. See https://bugs.openjdk.java.net/browse/JDK-8268392 If that is not sufficient and a stack trace is really still needed, my preference would be to leverage the existing java.security.debug system property, and add a new value, say "sm" and that would additionally print a stack trace. But let's see if this is really needed first. --Sean On 6/14/21 12:59 PM, Jaikiran Pai wrote: > While testing the Apache Ant project with the latest released EA of JDK > 17[1] (build 26), at least one of our internal test case has started > failing. The failure relates to the new "WARNING" message that gets > printed out to System.err when some code at runtime sets the security > manager. The test case we have expects that the System.err stream > contains only specific content. However, with this change, it now finds > the expected content plus this additional warning message: > > WARNING: java.lang.System::setSecurityManager is deprecated and will be > removed in a future release. > > Given the way the test is written, it doesn't like the presence of this > additional content on System.err and fails. > > "Fixing" this test itself is pretty trivial for us and given that it's > just one such test, I plan to just go ahead and do that tomorrow. > However, what I'm more interested in is what part of the code at runtime > is setting the security manager. I think even that part I can probably > easily narrow it down tomorrow once I look into the code. But from what > I imagine, this is going to be much more difficult to narrow down if the > security manager is being set at runtime from third party library code, > deep in the ecosystem of the deployed application (imagine some code > embedding Ant project and invoking it from their project). > > I understand that the -Djava.security.manager system property allows the > values "allow" and "disallow", but additionally would it be possible to > introduce a new (optional) system property which takes a value "debug"? > When this system property is set to "debug" and the Java runtime detects > that a WARNING needs to be issued because of runtime setting of security > manager, then a stacktrace is dumped showing the call location of each > such code which is setting the security manager? This would be similar > to the --illegal-access flag (although not a system property) that had > the "debug" option, which I thought proved to be very useful when > narrowing down the reflective access calls. > > > [1] https://jdk.java.net/17/ > > -Jaikiran > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Tue Jun 15 01:00:36 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 15 Jun 2021 11:00:36 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> Message-ID: On 14/06/2021 9:34 pm, Rafael Winterhalter wrote: > Why not add the property once this is the case, though? > As it is now, I read the 'forRemoval' property to indicate a problem > that should be instantly addressed. I too suggested and support this approach. > With Java 8 being a common baseline for libraries and the version > being supported until (at least) 2030, I don't see how this removal > would have a low impact within the next decade, if ever. Shouldn't the > property be set if the removal is within reach? To some degree, I > would expect that any deprecated API could be removed once it is no > longer used. > > As it is now, library maintainers face the choice of breaking their > support for current users that are on Java 8/11 and rely on the > security manager, or to remove their support to accommodate a Java > release that might be many years in the future. For this reason, I'm proposing a minimal change allowing us to implement Guard::check hooks at existing check points within the JVM using the security provider mechanism that can be back-ported and supported on all LTS releases, without any new Java API's. We require authorization layer functionality, I will be implementing it, and it will be freely available under an AL2.0 license. It would be nice to keep AccessController and AccessControlContext and use a property to enable or disable the stack walk for those who don't require it, however they are now marked for removal, so I'll be looking at using wrapper classes around them, so their implementations can be replaced at a later data. Our current implementation is high scaling with minimal performance impact, however I can't make any promises regarding future performance, but hopefully it will come to be as performant as our current implementation. Regards, Peter. > For my part, supporting the security manager seems to be the right > choice as things stand today. > Over the years, I would expect that fewer and fewer people rely on the > security manager, where this balance might shift. I would hope that > the 'forRemoval' property would serve as an indicator at that time to > tell library maintainers that usage of the security manager has > decreased so much that it is time to remove the library support, too. > I see the reason for a strong signal, deprecation already is such a > signal, but if you give the full blow today, it is no longer available > in the future where it might be more relevant to give. > > Am Mo., 14. Juni 2021 um 11:26?Uhr schrieb Ron Pressler > >: > > The JEP addresses this: > > > In future JDK releases, we will degrade the Security Manager > APIs so that they > remain in place but have limited or no functionality. ... This > will allow libraries > that support the Security Manager and were compiled against > previous Java releases > to continue to work without change or even recompilation. We > expect to remove the > APIs once the compatibility risk of doing so declines to an > acceptable level. > > If your question is, when only few codebases will refer to the API > and the > compatibility impact is low enough for it to be removed, what if > some of those > few libraries still want to support versions prior to the removal, > the answer is > the same as with all removals (MR-JARs, or multiple artefacts). By > definition, > the impact of complete removal when the impact is low, would be low. > > ? Ron > > > On 14 Jun 2021, at 09:38, Rafael Winterhalter > > wrote: > > > > One example for a currently necessary "doPrivileged" are Java > agents where > > a class loading triggers agent code where the agent shares the > stack with > > any code that loads a class for the first time. Otherwise, Byte > Buddy wraps > > anything that might require privileges as privileged action to allow > > setting a policy that gives Byte Buddy for example access to > class loaders, > > system properties or other things that the security manager > currently > > checks. There's many uses of the security manager throughout the > library, > > in the spirit of the API's invention. > > > > I could, of course, rip this code out of the library. But this > would make > > it impossible for users that choose to use the functionality for > now to > > update their dependency. This would certainly hinder a smooth > transition as > > library maintainers will always have people drag at both ends of > the JDK > > version range. After all, Java 8 is supported for another decade. > > Multi-release jars are neither a feasible option. They are not > globally > > supported by all class loaders, and would require me to add a > copy of an > > adjusted class file for any Java version prior to the removal > version or > > upwards from there. I don't think that this should be addressed > by tooling > > if keeping deprecated skeletons of the API can so easily avoid > this entire > > problem for all libraries without the need to chase down > maintainers. > > > > Therefore, I really think that the SecurityManager and > AccessController > > APIs should remain as skeletons and be deprecated, but not be marked > > forRemoval, especially without a clear roadmap for the actual > removal > > forward. And while I appreciate the clean up effort - I do think the > > SecurityManager deprecation and feature removal is a right > decision - I > > find the attempt to remove this API will cause unnecessary > breakage and > > cause thousands of libraries to become unlinkable on future VM, > without a > > clear need for it. Discovering this breakage would also require > manually > > scanning the content of each library and affect all the big > names in the > > industry. This would require big waves of dependency updates, > where such > > updates sometimes will be impossible if only a single (transitive) > > dependency has not catched up, including major names such as Spring, > > Hibernate or Mockito. From experience, such major updating waves > are often > > complex and therefore avoided, which will hinder adoption of > future JVM > > versions. This seems like a very high price to pay which could > be easily > > avoided by only keeping a handful of skeleton classes. > > > > Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < > > Alan.Bateman at oracle.com >: > > > >> cc'ing security-dev as that is the mailing list to use for this > JEP. > >> > >> This JEP is the first of several in a multi-release/multi-year > effort. > >> It's way too early to give any guess as to when the APIs will be > >> removed. As the JEP says, future releases may degrade the SM > APIs so > >> that System.getSM returns always returns null or > >> AccessController::doPriv just runs the action. This should mean > that > >> libraries that are compiling to older releases should continue to > >> compile and run on those releases. When they run on some future > release > >> that degrades the implementation then it will be as if there is > no SM. > >> So I would say the impact is little to none for libraries for the > >> foreseeable future. > >> > >> -Alan > >> > >> > >> On 13/06/2021 21:28, Rafael Winterhalter wrote: > >>> I am currently looking into how I should address JEP 411 in my > library > >> Byte > >>> Buddy and I find it rather challenging. The problem I am > facing is that I > >>> know of several users who rely on the security manager in > their Java 8/11 > >>> applications. I would like to continue to support those users' > use cases > >> as > >>> long as I support Java versions that contain the security > manager, which > >>> will be for many years to come. At the same time, I would like > to address > >>> the announced removal of the API and make sure that Byte Buddy > can work > >>> without it prior to the deadline when the library in its > current state > >>> would no longer link. > >>> > >>> From my understanding of the intention of JEP 411, the API was > supposed > >> to > >>> be stubbed ? similar to Android?s stubbing of the API - rather > than being > >>> removed. However, with the announced deprecation for removal of > >>> AccessController and SecurityManager, I understand that I > would need to > >>> fully remove the dispatching to work with future Java versions. > >>> > >>> Furthermore, it is difficult to create a working facade for > dispatching > >> to > >>> the security manager only if it is available. Methods like > >>> AccessController.doPrivileged are caller sensitive and by adding a > >> utility > >>> to a library, this utility would leak to any potential user. > It would > >>> therefore require package-private dispatchers for any relevant > package, > >>> which would lead to a lot of copy-paste to retain backwards > compatibility > >>> (given that a library cannot assume to be run as a module). > >>> > >>> Finally, removing the API would mean that Byte Buddy versions > of the last > >>> ten years would no longer link in future JDKs. For Byte Buddy > where new > >>> Java versions often require an update, that might not be a big > issue but > >>> many other libraries do support the API, I don?t feel it would > be a > >> rather > >>> severe restriction and cause unnecessary breakage if API is > removed, > >> rather > >>> than stubbed. I am thinking of libraries like Netty here which > are rather > >>> omnipresent and would suddenly no longer link, a concept that > is unlikely > >>> intuitive to a lot of developers. > >>> > >>> Therefore, my question is: should SecurityManager, > AccessController and > >> the > >>> Policy APIs really be deprecated for removal? Rather, I think > that the > >> APIs > >>> should be deprecated, but be retained with stubbed > implementations. > >>> System.getSecurityMananger would then always return null. > >>> System.setSecurityManager on the other hand could be > deprecated for > >>> removal. This way, existing code could continue to work as if the > >> security > >>> manager is not active, which already is the common scenario > and would not > >>> cause any disruption at the small price of keeping a handful > of some > >>> stubbed classes. > >>> > >>> Thanks for advice on how this is intended to be handled by library > >>> developers like me. > >>> Best regards, Rafael > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Tue Jun 15 05:19:42 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 15 Jun 2021 10:49:42 +0530 Subject: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages? In-Reply-To: <55e7eb81-8391-9745-2074-7e7342c442a6@oracle.com> References: <59b5a36b-cfac-691f-5cf9-6c587b2e4d1d@gmail.com> <55e7eb81-8391-9745-2074-7e7342c442a6@oracle.com> Message-ID: <53e650af-6e94-c7c1-0919-952683ba7599@gmail.com> Hello Sean, On 15/06/21 12:19 am, Sean Mullan wrote: > We already are working on improvements to the warning message to show > the class and the source of the code calling > System::setSecurityManager. See > https://bugs.openjdk.java.net/browse/JDK-8268392 > I just had a look at that JBS issue and the proposed change. Specifically: " Instead, a warning is issued at run time when System::setSecurityManager is invoked, as follows: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by com.foo.bar.server (file:/tmp/foobarserver/thing.jar) WARNING: Please consider reporting this to the maintainers of com.foo.bar.server WARNING: System::setSecurityManager will be removed in a future release " I think this will help a lot as compared to what is presently logged. > If that is not sufficient and a stack trace is really still needed, my > preference would be to leverage the existing java.security.debug > system property, and add a new value, say "sm" and that would > additionally print a stack trace. But let's see if this is really > needed first. > I think what is proposed in that JBS issue should help in most of the cases. i.e. the stacktrace probably won't be necessary. However, just to make a note of it here - in the case of --illegal-access=debug the stacktrace had helped decide if a particular call path can be bypassed to get past the issue, instead of attaching some IDE debugger and figuring out why the specific class/method was doing what it was doing. As for which system property to use, I don't have any specific preference. I think the existing one is fine too. One thing that might need consideration is whether this would adversely impact applications which have java.security.debug system property set to "all" and they now start seeing these stacktraces of "sm" in the output. -Jaikiran From github.com+10835776+stsypanov at openjdk.java.net Tue Jun 15 12:22:50 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 15 Jun 2021 12:22:50 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable Message-ID: In some JDK classes there's still the following hashCode() implementation: long objNum; public int hashCode() { return (int) objNum; } This outdated expression should be replaced with Long.hashCode(long) as it - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. See https://stackoverflow.com/a/4045083 This is related to https://github.com/openjdk/jdk/pull/4309 ------------- Commit messages: - 8268764: Use Long.hashCode() instead of int-cast where applicable Changes: https://git.openjdk.java.net/jdk/pull/4491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268764 Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491 From rick.hillegas at gmail.com Tue Jun 15 14:10:35 2021 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Tue, 15 Jun 2021 07:10:35 -0700 Subject: blizzard of deprecation warnings related to JEP 411 Message-ID: Resending this message from the account associated with my security-dev subscription, in the hope that this will bypass moderation: Rory O'Donnell recommended that I bring this issue to the security developers' mailing list. I work on Apache Derby. Derby is one of the applications which receive advance notice of new Open JDK distributions. We then build our application with the new JDK's javac and javadoc tools and we run our full test suite against the new JVM. As a canary in the mineshaft, we noticed the following significant disruption. When I tried to build Derby with the Rampdown Phase One build of open JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation of Security Manager classes and methods, undoubtedly the consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, embraced the Security Manager early on. Permissions checks were rototilled across the whole code base and our distributions ship with several template policy files, which we encourage users to customize for their environments. The "Configuring Java Security" section of our Security Guide explains how to do this (https://db.apache.org/derby/docs/10.15/security/index.html). My build only reported the first 100 warnings. It is likely that there are many more. Having read the summary of JEP 411, I understand the motivation for this change. However, I don't understand how applications like Tomcat and Derby are supposed to respond to the new blizzard of deprecation warnings. For instance, is there a replacement for the deprecated AccessController.doPrivileged() method? Or are we supposed to simply disable this deprecation check? Is there some security expert whom I should contact about this change and how to mitigate its effects? Thanks, -Rick From Alan.Bateman at oracle.com Tue Jun 15 15:56:21 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jun 2021 16:56:21 +0100 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: References: Message-ID: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> On 15/06/2021 15:10, Rick Hillegas wrote: > : > > When I tried to build Derby with the Rampdown Phase One build of open > JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation > of Security Manager classes and methods, undoubtedly the consequence > of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, > embraced the Security Manager early on. Permissions checks were > rototilled across the whole code base and our distributions ship with > several template policy files, which we encourage users to customize > for their environments. The "Configuring Java Security" section of our > Security Guide explains how to do this > (https://db.apache.org/derby/docs/10.15/security/index.html). > > My build only reported the first 100 warnings. It is likely that there > are many more. Yes, JEP 411 deprecates a number of APIs for future removal. There probably isn't much to do right now except to be aware that the APIs are earmarked for removal in some future release. I've no doubt there will be another JEP when that time comes. I assume you know about @SuppressWarnings("removal"), which you can use to suppress the warnings for now. The JDK usages of these APIs are using SuppressWarnings as the JDK is compiled with -Xlint set to made warnings fatal. -Alan From jwilhelm at openjdk.java.net Tue Jun 15 22:01:09 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:01:09 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge jdk17 - 8268768: idea.sh has been updated in surprising and incompatible ways - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 - 8268723: Problem list SA core file tests on OSX when using ZGC - 8268736: Use apiNote in AutoCloseable.close javadoc - 8263321: Regression 8% in javadoc-steady in 17-b11 - 8268125: ZGC: Clone oop array gets wrong acopy stub - 8268663: Crash when guards contain boolean expression - 8268347: C2: nested locks optimization may create unbalanced monitor enter/exit code - 8268643: SVML lib shouldn't be generated when C2 is absent - ... and 7 more: https://git.openjdk.java.net/jdk/compare/0b09129f...e748b877 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4499/files Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From lancea at openjdk.java.net Tue Jun 15 22:04:33 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Jun 2021 22:04:33 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v3] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 22:34:03 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new warning text again (6/14) Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From rhalade at openjdk.java.net Tue Jun 15 22:26:45 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Tue, 15 Jun 2021 22:26:45 GMT Subject: RFR: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Message-ID: Test is updated to add expiry exception for "identrustdstx3 [jdk]" alias. ------------- Commit messages: - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Changes: https://git.openjdk.java.net/jdk/pull/4500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259338 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4500/head:pull/4500 PR: https://git.openjdk.java.net/jdk/pull/4500 From valeriep at openjdk.java.net Tue Jun 15 22:44:04 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Jun 2021 22:44:04 GMT Subject: [jdk17] RFR: 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes Message-ID: Could someone please help review this trivial fix? The real changes are the two PKCS11 cipher impl classes under src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of classes are just cleanups, e.g. dead code or unused code. The test/jdk/javax/crypto/Cipher/TestCipherMode.java is updated to cover more cipher impls for completeness sake. It passes without this fix, so I only add the bug id to the the other test, i.e. test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java, which verifies the PKCS#11 cipher impls. Thanks, Valerie ------------- Commit messages: - 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes Changes: https://git.openjdk.java.net/jdk17/pull/69/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=69&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265500 Stats: 308 lines in 8 files changed: 254 ins; 5 del; 49 mod Patch: https://git.openjdk.java.net/jdk17/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/69/head:pull/69 PR: https://git.openjdk.java.net/jdk17/pull/69 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:40 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:40 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: - Merge jdk17 - 8268620: InfiniteLoopException test may fail on x86 platforms Reviewed-by: prr, trebari, azvegint - 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: kvn, vlivanov - 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name Co-authored-by: Markus GaisBauer Reviewed-by: stuefe, luhenry - 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj - 8268699: Shenandoah: Add test for JDK-8268127 Reviewed-by: rkennke - Merge Reviewed-by: dcubed - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" Reviewed-by: prr - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Reviewed-by: dcubed, stefank, kbarrett - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck - ... and 15 more: https://git.openjdk.java.net/jdk/compare/6da37cd0...e748b877 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4499/files - new: https://git.openjdk.java.net/jdk/pull/4499/files/e748b877..e748b877 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:41 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:41 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 21:51:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: e0f6f70d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4499 From wetmore at openjdk.java.net Tue Jun 15 23:12:50 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 15 Jun 2021 23:12:50 GMT Subject: RFR: 8267485: Remove the dependency on SecurityManager in JceSecurityManager.java [v5] In-Reply-To: References: Message-ID: > The JceSecurityManager is currently a subclass of java.security.SecurityManager. Now that JEP 411 has been integrated, this class should be updated to no longer subclass SecurityManager. > > The only reason for using SecurityManager to easily get the Class Context (call stack), but we can achieve the same effect by using the JDK 9 API java.lang.StackWalkeer. None of the other SecurityManager API are used. > > I have run mach5 tier1/tier2 plus --test jck:api/java_security,jck:api/javax_crypto,jck:api/javax_net,jck:api/javax_security,jck:api/org_ietf,jck:api/javax_xml/crypto with all green. Bradford Wetmore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into JDK-8267485 - More Codereview Comments - Merge branch 'master' into JDK-8267485 - Minor typo - Reduced SuppressWarnings scope - Codereview Comments #2 - Merge branch 'master' into JDK-8267485 - Address codereview comments - Merge branch 'master' into JDK-8267485 - Merge branch 'master' into JDK-8267485 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/e0f6f70d...c542d9d7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4150&range=04 Stats: 30 lines in 1 file changed: 15 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4150/head:pull/4150 PR: https://git.openjdk.java.net/jdk/pull/4150 From peter.firmstone at zeus.net.au Wed Jun 16 00:23:01 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 16 Jun 2021 10:23:01 +1000 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> Message-ID: Rick, Out of curiosity, does Apache Derby have a need for an Authorization layer? We have tooling to generate our policy files, which simplifies the process a lot, we also have highly scalable and performant SecurityManager and Policy implementations which are compatible with standard Java policy files. This is available under an AL2.0 license. I'm hoping that OpenJDK will create some hooks for permission checks, so that we can continue to provide an authorization layer for Java, following JEP 411. I'll be using StackWalker to reproduce AccessController's stack walk.?? We also have existing classes which wrap AccessControlContext, so we would use ThreadLocal's to preserve subject. -- Regards, Peter. On 16/06/2021 1:56 am, Alan Bateman wrote: > On 15/06/2021 15:10, Rick Hillegas wrote: >> : >> >> When I tried to build Derby with the Rampdown Phase One build of open >> JDK 17 (17-ea+26-2439), I saw many warnings related to the >> deprecation of Security Manager classes and methods, undoubtedly the >> consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, >> like Tomcat, embraced the Security Manager early on. Permissions >> checks were rototilled across the whole code base and our >> distributions ship with several template policy files, which we >> encourage users to customize for their environments. The "Configuring >> Java Security" section of our Security Guide explains how to do this >> (https://db.apache.org/derby/docs/10.15/security/index.html). >> >> My build only reported the first 100 warnings. It is likely that >> there are many more. > > Yes, JEP 411 deprecates a number of APIs for future removal. There > probably isn't much to do right now except to be aware that the APIs > are earmarked for removal in some future release. I've no doubt there > will be another JEP when that time comes. I assume you know about > @SuppressWarnings("removal"), which you can use to suppress the > warnings for now. The JDK usages of these APIs are using > SuppressWarnings as the JDK is compiled with -Xlint set to made > warnings fatal. > > -Alan From yyang at openjdk.java.net Wed Jun 16 08:25:51 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 16 Jun 2021 08:25:51 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible Message-ID: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> After JDK-8265518, it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. ------------- Commit messages: - use checkIndex globally Changes: https://git.openjdk.java.net/jdk/pull/4507/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268698 Stats: 206 lines in 34 files changed: 31 ins; 111 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:22:49 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:22:49 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:05:06 GMT, Michael Bien wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. >> I checked only places where `Vector` was used as local variable. > > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 592: > >> 590: >> 591: SignerInfo[] result = new SignerInfo[intResult.size()]; >> 592: return intResult.toArray(result); > > could be simplified to > `return intResult.toArray(new SignerInfo[0]);` > which would eliminate array zeroing as bonus as I have learned from your other PR ;) I considered this, when I was preparing the patch. But decided to reduce scope of changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 16 09:22:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 16 Jun 2021 09:22:47 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. > I checked only places where `Vector` was used as local variable. I've filed https://bugs.openjdk.java.net/browse/JDK-8268873 for this, just put `/issue 8268873` as a comment for this ticket to bind it to the issue src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: > 152: while (tokenizer.hasMoreTokens()) > 153: v.add(tokenizer.nextToken()); > 154: ciphers = new String [v.size()]; Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+114367+mbien at openjdk.java.net Wed Jun 16 09:22:48 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Wed, 16 Jun 2021 09:22:48 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. > I checked only places where `Vector` was used as local variable. src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 592: > 590: > 591: SignerInfo[] result = new SignerInfo[intResult.size()]; > 592: return intResult.toArray(result); could be simplified to `return intResult.toArray(new SignerInfo[0]);` which would eliminate array zeroing as bonus as I have learned from your other PR ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:22:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:22:47 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base Message-ID: Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. I checked only places where `Vector` was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.base - [PATCH] Unnecessary Vector usage in JarIndex.read Changes: https://git.openjdk.java.net/jdk/pull/4482/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4482&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268873 Stats: 18 lines in 3 files changed: 1 ins; 4 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4482/head:pull/4482 PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:52:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:52:38 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> On Wed, 16 Jun 2021 09:01:30 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. >> I checked only places where `Vector` was used as local variable. > > src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: > >> 152: while (tokenizer.hasMoreTokens()) >> 153: v.add(tokenizer.nextToken()); >> 154: ciphers = new String [v.size()]; > > Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` It's not a drop-in replacement. Result is different for some Strings. For example for `, A` I would prefer to preserve existing behavior under this cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From david.lloyd at redhat.com Wed Jun 16 13:18:14 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 16 Jun 2021 08:18:14 -0500 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone wrote: > SecurityManager depends on Permission, currently there are Permission > checks throughout the JVM, however Permission implementation classes > will be removed, although the Permission class itself won't be. This is incorrect AFAICT. The relevant JEP text is: > Permission and subclasses ? Other significant classes, such as ProtectionDomain, depend on Permission. Many of the subclasses of Permission, however, are specific to use cases which will likely no longer be relevant after the Security Manager is removed. The maintainers of these subclasses can deprecate and remove them separately, after evaluating the compatibility risk. > Permission references can be replaced with Guard references (which > Permissions are instances of). I guess you've got something fairly complex in mind, could you give some practical examples of how this would work? > The Permission implementations of Guard::check call SecurityManager, so > checks will continue working as expected, but it allows us to intercept > them and do something different. What do you envision these checks looking like? Where would the JDK find these Guard instances? > By replacing Permission references with Guard, it allows us to implement > our own checks in these locations, and OpenJDK doesn't need to maintain > Permission instances, and or, we don't need to make use of unmaintained > Permission implementations. As I said I don't think there is an intention to remove the permission classes just yet, and I don't think that it is a fair statement to say that the permission implementations would be unmaintained. Most of those classes have not needed to be touched in many years; there's just not a lot of complexity there for the vast majority of them. > There are already issues with Permission implementations, take for > example SocketPermission, it consults DNS and it isn't possible to enter > a range of IP addresses (such as the local subnet, and a list of public > IP addresses), for now, every single IP address must be entered and this > isn't practical. The proposed API would allow us to re-implement > SocketPermission functionality, as well as other Permission implementations. Sure, this would be nice to clean up. I just don't understand the proposed mechanism. > > On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: > >> AccessController::doPriv just runs the action. > > TBH this should have always been the case. Implementation-wise, if > > one were constructing an access control context based on stack > > walking, one would stop at points where `AccessController` is on the > > stack (which is easily determinable) to do special work on assembling > > the access control context based on the method called at that frame. > > Yes, one can do that, but these classes will also eventually be removed. Sure. This was mainly a practical observation about the current implementation. And any replacement third-party stack-based authorization system could (and should) use a similar mechanism regardless of whether these exact methods stay in the JDK for 5 or 50 more years. -- - DML ? he/him From fguallini at openjdk.java.net Wed Jun 16 14:33:00 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 16 Jun 2021 14:33:00 GMT Subject: [jdk17] RFR: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" Message-ID: The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is failing intermittently because the client side is expecting a SocketException only if it is wrapped into a SSLException, but it should also expect a SocketException when there is no exception chaining. ------------- Commit messages: - SocketException may not be wrapped into SSLException Changes: https://git.openjdk.java.net/jdk17/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265297 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk17/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk17/pull/80 From rick.hillegas at gmail.com Wed Jun 16 15:00:09 2021 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Wed, 16 Jun 2021 08:00:09 -0700 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> Message-ID: <4b60bae9-684a-2b8b-628c-ebd2d2a8656f@gmail.com> Thanks, Peter. Derby supports a couple authorization mechanisms, the most important one being the role-based SQL Standard GRANT/REVOKE commands (see https://db.apache.org/derby/docs/10.15/security/csecauthorization.html). I'm afraid that my old eyes didn't see a link to your authorization libraries in your message. On 6/15/21 5:23 PM, Peter Firmstone wrote: > Rick, > > Out of curiosity, does Apache Derby have a need for an Authorization > layer? > > We have tooling to generate our policy files, which simplifies the > process a lot, we also have highly scalable and performant > SecurityManager and Policy implementations which are compatible with > standard Java policy files. > > This is available under an AL2.0 license. > > I'm hoping that OpenJDK will create some hooks for permission checks, > so that we can continue to provide an authorization layer for Java, > following JEP 411. > > I'll be using StackWalker to reproduce AccessController's stack > walk.?? We also have existing classes which wrap AccessControlContext, > so we would use ThreadLocal's to preserve subject. > From xuelei at openjdk.java.net Wed Jun 16 15:38:35 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 16 Jun 2021 15:38:35 GMT Subject: [jdk17] RFR: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 14:24:31 GMT, Fernando Guallini wrote: > The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is failing intermittently because the client side is expecting a SocketException only if it is wrapped into a SSLException, but it should also expect a SocketException when there is no exception chaining. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/80 From xuelei at openjdk.java.net Wed Jun 16 17:06:43 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 16 Jun 2021 17:06:43 GMT Subject: RFR: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:20:23 GMT, Rajan Halade wrote: > Test is updated to add expiry exception for "identrustdstx3 [jdk]" alias. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4500 From rhalade at openjdk.java.net Wed Jun 16 17:13:46 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 16 Jun 2021 17:13:46 GMT Subject: Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:20:23 GMT, Rajan Halade wrote: > Test is updated to add expiry exception for "identrustdstx3 [jdk]" alias. This pull request has now been integrated. Changeset: b836b83b Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/b836b83b2aefbc87b0cf26990ddbab4479c42b71 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/4500 From rhalade at openjdk.java.net Wed Jun 16 17:13:44 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 16 Jun 2021 17:13:44 GMT Subject: [jdk17] RFR: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 14:24:31 GMT, Fernando Guallini wrote: > The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is failing intermittently because the client side is expecting a SocketException only if it is wrapped into a SSLException, but it should also expect a SocketException when there is no exception chaining. Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/80 From xuelei at openjdk.java.net Wed Jun 16 17:49:52 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 16 Jun 2021 17:49:52 GMT Subject: [jdk17] RFR: 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:37:29 GMT, Valerie Peng wrote: > Could someone please help review this trivial fix? The real changes are the two PKCS11 cipher impl classes under src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of classes are just cleanups, e.g. dead code or unused code. The test/jdk/javax/crypto/Cipher/TestCipherMode.java is updated to cover more cipher impls for completeness sake. It passes without this fix, so I only add the bug id to the the other test, i.e. test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java, which verifies the PKCS#11 cipher impls. > > Thanks, > Valerie Looks good to me. Marked as reviewed by xuelei (Reviewer). src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 365: > 363: default: > 364: // should never happen; checked by Cipher.init() > 365: throw new AssertionError("Unknown mode: " + opmode); This update looks good to me. But there is a potential issues, maybe for all switch statements. If the cipher modes is extended to support more items, we may have to look for and update all the switch uses and make sure there is no broken. Anyway, for my personal understanding, there is nothing we could do right now. ------------- PR: https://git.openjdk.java.net/jdk17/pull/69 From valeriep at openjdk.java.net Wed Jun 16 18:12:55 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 16 Jun 2021 18:12:55 GMT Subject: [jdk17] RFR: 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes In-Reply-To: References: Message-ID: <5YsF7sqV35HLTIJHfKr1nwNyrCcrRRTjfxvkVcahGQo=.b841dc4e-f6e1-419f-abd0-cfbf09266016@github.com> On Wed, 16 Jun 2021 17:44:13 GMT, Xue-Lei Andrew Fan wrote: >> Could someone please help review this trivial fix? The real changes are the two PKCS11 cipher impl classes under src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of classes are just cleanups, e.g. dead code or unused code. The test/jdk/javax/crypto/Cipher/TestCipherMode.java is updated to cover more cipher impls for completeness sake. It passes without this fix, so I only add the bug id to the the other test, i.e. test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java, which verifies the PKCS#11 cipher impls. >> >> Thanks, >> Valerie > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 365: > >> 363: default: >> 364: // should never happen; checked by Cipher.init() >> 365: throw new AssertionError("Unknown mode: " + opmode); > > This update looks good to me. But there is a potential issues, maybe for all switch statements. If the cipher modes is extended to support more items, we may have to look for and update all the switch uses and make sure there is no broken. Anyway, for my personal understanding, there is nothing we could do right now. Right, if new modes are added, we need to go through all cipher impl and update the switch statements. This change is just to make sure our handling is consistent. ------------- PR: https://git.openjdk.java.net/jdk17/pull/69 From valeriep at openjdk.java.net Wed Jun 16 18:20:02 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 16 Jun 2021 18:20:02 GMT Subject: [jdk17] RFR: 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes In-Reply-To: <5YsF7sqV35HLTIJHfKr1nwNyrCcrRRTjfxvkVcahGQo=.b841dc4e-f6e1-419f-abd0-cfbf09266016@github.com> References: <5YsF7sqV35HLTIJHfKr1nwNyrCcrRRTjfxvkVcahGQo=.b841dc4e-f6e1-419f-abd0-cfbf09266016@github.com> Message-ID: On Wed, 16 Jun 2021 18:10:05 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java line 365: >> >>> 363: default: >>> 364: // should never happen; checked by Cipher.init() >>> 365: throw new AssertionError("Unknown mode: " + opmode); >> >> This update looks good to me. But there is a potential issues, maybe for all switch statements. If the cipher modes is extended to support more items, we may have to look for and update all the switch uses and make sure there is no broken. Anyway, for my personal understanding, there is nothing we could do right now. > > Right, if new modes are added, we need to go through all cipher impl and update the switch statements. This change is just to make sure our handling is consistent. Thanks much for the review~ ------------- PR: https://git.openjdk.java.net/jdk17/pull/69 From rhalade at openjdk.java.net Wed Jun 16 18:59:44 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 16 Jun 2021 18:59:44 GMT Subject: [jdk17] Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Message-ID: clean backport to JDK 17. Reviewed-by: xuelei ------------- Commit messages: - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Changes: https://git.openjdk.java.net/jdk17/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=83&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259338 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/83/head:pull/83 PR: https://git.openjdk.java.net/jdk17/pull/83 From rhalade at openjdk.java.net Wed Jun 16 18:59:47 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Wed, 16 Jun 2021 18:59:47 GMT Subject: [jdk17] Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 18:44:30 GMT, Rajan Halade wrote: > clean backport to JDK 17. > > Reviewed-by: xuelei This pull request has now been integrated. Changeset: 54f5ffea Author: Rajan Halade URL: https://git.openjdk.java.net/jdk17/commit/54f5ffeaad9da7cc77d9b6c0339758340c42ea2e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Backport-of: b836b83b2aefbc87b0cf26990ddbab4479c42b71 ------------- PR: https://git.openjdk.java.net/jdk17/pull/83 From rick.hillegas at gmail.com Wed Jun 16 23:30:08 2021 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Wed, 16 Jun 2021 16:30:08 -0700 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> Message-ID: Thanks for that advice, Alan. I have rototilled @SuppressWarnings("removal") annotations across the Derby codebase and thrown more memory at javadoc so that it won't crash on JDK 11. When I run Derby's test suites, I see a blizzard of the following diagnostics: ? WARNING: java.lang.System::setSecurityManager is deprecated and will be removed in a future release. Unfortunately, Derby still has more than 100 canon-based tests which were developed before assertion-based testing became the norm. These tests are run both with and without a security manager. In the latter case, they now fail on JDK 17. Is there a way to disable this diagnostic? Even better: Could the diagnostic be removed in the next Open JDK build? It could be re-introduced when Open JDK provides a replacement for the deprecated functionality. Right now the diagnostic does not seem to provide any actionable information. On 6/15/21 8:56 AM, Alan Bateman wrote: > On 15/06/2021 15:10, Rick Hillegas wrote: >> : >> >> When I tried to build Derby with the Rampdown Phase One build of open >> JDK 17 (17-ea+26-2439), I saw many warnings related to the >> deprecation of Security Manager classes and methods, undoubtedly the >> consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, >> like Tomcat, embraced the Security Manager early on. Permissions >> checks were rototilled across the whole code base and our >> distributions ship with several template policy files, which we >> encourage users to customize for their environments. The "Configuring >> Java Security" section of our Security Guide explains how to do this >> (https://db.apache.org/derby/docs/10.15/security/index.html). >> >> My build only reported the first 100 warnings. It is likely that >> there are many more. > > Yes, JEP 411 deprecates a number of APIs for future removal. There > probably isn't much to do right now except to be aware that the APIs > are earmarked for removal in some future release. I've no doubt there > will be another JEP when that time comes. I assume you know about > @SuppressWarnings("removal"), which you can use to suppress the > warnings for now. The JDK usages of these APIs are using > SuppressWarnings as the JDK is compiled with -Xlint set to made > warnings fatal. > > -Alan From dholmes at openjdk.java.net Thu Jun 17 01:54:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Jun 2021 01:54:09 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. I skimmed through all these and the changes seem fine in principal. I have two mild concerns: 1. How does this change the class initialization order on VM startup? 2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Thu Jun 17 03:35:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 17 Jun 2021 03:35:13 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> Message-ID: <4yPb1iqPV0JAYphfov1jMn-bLr8NjA3e3EJDi6_Qg-E=.39756447-7617-4e72-aeaa-e0dd5ad0b64c@github.com> On Thu, 17 Jun 2021 01:51:41 GMT, David Holmes wrote: > I skimmed through all these and the changes seem fine in principal. > I have two mild concerns: > > 1. How does this change the class initialization order on VM startup? > 2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException? > > Thanks, > David Hi David, your concerns are reasonable. I think this change would not affect the class initialization order, because regardless of whether the patch is applied or not, `java -Xlog:class+load -version` prints identical class initialization order(for j.l.Objects and jdk.internal.util.Preconditions) as far as I can see. [class_load.log](https://github.com/openjdk/jdk/files/6667168/class_load.log). And tier1 tests are all passed w/o any modifications. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From dongbohe at openjdk.java.net Thu Jun 17 03:54:54 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Thu, 17 Jun 2021 03:54:54 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v2] In-Reply-To: References: Message-ID: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op > > Benchmark results after patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op > > SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > > Testing: tier1, tier2 Dongbo He has updated the pull request incrementally with one additional commit since the last revision: Make getAlgorithms() method return a Set ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4424/files - new: https://git.openjdk.java.net/jdk/pull/4424/files/84706053..dde672f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=00-01 Stats: 45 lines in 3 files changed: 3 ins; 23 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424 PR: https://git.openjdk.java.net/jdk/pull/4424 From xuelei at openjdk.java.net Thu Jun 17 04:47:10 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 17 Jun 2021 04:47:10 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 03:54:54 GMT, Dongbo He wrote: >> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. >> >> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. >> Baseline results before patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op >> >> Benchmark results after patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op >> >> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. >> >> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: >> Before patch: >> >> summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> After patch: >> >> summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> >> Testing: tier1, tier2 > > Dongbo He has updated the pull request incrementally with one additional commit since the last revision: > > Make getAlgorithms() method return a Set src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 72: > 70: algorithmsInProperty = property.split(","); > 71: for (int i = 0; i < algorithmsInProperty.length; i++) { > 72: algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(Locale.ENGLISH); Is it possible to keep the current behavior that the property could be sensitive? It may be not desired to allow "keysize" for "keySize" spec in the property. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From peter.firmstone at zeus.net.au Thu Jun 17 05:04:51 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 17 Jun 2021 15:04:51 +1000 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: <4b60bae9-684a-2b8b-628c-ebd2d2a8656f@gmail.com> References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> <4b60bae9-684a-2b8b-628c-ebd2d2a8656f@gmail.com> Message-ID: <9db00abc-8181-1f01-88ff-117f43c9835e@zeus.net.au> Hi Rick This is dependant on OpenJDK creating hooks in JVM code for existing permission's without depending existing Security infrastructure. The major components can be found here, also available on Maven: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/SecurityContext.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java Regards, Peter. On 17/06/2021 1:00 am, Rick Hillegas wrote: > Thanks, Peter. Derby supports a couple authorization mechanisms, the > most important one being the role-based SQL Standard GRANT/REVOKE > commands (see > https://db.apache.org/derby/docs/10.15/security/csecauthorization.html). > I'm afraid that my old eyes didn't see a link to your authorization > libraries in your message. > > On 6/15/21 5:23 PM, Peter Firmstone wrote: >> Rick, >> >> Out of curiosity, does Apache Derby have a need for an Authorization >> layer? >> >> We have tooling to generate our policy files, which simplifies the >> process a lot, we also have highly scalable and performant >> SecurityManager and Policy implementations which are compatible with >> standard Java policy files. >> >> This is available under an AL2.0 license. >> >> I'm hoping that OpenJDK will create some hooks for permission checks, >> so that we can continue to provide an authorization layer for Java, >> following JEP 411. >> >> I'll be using StackWalker to reproduce AccessController's stack >> walk.?? We also have existing classes which wrap >> AccessControlContext, so we would use ThreadLocal's to preserve subject. >> > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From dholmes at openjdk.java.net Thu Jun 17 05:19:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Jun 2021 05:19:11 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Class loading order is different to class initialization order. There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From dongbohe at openjdk.java.net Thu Jun 17 08:16:42 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Thu, 17 Jun 2021 08:16:42 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v3] In-Reply-To: References: Message-ID: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op > > Benchmark results after patch: > > Benchmark (algorithm) Mode Cnt Score Error Units > AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op > AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op > AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op > > SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > > Testing: tier1, tier2 Dongbo He has updated the pull request incrementally with one additional commit since the last revision: Replace HashSet with TreeSet ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4424/files - new: https://git.openjdk.java.net/jdk/pull/4424/files/dde672f6..0253fdb2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=01-02 Stats: 17 lines in 2 files changed: 2 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424 PR: https://git.openjdk.java.net/jdk/pull/4424 From github.com+10835776+stsypanov at openjdk.java.net Thu Jun 17 08:20:15 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Jun 2021 08:20:15 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> References: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> Message-ID: On Wed, 16 Jun 2021 09:49:17 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: >> >>> 152: while (tokenizer.hasMoreTokens()) >>> 153: v.add(tokenizer.nextToken()); >>> 154: ciphers = new String [v.size()]; >> >> Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` > > It's not a drop-in replacement. Result is different for some Strings. For example for `, A` > I would prefer to preserve existing behavior under this cleanup. Then let's keep it as is ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From alanb at openjdk.java.net Thu Jun 17 10:28:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 10:28:15 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. I looked through the changes in java.base and only spotted one case where a different (and more specific) exception is thrown. The changes to to files in java.util.zip lead to annoying long lines so would be good to fix all those. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471: > 469: */ > 470: public int offsetByCodePoints(int index, int codePointOffset) { > 471: checkOffset(index, count); String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the further because code. I only mention is because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result. src/java.base/share/classes/java/util/Base64.java line 934: > 932: if (closed) > 933: throw new IOException("Stream is closed"); > 934: Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException()); You might to split this really long line to avoid inconsistent line length in this source file. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From alanb at openjdk.java.net Thu Jun 17 10:50:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 10:50:13 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception). ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From Alan.Bateman at oracle.com Thu Jun 17 11:56:35 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jun 2021 12:56:35 +0100 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> Message-ID: <4056512e-7983-ff25-fcd0-8f9fe5564291@oracle.com> On 17/06/2021 00:30, Rick Hillegas wrote: > Thanks for that advice, Alan. I have rototilled > @SuppressWarnings("removal") annotations across the Derby codebase and > thrown more memory at javadoc so that it won't crash on JDK 11. When I > run Derby's test suites, I see a blizzard of the following diagnostics: > > ? WARNING: java.lang.System::setSecurityManager is deprecated and will > be removed in a future release. > > Unfortunately, Derby still has more than 100 canon-based tests which > were developed before assertion-based testing became the norm. These > tests are run both with and without a security manager. In the latter > case, they now fail on JDK 17. > > Is there a way to disable this diagnostic? > > Even better: Could the diagnostic be removed in the next Open JDK > build? It could be re-introduced when Open JDK provides a replacement > for the deprecated functionality. Right now the diagnostic does not > seem to provide any actionable information. > I assume the OOME with javadoc isn't anything to do with this JEP or the @SupressWarnings annotations, right? There isn't any way to suppress the warning. This warning is sending a clear message that that setSecurityManager will be removed in the future. The "Illegal reflective access" warnings in JDK 9-15 set the precedent. For applications that do set a security manager then it is more likely that they set it once, at startup, rather than setting it hundreds of times in a running VM. Does Derby call setSecurityManager itself? At least in the embedded case then I wouldn't expect it does as it will be up to the application to do that if it wants. Clearly Derby has tests to ensure that it can work with a SM so I assume its the tests that are calling setSecurityManager. I'm not familar with the term "canon-based tests" but I'm guessing that these are tests that run with and without SM and are somehow sensitive to the stderr stream, is that right? There were a small number of these in the JDK test suite too, but not many. -Alan From dongbohe at openjdk.java.net Thu Jun 17 12:08:13 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Thu, 17 Jun 2021 12:08:13 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 04:43:27 GMT, Xue-Lei Andrew Fan wrote: >> Dongbo He has updated the pull request incrementally with one additional commit since the last revision: >> >> Make getAlgorithms() method return a Set > > src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 72: > >> 70: algorithmsInProperty = property.split(","); >> 71: for (int i = 0; i < algorithmsInProperty.length; i++) { >> 72: algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(Locale.ENGLISH); > > Is it possible to keep the current behavior that the property could be sensitive? It may be not desired to allow "keysize" for "keySize" spec in the property. If we keep property sensitive, we may need to use TreeSet. I have updated the PR with TreeSet. Fortunately, the performance hasn't changed much. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From dongbohe at openjdk.java.net Thu Jun 17 12:14:12 2021 From: dongbohe at openjdk.java.net (Dongbo He) Date: Thu, 17 Jun 2021 12:14:12 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 08:16:42 GMT, Dongbo He wrote: >> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search. >> >> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`. >> Baseline results before patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 21.687 ? 1.118 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 324.216 ? 6.233 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 709.462 ? 51.259 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 687.497 ? 170.181 ns/op >> >> Benchmark results after patch: >> >> Benchmark (algorithm) Mode Cnt Score Error Units >> AlgorithmConstraintsPermits.permits SSLv3 avgt 5 46.407 ? 1.057 ns/op >> AlgorithmConstraintsPermits.permits DES avgt 5 65.722 ? 0.578 ns/op >> AlgorithmConstraintsPermits.permits NULL avgt 5 43.988 ? 1.264 ns/op >> AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 399.546 ? 11.194 ns/op >> >> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. >> >> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: >> Before patch: >> >> summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min: 16 Max: 1281 Err: 0 (0.00%) >> summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> After patch: >> >> summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min: 26 Max: 697 Err: 0 (0.00%) >> summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 >> >> >> Testing: tier1, tier2 > > Dongbo He has updated the pull request incrementally with one additional commit since the last revision: > > Replace HashSet with TreeSet The following is the Benchmark results for the new commit: JMH: Benchmark (algorithm) Mode Cnt Score Error Units AlgorithmConstraintsPermits.permits SSLv3 avgt 5 47.353 ? 3.193 ns/op AlgorithmConstraintsPermits.permits DES avgt 5 60.307 ? 1.351 ns/op AlgorithmConstraintsPermits.permits NULL avgt 5 59.065 ? 0.728 ns/op AlgorithmConstraintsPermits.permits TLS1.3 avgt 5 428.311 ? 16.542 ns/op Tomcat+Jmeter: summary + 60455 in 00:00:30 = 2016.4/s Avg: 198 Min: 164 Max: 256 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 106982 in 00:00:55 = 1927.6/s Avg: 188 Min: 25 Max: 1194 Err: 0 (0.00%) summary + 60430 in 00:00:30 = 2014.6/s Avg: 198 Min: 160 Max: 252 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 167412 in 00:01:25 = 1958.1/s Avg: 191 Min: 25 Max: 1194 Err: 0 (0.00%) summary + 60480 in 00:00:30 = 2014.6/s Avg: 198 Min: 161 Max: 245 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 summary = 227892 in 00:01:56 = 1972.8/s Avg: 193 Min: 25 Max: 1194 Err: 0 (0.00%) summary + 60506 in 00:00:30 = 2016.6/s Avg: 198 Min: 161 Max: 255 Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0 ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From david.holmes at oracle.com Thu Jun 17 12:25:07 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jun 2021 22:25:07 +1000 Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <59f05d6a-66a7-129c-4897-e45b4dd564ab@oracle.com> On 17/06/2021 8:50 pm, Alan Bateman wrote: > On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: > >> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. > > It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception). tiers 1-3 on Linux-x64 passed okay. Any change to the exact type of exception thrown should be affirmed through a CSR request. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4507 > From abakhtin at openjdk.java.net Thu Jun 17 13:28:27 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 17 Jun 2021 13:28:27 GMT Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket to SSL server Message-ID: Please review the fix for JDK-8268965. The new jtreg test is added for the described issue. sun/security/ssl and javax/net/ssl tests are passed ------------- Commit messages: - 8268965: TCP Connection Reset when connecting simple socket to SSL server Changes: https://git.openjdk.java.net/jdk/pull/4520/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4520&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268965 Stats: 114 lines in 2 files changed: 114 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4520.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4520/head:pull/4520 PR: https://git.openjdk.java.net/jdk/pull/4520 From mullan at openjdk.java.net Thu Jun 17 14:08:40 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 17 Jun 2021 14:08:40 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v3] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 22:34:03 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new warning text again (6/14) test/jdk/java/lang/System/SecurityManagerWarnings.java line 38: > 36: import java.security.Permission; > 37: > 38: public class SecurityManagerWarnings { This should probably have 8268349 in the @bug line. test/jdk/java/security/ProtectionDomain/RecursionDebug.java line 91: > 89: } > 90: > 91: System.setSecurityManager(null); Why did this line need to be removed? ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 14:17:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 14:17:33 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:02:35 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> new warning text again (6/14) > > test/jdk/java/lang/System/SecurityManagerWarnings.java line 38: > >> 36: import java.security.Permission; >> 37: >> 38: public class SecurityManagerWarnings { > > This should probably have 8268349 in the @bug line. OK. ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 14:30:28 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 14:30:28 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:05:40 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> new warning text again (6/14) > > test/jdk/java/security/ProtectionDomain/RecursionDebug.java line 91: > >> 89: } >> 90: >> 91: System.setSecurityManager(null); > > Why did this line need to be removed? This is where the `setSecurityManager` method is called again when a security manager has already been installed, and the `getProtectionDomain` permission is needed. While I can add the new permission into the policy file, my understanding is that this line was just a clean-up and the test was about implementation of `ProtectionDomain::toString` (esp the `seeAllp` method called by it) when debug is on. ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 14:55:02 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 14:55:02 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: References: Message-ID: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: add bug id into a test ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/13/files - new: https://git.openjdk.java.net/jdk17/pull/13/files/cb732f99..2d5b1ba5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13 From mullan at openjdk.java.net Thu Jun 17 15:02:38 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 17 Jun 2021 15:02:38 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:55:02 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > add bug id into a test Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From mullan at openjdk.java.net Thu Jun 17 15:02:39 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 17 Jun 2021 15:02:39 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 14:27:30 GMT, Weijun Wang wrote: >> test/jdk/java/security/ProtectionDomain/RecursionDebug.java line 91: >> >>> 89: } >>> 90: >>> 91: System.setSecurityManager(null); >> >> Why did this line need to be removed? > > This is where the `setSecurityManager` method is called again when a security manager has already been installed, and the `getProtectionDomain` permission is needed. While I can add the new permission into the policy file, my understanding is that this line was just a clean-up and the test was about implementation of `ProtectionDomain::toString` (esp the `seeAllp` method called by it) when debug is on. Ok, thanks for the explanation. I think it should be ok to remove this line then. ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From rick.hillegas at gmail.com Thu Jun 17 15:28:50 2021 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Thu, 17 Jun 2021 08:28:50 -0700 Subject: blizzard of deprecation warnings related to JEP 411 In-Reply-To: <4056512e-7983-ff25-fcd0-8f9fe5564291@oracle.com> References: <81037ee4-8d23-3b12-8af9-fb3a07dd11ec@oracle.com> <4056512e-7983-ff25-fcd0-8f9fe5564291@oracle.com> Message-ID: On 6/17/21 4:56 AM, Alan Bateman wrote: > On 17/06/2021 00:30, Rick Hillegas wrote: >> Thanks for that advice, Alan. I have rototilled >> @SuppressWarnings("removal") annotations across the Derby codebase >> and thrown more memory at javadoc so that it won't crash on JDK 11. >> When I run Derby's test suites, I see a blizzard of the following >> diagnostics: >> >> ? WARNING: java.lang.System::setSecurityManager is deprecated and >> will be removed in a future release. >> >> Unfortunately, Derby still has more than 100 canon-based tests which >> were developed before assertion-based testing became the norm. These >> tests are run both with and without a security manager. In the latter >> case, they now fail on JDK 17. >> >> Is there a way to disable this diagnostic? >> >> Even better: Could the diagnostic be removed in the next Open JDK >> build? It could be re-introduced when Open JDK provides a replacement >> for the deprecated functionality. Right now the diagnostic does not >> seem to provide any actionable information. >> > I assume the OOME with javadoc isn't anything to do with this JEP or > the @SupressWarnings annotations, right? I stopped investigating the problem after I found that I could work around it by giving javadoc more memory. All I can report is the following: 1) The extra annotations caused the JDK 11 javadoc tool to run out of memory. 2) The extra annotations did NOT cause the JDK 17 javadoc tool to run out of memory. > > There isn't any way to suppress the warning. This warning is sending a > clear message that that setSecurityManager will be removed in the > future. The "Illegal reflective access" warnings in JDK 9-15 set the > precedent. > > For applications that do set a security manager then it is more likely > that they set it once, at startup, rather than setting it hundreds of > times in a running VM. Does Derby call setSecurityManager itself? The Derby network server installs a security manager if the DBA doesn't. With some effort, users can override this behavior. This behavior dates back to 2007 and was introduced by Derby release 10.3.1.4. At that time, developers from IBM and Sun Microsystems (the major players in the Derby community) agreed that the client-server configuration should be "secure by default." > At least in the embedded case then I wouldn't expect it does as it > will be up to the application to do that if it wants. Clearly Derby > has tests to ensure that it can work with a SM so I assume its the > tests that are calling setSecurityManager. I'm not familar with the > term "canon-based tests" but I'm guessing that these are tests that > run with and without SM and are somehow sensitive to the stderr > stream, is that right? Canon-based testing is an old black-box testing pattern in which you do the following: 1) Run a test script through a Read-Evaluate-Print-Loop tool. 2) Collect the console output (stdout + stderr). 3) Compare the actual output to a file of expected output (the canon). > There were a small number of these in the JDK test suite too, but not > many. > > -Alan From psandoz at openjdk.java.net Thu Jun 17 15:48:32 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 17 Jun 2021 15:48:32 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com> On Thu, 17 Jun 2021 10:21:35 GMT, Alan Bateman wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > src/java.base/share/classes/java/util/Base64.java line 934: > >> 932: if (closed) >> 933: throw new IOException("Stream is closed"); >> 934: Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException()); > > You might want to split this really long line too, to avoid inconsistent line length in this source file. I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message). See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps). ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From xuelei at openjdk.java.net Thu Jun 17 16:03:26 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 17 Jun 2021 16:03:26 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 12:05:28 GMT, Dongbo He wrote: >> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 72: >> >>> 70: algorithmsInProperty = property.split(","); >>> 71: for (int i = 0; i < algorithmsInProperty.length; i++) { >>> 72: algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(Locale.ENGLISH); >> >> Is it possible to keep the current behavior that the property could be sensitive? It may be not desired to allow "keysize" for "keySize" spec in the property. > > If we keep property sensitive, we may need to use TreeSet. I have updated the PR with TreeSet. Fortunately, the performance hasn't changed much. I did not get the point to use TreeSet. Is it sufficient if the toLowerCase() is not added (and don't compare keywords like "keySize" by ignoring cases)? - algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(...); + algorithmsInProperty[i] = algorithmsInProperty[i].trim(); ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From xuelei at openjdk.java.net Thu Jun 17 16:11:29 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 17 Jun 2021 16:11:29 GMT Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 15:59:45 GMT, Xue-Lei Andrew Fan wrote: >> If we keep property sensitive, we may need to use TreeSet. I have updated the PR with TreeSet. Fortunately, the performance hasn't changed much. > > I did not get the point to use TreeSet. Is it sufficient if the toLowerCase() is not added (and don't compare keywords like "keySize" by ignoring cases)? > > > - algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(...); > + algorithmsInProperty[i] = algorithmsInProperty[i].trim(); Sorry, I missed a "case" in the original comment (corrected). I meant to keep the property case sensitive in the hash set so that the keywords like "keySize" could be used correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/4424 From github.com+34924738+mahendrachhipa at openjdk.java.net Thu Jun 17 16:23:08 2021 From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa) Date: Thu, 17 Jun 2021 16:23:08 GMT Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v4] In-Reply-To: References: Message-ID: > ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4432/files - new: https://git.openjdk.java.net/jdk/pull/4432/files/db615030..295c2a56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4432/head:pull/4432 PR: https://git.openjdk.java.net/jdk/pull/4432 From fguallini at openjdk.java.net Thu Jun 17 16:28:29 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Thu, 17 Jun 2021 16:28:29 GMT Subject: [jdk17] Integrated: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 14:24:31 GMT, Fernando Guallini wrote: > The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is failing intermittently because the client side is expecting a SocketException only if it is wrapped into a SSLException, but it should also expect a SocketException when there is no exception chaining. This pull request has now been integrated. Changeset: 2047da7d Author: Fernando Guallini Committer: Rajan Halade URL: https://git.openjdk.java.net/jdk17/commit/2047da7dccacb1adb7f811639a58b8fbe1aa3546 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset" Reviewed-by: xuelei, rhalade ------------- PR: https://git.openjdk.java.net/jdk17/pull/80 From alanb at openjdk.java.net Thu Jun 17 16:31:32 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 16:31:32 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: References: Message-ID: <5zkVDCUuhsGl276IA7G2oYpVoGSgtT8LILABdoyy3GA=.714847a5-50e7-48ec-a638-38238155b511@github.com> On Thu, 17 Jun 2021 14:55:02 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > add bug id into a test Implementation changes/text is okay. src/java.base/share/classes/java/lang/System.java line 330: > 328: > 329: // Remember original System.err. setSecurityManager() warning goes here > 330: private static volatile @Stable PrintStream originalErrStream = null; I'd probably use "initial" rather than "original" here but okay. You can drop setting it to null as that is its default value. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 17:14:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 17:14:27 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: <5zkVDCUuhsGl276IA7G2oYpVoGSgtT8LILABdoyy3GA=.714847a5-50e7-48ec-a638-38238155b511@github.com> References: <5zkVDCUuhsGl276IA7G2oYpVoGSgtT8LILABdoyy3GA=.714847a5-50e7-48ec-a638-38238155b511@github.com> Message-ID: <4t3llV6B2uosrtBWWCHEPdHxWl-LkbSlli3ZLBgw5r0=.c346b011-b389-478f-9851-4339a8a748c8@github.com> On Thu, 17 Jun 2021 16:27:41 GMT, Alan Bateman wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> add bug id into a test > > src/java.base/share/classes/java/lang/System.java line 330: > >> 328: >> 329: // Remember original System.err. setSecurityManager() warning goes here >> 330: private static volatile @Stable PrintStream originalErrStream = null; > > I'd probably use "initial" rather than "original" here but okay. You can drop setting it to null as that is its default value. Will do. Thanks. ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 17:21:04 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 17:21:04 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v5] In-Reply-To: References: Message-ID: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: verbose warning message test and renaming in System.java ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/13/files - new: https://git.openjdk.java.net/jdk17/pull/13/files/2d5b1ba5..1e1e7221 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=03-04 Stats: 111 lines in 2 files changed: 51 ins; 30 del; 30 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13 From weijun at openjdk.java.net Thu Jun 17 17:21:07 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Jun 2021 17:21:07 GMT Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about Security Manager deprecation [v4] In-Reply-To: References: Message-ID: <9bOM4lnzvbEJqEJOeNaSKFdKI5JW5sXWhjQuo9TKlTo=.6b3302f7-c181-4edd-8e17-cafb8c89f7c3@github.com> On Thu, 17 Jun 2021 14:55:02 GMT, Weijun Wang wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. >> >> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > add bug id into a test A new commit. Much more exact checking of various warning messages. ------------- PR: https://git.openjdk.java.net/jdk17/pull/13 From rhalade at openjdk.java.net Thu Jun 17 23:17:47 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 17 Jun 2021 23:17:47 GMT Subject: RFR: 8268678: LetsEncryptCA.java test fails as =?UTF-8?B?TGV04oCZcw==?= Encrypt Authority X3 is retired Message-ID: See the bug for more details. - Intermediate root cert R3 doesn't specify OCSP responder and end entity test certificates doesn't specify CRLs - New test artifacts are available but revoked expires on July 7th, 2021 and valid on August 31st, 2021. so backdated validity check is performed for OCSP. If this fix is not acceptable for now then we can wait till CA updates test sites. ------------- Commit messages: - 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired Changes: https://git.openjdk.java.net/jdk/pull/4524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268678 Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/4524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4524/head:pull/4524 PR: https://git.openjdk.java.net/jdk/pull/4524 From valeriep at openjdk.java.net Thu Jun 17 23:31:30 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 17 Jun 2021 23:31:30 GMT Subject: [jdk17] Integrated: 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 22:37:29 GMT, Valerie Peng wrote: > Could someone please help review this trivial fix? The real changes are the two PKCS11 cipher impl classes under src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/. The rest of classes are just cleanups, e.g. dead code or unused code. The test/jdk/javax/crypto/Cipher/TestCipherMode.java is updated to cover more cipher impls for completeness sake. It passes without this fix, so I only add the bug id to the the other test, i.e. test/jdk/sun/security/pkcs11/Cipher/TestCipherMode.java, which verifies the PKCS#11 cipher impls. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 80dc262e Author: Valerie Peng URL: https://git.openjdk.java.net/jdk17/commit/80dc262e8132204d70b184b32978e6c456460fb0 Stats: 308 lines in 8 files changed: 254 ins; 5 del; 49 mod 8265500: Some impls of javax.crypto.Cipher.init() do not throw UnsupportedOperationExc for unsupported modes Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk17/pull/69 From jwilhelm at openjdk.java.net Thu Jun 17 23:34:36 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Jun 2021 23:34:36 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed - 8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy - 8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 - 8264843: Javac crashes with NullPointerException when finding unencoded XML in 

 tag
 - 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"
 - 8268353: Test libsvml.so is and is not present in jdk image
 - 8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
 - 8268776: Test `ADatagramSocket.java` missing /othervm from @run tag
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/bb24fa65...a3951c44

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4525/files
  Stats: 845 lines in 26 files changed: 408 ins; 384 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4525/head:pull/4525

PR: https://git.openjdk.java.net/jdk/pull/4525

From xuelei at openjdk.java.net  Fri Jun 18 00:37:25 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Jun 2021 00:37:25 GMT
Subject: RFR: 8268678: LetsEncryptCA.java test fails as
 =?UTF-8?B?TGV04oCZcw==?= Encrypt Authority X3 is retired
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 23:10:58 GMT, Rajan Halade  wrote:

> See the bug for more details.
> 
> - Intermediate root cert R3 doesn't specify OCSP responder and end entity test certificates doesn't specify CRLs
> - New test artifacts are available but revoked expires on July 7th, 2021 and valid on August 31st, 2021. so backdated validity check is performed for OCSP.
> 
> If this fix is not acceptable for now then we can wait till CA updates test sites.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4524

From rhalade at openjdk.java.net  Fri Jun 18 00:53:28 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 18 Jun 2021 00:53:28 GMT
Subject: Integrated: 8268678: LetsEncryptCA.java test fails as
 =?UTF-8?B?TGV04oCZcw==?= Encrypt Authority X3 is retired
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 23:10:58 GMT, Rajan Halade  wrote:

> See the bug for more details.
> 
> - Intermediate root cert R3 doesn't specify OCSP responder and end entity test certificates doesn't specify CRLs
> - New test artifacts are available but revoked expires on July 7th, 2021 and valid on August 31st, 2021. so backdated validity check is performed for OCSP.
> 
> If this fix is not acceptable for now then we can wait till CA updates test sites.

This pull request has now been integrated.

Changeset: 58e6e6d9
Author:    Rajan Halade 
URL:       https://git.openjdk.java.net/jdk/commit/58e6e6d919cb15559a61a67805da263be3c9d693
Stats:     125 lines in 1 file changed: 11 ins; 9 del; 105 mod

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4524

From jwilhelm at openjdk.java.net  Fri Jun 18 00:56:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 00:56:32 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 23:26:26 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a051e735
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c
Stats:     845 lines in 26 files changed: 408 ins; 384 del; 53 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4525

From rhalade at openjdk.java.net  Fri Jun 18 01:03:47 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 18 Jun 2021 01:03:47 GMT
Subject: [jdk17] Integrated: 8268678: LetsEncryptCA.java test fails as
 =?UTF-8?B?TGV04oCZcw==?= Encrypt Authority X3 is retired
Message-ID: 

clean backport to JDK 17

Reviewed-by: xuelei

-------------

Commit messages:
 - 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Changes: https://git.openjdk.java.net/jdk17/pull/94/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=94&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268678
  Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/94.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/94/head:pull/94

PR: https://git.openjdk.java.net/jdk17/pull/94

From rhalade at openjdk.java.net  Fri Jun 18 01:03:48 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Fri, 18 Jun 2021 01:03:48 GMT
Subject: [jdk17] Integrated: 8268678: LetsEncryptCA.java test fails as
 =?UTF-8?B?TGV04oCZcw==?= Encrypt Authority X3 is retired
In-Reply-To: 
References: 
Message-ID: <_453s2QTJGAUSYcfO6_1Tdd_GQEKNsWKeiVroBQwJc8=.09104b73-cb6c-4cf8-837d-8672c51e17d9@github.com>

On Fri, 18 Jun 2021 00:54:43 GMT, Rajan Halade  wrote:

> clean backport to JDK 17
> 
> Reviewed-by: xuelei

This pull request has now been integrated.

Changeset: 483f1ee2
Author:    Rajan Halade 
URL:       https://git.openjdk.java.net/jdk17/commit/483f1ee211bc0e37b486eb9d38d283ff02f0bdcc
Stats:     125 lines in 1 file changed: 11 ins; 9 del; 105 mod

8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired

Backport-of: 58e6e6d919cb15559a61a67805da263be3c9d693

-------------

PR: https://git.openjdk.java.net/jdk17/pull/94

From dongbohe at openjdk.java.net  Fri Jun 18 01:57:31 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 18 Jun 2021 01:57:31 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 17 Jun 2021 16:08:15 GMT, Xue-Lei Andrew Fan  wrote:

>> I did not get the point to use TreeSet.  Is it sufficient if the toLowerCase() is not added (and don't compare keywords like "keySize" by ignoring cases)?
>> 
>> 
>> - algorithmsInProperty[i] = algorithmsInProperty[i].trim().toLowerCase(...);
>> + algorithmsInProperty[i] = algorithmsInProperty[i].trim();
>
> Sorry, I missed a "case" in the original comment (corrected).  I meant to keep the property case sensitive in the hash set so that the keywords like "keySize" could be used correctly.

[checkAlgorithm](https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java#L94) check whether the item is in the collection by ignoring case. If the item in the HashSet is case-sensitive, the method will lose its original algorithmic logic, but will retain it by using a ` new TreeSet<>(String.CASE_INSENSITIVE_ORDER);`

Can we use case sensitivity in checkAlgorithm to check an algorithm?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From jpai at openjdk.java.net  Fri Jun 18 02:33:28 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 18 Jun 2021 02:33:28 GMT
Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about
 Security Manager deprecation [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 17:21:04 GMT, Weijun Wang  wrote:

>> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.
>> 
>> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   verbose warning message test and renaming in System.java

src/java.base/share/classes/java/lang/System.java line 381:

> 379:         if (allowSecurityManager()) {
> 380:             var caller = Reflection.getCallerClass();
> 381:             String signature = caller.getName() + " (" + codeSource(caller) + ")";

Hello Weijun,

Given that the `codeSource()` method above is allowed to return `null`, there could be a case where the warning message printed would be something like:

> 
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by foo.bar.Hello (null)
> WARNING: Please consider reporting this to the maintainers of foo.bar.Hello
> WARNING: System::setSecurityManager will be removed in a future release
> 

Would that be OK or do you think the presence of "(null)" be unnecessary and confusing? Maybe in such cases that line should just say "System::setSecurityManager has been called by foo.bar.Hello"?

Another minor nit - the variable is named `signature` which initially gave me an impression that it was the method signature of the caller code, but that isn't the case. Should this variable be renamed perhaps?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/13

From jpai at openjdk.java.net  Fri Jun 18 02:51:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 18 Jun 2021 02:51:29 GMT
Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about
 Security Manager deprecation [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 17:21:04 GMT, Weijun Wang  wrote:

>> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.
>> 
>> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   verbose warning message test and renaming in System.java

Hello Sean, Weijung,

>From what I have known, the Java/JDK code has always taken extra precaution when it comes to printing out potentially sensitive details like IP addresses and paths to file, like jar files in the log messages or exception stacktraces. In fact, one of the annoying things about some of the error messages that the JarFile API throws is that it doesn't even print out the jar file name, let alone the full path of the jar file which ran into issues. At least that was the case, unless that has changed in recent times. Furthermore, as you will surely know, to print out these details there's an security property which needs to be explicitly enabled ("jdk.includeInExceptions") with the right values.

Given all that, do you think that we should be printing the jar file paths in this WARNING message by default? I read the linked CSR, but I didn't see why the location of the jar or the name of the jar would be useful in this warning message. As long as the caller class (and perhaps the caller method) is printed, I think that should be enough of a summary on what's triggering this warning.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/13

From peter.firmstone at zeus.net.au  Fri Jun 18 03:18:02 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 18 Jun 2021 13:18:02 +1000
Subject: JEP 411: Deprecation with removal would break most existing Java
 libraries
In-Reply-To: 
References: 
 <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com>
 <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au>
 
 
 
Message-ID: 


On 16/06/2021 11:18 pm, David Lloyd wrote:
> On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
>  wrote:
>
>> Permission references can be replaced with Guard references (which
>> Permissions are instances of).
> I guess you've got something fairly complex in mind, could you give
> some practical examples of how this would work?


The same service provider mechanism encryption uses.? So implementation 
may utilize authorization access check points without any dependencies 
on current SecurityManager, Policy or Permission API's.

It's completely up to the implementation to determine how to manage.


>
>> The Permission implementations of Guard::check call SecurityManager, so
>> checks will continue working as expected, but it allows us to intercept
>> them and do something different.
> What do you envision these checks looking like?  Where would the JDK
> find these Guard instances?


GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
"connect,accept");

// Permission check

localHostConnectAccept.check();



GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);

// Permission check

createClassLoader.check();

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


From peter.firmstone at zeus.net.au  Fri Jun 18 03:24:54 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 18 Jun 2021 13:24:54 +1000
Subject: JEP 411: Deprecation with removal would break most existing Java
 libraries
In-Reply-To: 
References: 
 <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com>
 <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au>
 
 
 
 
Message-ID: <3f675f18-b95b-ff7c-7a04-dfdceb569aca@zeus.net.au>


On 18/06/2021 1:18 pm, Peter Firmstone wrote:
>
> On 16/06/2021 11:18 pm, David Lloyd wrote:
>> On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
>>  wrote:
>>
>>> Permission references can be replaced with Guard references (which
>>> Permissions are instances of).
>> I guess you've got something fairly complex in mind, could you give
>> some practical examples of how this would work?
>
>
> The same service provider mechanism encryption uses.? So 
> implementation may utilize authorization access check points without 
> any dependencies on current SecurityManager, Policy or Permission API's.


Eg GuardFactorySpi


>
> It's completely up to the implementation to determine how to manage.
>
>
>>
>>> The Permission implementations of Guard::check call SecurityManager, so
>>> checks will continue working as expected, but it allows us to intercept
>>> them and do something different.
>> What do you envision these checks looking like?? Where would the JDK
>> find these Guard instances?
>
>
> GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");
>
> Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
> "connect,accept");
>
> // Permission check
>
> localHostConnectAccept.check();
>
>
>
> GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");
>
> Guard createClassLoader = 
> runtimeGuardFactory.orders("createClassLoader", null);
>
> // Permission check
>
> createClassLoader.check();
>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


From xuelei at openjdk.java.net  Fri Jun 18 04:17:24 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Jun 2021 04:17:24 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 01:54:30 GMT, Dongbo He  wrote:

>> Sorry, I missed a "case" in the original comment (corrected).  I meant to keep the property case sensitive in the hash set so that the keywords like "keySize" could be used correctly.
>
> [checkAlgorithm](https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java#L94) check whether the item is in the collection by ignoring case. If the item in the HashSet is case-sensitive, the method will lose its original algorithmic logic, but will retain it by using a ` new TreeSet<>(String.CASE_INSENSITIVE_ORDER);`
> 
> Can we use case sensitivity in checkAlgorithm to check an algorithm?

The checkAlgorithm is using equalsIgnoreCase(), so it is safe for it.  My concern is mainly about the keywords, like "keySize" used the property, not really the algorithm name.  It is good to keep the current case sensitive checking behavior unchanged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From dongbohe at openjdk.java.net  Fri Jun 18 04:59:26 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 18 Jun 2021 04:59:26 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 04:14:09 GMT, Xue-Lei Andrew Fan  wrote:

>> [checkAlgorithm](https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java#L94) check whether the item is in the collection by ignoring case. If the item in the HashSet is case-sensitive, the method will lose its original algorithmic logic, but will retain it by using a ` new TreeSet<>(String.CASE_INSENSITIVE_ORDER);`
>> 
>> Can we use case sensitivity in checkAlgorithm to check an algorithm?
>
> The checkAlgorithm is using equalsIgnoreCase(), so it is safe for it.  My concern is mainly about the keywords, like "keySize" used the property, not really the algorithm name.  It is good to keep the current case sensitive checking behavior unchanged.

Hi, Xuelei, thank you for your comments. I may not express it clearly, let me clarify. My concern is that if we use the HashSet:contains method to check whether an item is in the hash set, we cannot use equalsIgnoreCase(), so I used `new TreeSet<>(String.CASE_INSENSITIVE_ORDER)`  that can support equalsIgnoreCase().

According to my understanding, the current checkAlgorithm is not case sensitive, because it ignores the case of the item being checked. Looking forward to your suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From xuelei at openjdk.java.net  Fri Jun 18 05:33:25 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Jun 2021 05:33:25 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v2]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 04:56:25 GMT, Dongbo He  wrote:

>> The checkAlgorithm is using equalsIgnoreCase(), so it is safe for it.  My concern is mainly about the keywords, like "keySize" used the property, not really the algorithm name.  It is good to keep the current case sensitive checking behavior unchanged.
>
> Hi, Xuelei, thank you for your comments. I may not express it clearly, let me clarify. My concern is that if we use the HashSet:contains method to check whether an item is in the hash set, we cannot use equalsIgnoreCase(), so I used `new TreeSet<>(String.CASE_INSENSITIVE_ORDER)`  that can support equalsIgnoreCase().
> 
> According to my understanding, the current checkAlgorithm is not case sensitive, because it ignores the case of the item being checked. Looking forward to your suggestions?

I see your point now.  Thank you for the clarification.  I need more time to think about if there is an improvement.  I will be back.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From akolarkunnu at openjdk.java.net  Fri Jun 18 05:43:15 2021
From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu)
Date: Fri, 18 Jun 2021 05:43:15 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v2]
In-Reply-To: 
References: 
Message-ID: 

> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.

Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:

  8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4413/files
  - new: https://git.openjdk.java.net/jdk/pull/4413/files/4b866628..4969232f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4413&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4413&range=00-01

  Stats: 102 lines in 3 files changed: 60 ins; 35 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4413.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4413/head:pull/4413

PR: https://git.openjdk.java.net/jdk/pull/4413

From yyang at openjdk.java.net  Fri Jun 18 05:54:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  restore IndexOfOufBoundsException; split exception line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/593bf995..ec0a4d44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00-01

  Stats: 30 lines in 8 files changed: 15 ins; 2 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Fri Jun 18 05:54:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:05 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471:
> 
>> 469:      */
>> 470:     public int offsetByCodePoints(int index, int codePointOffset) {
>> 471:         checkOffset(index, count);
> 
> String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the future. I only mention it because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result.

Yes, changing the type of thrown exception may break something. And as David said, this also requires a CSR approval, which is a relatively long process, so I restored the original code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From ssahoo at openjdk.java.net  Fri Jun 18 06:09:31 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Fri, 18 Jun 2021 06:09:31 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 05:43:15 GMT, Abdul Kolarkunnu  wrote:

>> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.
>
> Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

test/jdk/sun/security/pkcs12/KeytoolOpensslInterop.sh line 25:

> 23: 
> 24: # Use OpenSSL 1.1.0i or above versions, earlier versions may generate different
> 25: # info and test fail.

It will be more helpful, if some instruction given about finding openssl, any pre-post requirement and any specific way to validate the result after execution for this manual Test execution.

test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 43:

> 41:  */
> 42: 
> 43: public class KeytoolOpensslInteropTest {

This file is not necessary and the shell script can have @run tag instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4413

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.java.net):_
> 
> On 17/06/2021 8:50 pm, Alan Bateman wrote:
> 
> > On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes  wrote:
> > > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> > 
> > 
> > It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception).
> 
> tiers 1-3 on Linux-x64 passed okay.
> 
> Any change to the exact type of exception thrown should be affirmed
> through a CSR request.
> 
> Cheers,
> David

Thank you David for running these tests!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
Message-ID: <_doEJsq2BCo-Bkj8aoB6EemEkhPS-eTcr_Zq8NIf0qM=.012d8685-d7eb-4133-bdf7-9366ee394004@github.com>

On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz  wrote:

>> src/java.base/share/classes/java/util/Base64.java line 934:
>> 
>>> 932:             if (closed)
>>> 933:                 throw new IOException("Stream is closed");
>>> 934:             Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());
>> 
>> You might want to split this really long line too, to avoid inconsistent line length in this source file.
>
> I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message).
> 
> See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps).

Ok, I've replaced

Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());

with 

Preconditions.checkFromIndexSize(len, off, b.length,
    Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));


----

I am curious about the motivations of current APIs:

public static 
int checkIndex(int index, int length,
               BiFunction, X> oobef) {
    if (index < 0 || index >= length)
        throw outOfBoundsCheckIndex(oobef, index, length);
    return index;
}

Are they over-engineered? When I checked all checkIndex-like patterns in the whole jdk codebase, I found that in most cases, providing an API that accepts custom exception should be enough for scalability:

int checkIndex(int index, int length, IndexOutOfBoundException iooe) {
    if (index < 0 || index >= length)
        throw iooe;
    return index;
}

In addition to the ease-of-use problem, there is another problem with the current API design.

Some methods in j.l.String are good replacement candidates for Preconditions.check{Index,...}:

https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/java/lang/String.java#L4558-L4604

But we **can not** do such replacement after my practice.

The third parameter of Preconditions.checkIndex is a BiFunction, which can be passed a lambda as its argument. The generated lambda method exercises many other codes like MethodHandles, j.l.Package, etc, eventually it called j.l.String.checkIndex itself, so if we replace j.l.String.checkIndex with `Preconditions.checkIndex(a,b,(x1,x2)->....)`, a StackOverflowError would occur at VM startup. 

If there is an API that accepts user-defined exceptions, I think we can apply Preconditions in more places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From Alan.Bateman at oracle.com  Fri Jun 18 06:49:23 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 18 Jun 2021 07:49:23 +0100
Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about
 Security Manager deprecation [v5]
In-Reply-To: 
References: 
 
 
Message-ID: <86e212d6-aa81-f949-6edb-15867f5e0171@oracle.com>

On 18/06/2021 03:51, Jaikiran Pai wrote:
> :
> Given all that, do you think that we should be printing the jar file paths in this WARNING message by default? I read the linked CSR, but I didn't see why the location of the jar or the name of the jar would be useful in this warning message. As long as the caller class (and perhaps the caller method) is printed, I think that should be enough of a summary on what's triggering this warning.
>
It's not hugely different to the "Illegal reflective access" warnings 
except I wouldn't expect many libraries to call setSecurityManager in a 
running system. Instead, it tends to be the main application that 
installs the SM at startup. However if code in a library were to call it 
then it useful to identify where that code is.

-Alan.

From dfuchs at openjdk.java.net  Fri Jun 18 08:45:26 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 18 Jun 2021 08:45:26 GMT
Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 16:23:08 GMT, Mahendra Chhipa  wrote:

>> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4432

From akolarkunnu at openjdk.java.net  Fri Jun 18 13:24:17 2021
From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu)
Date: Fri, 18 Jun 2021 13:24:17 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v3]
In-Reply-To: 
References: 
Message-ID: 

> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.

Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:

  8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4413/files
  - new: https://git.openjdk.java.net/jdk/pull/4413/files/4969232f..20d6bb5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4413&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4413&range=01-02

  Stats: 175 lines in 3 files changed: 78 ins; 97 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4413.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4413/head:pull/4413

PR: https://git.openjdk.java.net/jdk/pull/4413

From akolarkunnu at openjdk.java.net  Fri Jun 18 13:24:21 2021
From: akolarkunnu at openjdk.java.net (Abdul Kolarkunnu)
Date: Fri, 18 Jun 2021 13:24:21 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Jun 2021 06:06:01 GMT, Sibabrata Sahoo  wrote:

>> Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java
>
> test/jdk/sun/security/pkcs12/KeytoolOpensslInterop.sh line 25:
> 
>> 23: 
>> 24: # Use OpenSSL 1.1.0i or above versions, earlier versions may generate different
>> 25: # info and test fail.
> 
> It will be more helpful, if some instruction given about finding openssl, any pre-post requirement and any specific way to validate the result after execution for this manual Test execution.

Added more details.

> test/jdk/sun/security/pkcs12/KeytoolOpensslInteropTest.java line 43:
> 
>> 41:  */
>> 42: 
>> 43: public class KeytoolOpensslInteropTest {
> 
> This file is not necessary and the shell script can have @run tag instead.

Yes, corrected that way. Removed this file and done everything in the shell script.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4413

From weijun at openjdk.java.net  Fri Jun 18 13:54:59 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Jun 2021 13:54:59 GMT
Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about
 Security Manager deprecation [v6]
In-Reply-To: 
References: 
Message-ID: 

> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.
> 
> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  no more null as codeSource, rename one variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/13/files
  - new: https://git.openjdk.java.net/jdk17/pull/13/files/1e1e7221..885a0072

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=13&range=04-05

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/13.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13

PR: https://git.openjdk.java.net/jdk17/pull/13

From weijun at openjdk.java.net  Fri Jun 18 13:55:06 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 18 Jun 2021 13:55:06 GMT
Subject: [jdk17] RFR: 8268349: Provide clear run-time warnings about
 Security Manager deprecation [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Jun 2021 02:30:22 GMT, Jaikiran Pai  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   verbose warning message test and renaming in System.java
>
> src/java.base/share/classes/java/lang/System.java line 381:
> 
>> 379:         if (allowSecurityManager()) {
>> 380:             var caller = Reflection.getCallerClass();
>> 381:             String signature = caller.getName() + " (" + codeSource(caller) + ")";
> 
> Hello Weijun,
> 
> Given that the `codeSource()` method above is allowed to return `null`, there could be a case where the warning message printed would be something like:
> 
>> 
>> WARNING: A terminally deprecated method in java.lang.System has been called
>> WARNING: System::setSecurityManager has been called by foo.bar.Hello (null)
>> WARNING: Please consider reporting this to the maintainers of foo.bar.Hello
>> WARNING: System::setSecurityManager will be removed in a future release
>> 
> 
> Would that be OK or do you think the presence of "(null)" be unnecessary and confusing? Maybe in such cases that line should just say "System::setSecurityManager has been called by foo.bar.Hello"?
> 
> Another minor nit - the variable is named `signature` which initially gave me an impression that it was the method signature of the caller code, but that isn't the case. Should this variable be renamed perhaps?

Good catches. Will fix it. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/13

From mullan at openjdk.java.net  Fri Jun 18 15:33:52 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 18 Jun 2021 15:33:52 GMT
Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
Message-ID: 

Please review this fix to backout the change to Disable SHA-1 Signed JARs from JDK 17 due to a startup performance regression (see https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address the performance issue in JDK 18, which will also allow for more bake time.

-------------

Commit messages:
 - [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs.

Changes: https://git.openjdk.java.net/jdk17/pull/100/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=100&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267100
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/100/head:pull/100

PR: https://git.openjdk.java.net/jdk17/pull/100

From xuelei at openjdk.java.net  Fri Jun 18 15:56:30 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 18 Jun 2021 15:56:30 GMT
Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed
 JARs
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 15:21:06 GMT, Sean Mullan  wrote:

> Please review this fix to backout the change to Disable SHA-1 Signed JARs from JDK 17 due to a startup performance regression (see https://bugs.openjdk.java.net/browse/JDK-8266971). The plan is to now address the performance issue in JDK 18, which will also allow for more bake time.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/100

From psandoz at openjdk.java.net  Fri Jun 18 18:23:33 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 18 Jun 2021 18:23:33 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

@kahatlen for cases earlier in VM startup you need to avoid method references and lambda expressions. See the implementation of `outOfBoundsExceptionFormatter`, and see the usage in `VarHandle` for two examples.

Custom exception formaters should ideally be constants held in static final fields.

I think the API complexity comes down to whether it is necessary to preserve existing exception messages or not when converting existing code to use the precondition methods. The API is designed to do that and composes reasonably well for default exception messages with a non-default exceptions. We could argue (i would!) it is preferable to have a consistent exception messages for index out of bounds exceptions, thereby we could collapse and simplify, but this is sometimes considered a change in behaviour.

src/java.base/share/classes/java/util/Base64.java line 935:

> 933:                 throw new IOException("Stream is closed");
> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));

`outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From mullan at openjdk.java.net  Fri Jun 18 18:31:32 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 18 Jun 2021 18:31:32 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: 
References: 
Message-ID: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>

On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov  wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.

The change to `PKCS7::verify(byte[])` looks fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4482

From ascarpino at openjdk.java.net  Fri Jun 18 21:28:40 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 18 Jun 2021 21:28:40 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 08:16:42 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace HashSet with TreeSet

I will let Xuelei finish his review.  From what I see in the code, the Comparator is used when the algorithm is fully disabled.  The use of keywords later on in the Constraints constructor uses the ConstraintsEntry which I believe is stored with the upper and lower case.  I think the code should be ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From jwilhelm at openjdk.java.net  Fri Jun 18 22:26:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 22:26:34 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268316: Typo in JFR jdk.Deserialization event
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
 - 8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
 - 8265073: XML transformation and indentation when using xml:space
 - 8269025: jsig/Testjsig.java doesn't check exit code
 - 8266518: Refactor and expand scatter/gather tests
 - 8268903: JFR: RecordingStream::dump is missing @since
 - 8265369: [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed with "SocketException: Cannot allocate memory"
 - 8268564: mark hotspot serviceability/attach tests which ignore external VM flags
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/8f2456e5...ed622f4b

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
  Stats: 12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

PR: https://git.openjdk.java.net/jdk/pull/4533

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - Merge
 - 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
   
   Co-authored-by: Chris Cole 
   Reviewed-by: dsamersoff
 - 8268964: Remove unused ReferenceProcessorAtomicMutator
   
   Reviewed-by: tschatzl, pliden
 - 8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace
   
   Reviewed-by: dfuchs, chegar, michaelm
 - Merge
 - 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired
   
   Reviewed-by: xuelei
 - 8267189: Remove duplicated unregistered classes from dynamic archive
   
   Reviewed-by: ccheung, minqi
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
   
   Reviewed-by: dholmes, phh
 - 8268556: Use bitmap for storing regions that failed evacuation
   
   Reviewed-by: kbarrett, iwalulya, sjohanss
 - 8268294: Reusing HttpClient in a WebSocket.Listener hangs.
   
   Reviewed-by: dfuchs
 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/b8f073be...ed622f4b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4533&range=01
  Stats: 8681 lines in 159 files changed: 7992 ins; 386 del; 303 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

PR: https://git.openjdk.java.net/jdk/pull/4533

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:36 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: <2lNbBvRChZKSawaU5THoDLfbazhJcqIyt1V_Ew-3kNY=.f7fb1cfd-ecda-4fd3-874d-311a6d8362b9@github.com>

On Fri, 18 Jun 2021 22:17:41 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b7d78a5b
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/b7d78a5b661e2b00f271298db3b6cc873cf754e7
Stats:     12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4533

From peter.firmstone at zeus.net.au  Sun Jun 20 03:58:24 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 20 Jun 2021 13:58:24 +1000
Subject: JEP 411: Deprecation with removal would break most existing Java
 libraries
In-Reply-To: 
References: 
 <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com>
 <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au>
 
 
 
Message-ID: 


On 16/06/2021 11:18 pm, David Lloyd wrote:
>> There are already issues with Permission implementations, take for
>> example SocketPermission, it consults DNS and it isn't possible to enter
>> a range of IP addresses (such as the local subnet, and a list of public
>> IP addresses), for now, every single IP address must be entered and this
>> isn't practical.   The proposed API would allow us to re-implement
>> SocketPermission functionality, as well as other Permission implementations.
> Sure, this would be nice to clean up.


What the above example enhances:

  * Generation of policy files during integration testing.
  * Specifying Properties, to replace local information contained in URL
    and file paths, for later policy expansion.
  * In this specific case, I could substitute an IP address with a
    property that specified an allowed subnet mask, this would
    automatically expand the SocketPermission to the local subnet, and
    it would shrink the size of the generated policy file by eliminating
    other SocketPermission grants to IP addresses on the subnet.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From yyang at openjdk.java.net  Mon Jun 21 03:25:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: 

On Fri, 18 Jun 2021 18:03:44 GMT, Paul Sandoz  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/util/Base64.java line 935:
> 
>> 933:                 throw new IOException("Stream is closed");
>> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
>> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));
> 
> `outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

Thanks for the clarification! Fixed.

This incremental change does many stuff:
- Create inner classes and public static final fields within Preconditions
- Use Preconditions.check* in j.l.String
- Use Preconditions.*IOOBE_FORMATTER in java.util.zip.* classes
- Use Preconditions.*IOOBE_FORMATTER in java.util.Base64
- Use Preconditions.*IOOBE_FORMATTER in X-VarHandle.java.template and X-VarHandleByteArrayView.java.template
- Use Preconditions.*IOOBE_FORMATTER in sun.security.provider.DigestBase
- Use Preconditions.*IOOBE_FORMATTER in sun.security.util.ArrayUtil

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 03:25:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v3]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  new Preconditions.IOOBE_FORMATTER

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/ec0a4d44..c1dd2f76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=01-02

  Stats: 129 lines in 13 files changed: 43 ins; 40 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 04:17:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:17:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v4]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  format

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c1dd2f76..154989a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=02-03

  Stats: 15 lines in 1 file changed: 4 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 04:46:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:46:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v5]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  more replacements

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/154989a0..c8b2106e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=03-04

  Stats: 59 lines in 8 files changed: 11 ins; 37 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 05:17:09 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 05:17:09 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  more replacement 2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c8b2106e..3a8875ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=04-05

  Stats: 32 lines in 2 files changed: 1 ins; 20 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From michaelm at openjdk.java.net  Mon Jun 21 13:57:35 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 21 Jun 2021 13:57:35 GMT
Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 16:23:08 GMT, Mahendra Chhipa  wrote:

>> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 89:

> 87:         return hostaddr + ":" + server.getAddress().getPort();
> 88:     }
> 89:     public void handle(HttpExchange req) throws IOException {

Minor style point. I would put a blank line between the two methods.

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 170:

> 168:                 req.sendResponseHeaders(404, -1);
> 169:                 break;
> 170:         }

Probably should add a call to "req.close()" at the end of the method.

test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java line 366:

> 364:                 TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
> 365:                 tmf.init(ts);
> 366: 

Could SimpleSSLContext be used here instead of manually writing this code? Same for other tests with same pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4432

From psandoz at openjdk.java.net  Mon Jun 21 21:02:30 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 21 Jun 2021 21:02:30 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more replacement 2

All the updates to the check* methods look ok (requires some careful looking!).

I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:

> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
> 77: 
> 78:     public static final BiFunction, StringIndexOutOfBoundsException> AIOOBE_FORMATTER

Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From xuelei at openjdk.java.net  Mon Jun 21 21:43:35 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Mon, 21 Jun 2021 21:43:35 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v3]
In-Reply-To: 
References: 
 
Message-ID: <-Qv8KJs44sQ-x3au21b7vj9ESCaigOmu92XlUZHnO-4=.e134fe10-1b87-4046-bb72-ba934b55463f@github.com>

On Thu, 17 Jun 2021 08:16:42 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace HashSet with TreeSet

Changes requested by xuelei (Reviewer).

src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 90:

> 88:         }
> 89: 
> 90:         Set elements = null;

This line could be placed and merged with line 96-98.

`Set elements = decomposer.decompose(algorithm);`

src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 101:

> 99:         // check the element of the elements
> 100:         for (String element : elements) {
> 101:             if (algorithms.contains(algorithm)) {

The check should be placed on the decomposed elements.


- if (algorithms.contains(algorithm)) 
+ if (algorithms.contains(element))

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 133:

> 131: 
> 132:         // Check for alias
> 133:         Pattern INCLUDE_PATTERN = Pattern.compile("include " + PROPERTY_DISABLED_EC_CURVES, Pattern.CASE_INSENSITIVE);

Per the Java code conventions, the variable name could be "includePattern",  rather than using capital all letters.

Please keep each line less than or equal to 80 bytes.

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 134:

> 132:         // Check for alias
> 133:         Pattern INCLUDE_PATTERN = Pattern.compile("include " + PROPERTY_DISABLED_EC_CURVES, Pattern.CASE_INSENSITIVE);
> 134:         Matcher matcher;

I think the performance impact should be trivial if moving the "matcher" declaration into the for-loop block.

src/java.base/share/classes/sun/security/util/LegacyAlgorithmConstraints.java line 31:

> 29: import java.security.CryptoPrimitive;
> 30: import java.security.Key;
> 31: import java.util.HashSet;

I guess this line could be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From weijun at openjdk.java.net  Mon Jun 21 22:53:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 21 Jun 2021 22:53:38 GMT
Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
Message-ID: 

This is a copy of https://github.com/openjdk/jdk17/pull/100 so that I can integrate the fix for @seanjmullan.

-------------

Commit messages:
 - [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs.

Changes: https://git.openjdk.java.net/jdk17/pull/113/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=113&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267100
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/113.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/113/head:pull/113

PR: https://git.openjdk.java.net/jdk17/pull/113

From hchao at openjdk.java.net  Mon Jun 21 22:57:30 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 21 Jun 2021 22:57:30 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 13:24:17 GMT, Abdul Kolarkunnu  wrote:

>> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.
>
> Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

Marked as reviewed by hchao (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4413

From hchao at openjdk.java.net  Mon Jun 21 23:00:28 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 21 Jun 2021 23:00:28 GMT
Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed
 JARs
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Jun 2021 22:43:58 GMT, Weijun Wang  wrote:

> This is a copy of https://github.com/openjdk/jdk17/pull/100 so that I can integrate the fix for @seanjmullan.

Marked as reviewed by hchao (Committer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/113

From xuelei at openjdk.java.net  Tue Jun 22 00:15:28 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Jun 2021 00:15:28 GMT
Subject: [jdk17] RFR: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed
 JARs
In-Reply-To: 
References: 
Message-ID: <4LxbqyqTj0QPwluRn9UWiin41CYR1PWjeCClUZeUkIY=.015e4777-8fa5-42a0-b159-b927225f2272@github.com>

On Mon, 21 Jun 2021 22:43:58 GMT, Weijun Wang  wrote:

> This is a copy of https://github.com/openjdk/jdk17/pull/100 so that I can integrate the fix for @seanjmullan.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/113

From weijun at openjdk.java.net  Tue Jun 22 00:45:31 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Jun 2021 00:45:31 GMT
Subject: [jdk17] Integrated: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1
 Signed JARs
In-Reply-To: 
References: 
Message-ID: <6-INU0OTPV6VZGbZ0c9K-3XuZlpFi4HtrU_C3X779R0=.cd1261be-171a-44b6-886a-0dbb648d8282@github.com>

On Mon, 21 Jun 2021 22:43:58 GMT, Weijun Wang  wrote:

> This is a copy of https://github.com/openjdk/jdk17/pull/100 so that I can integrate the fix for @seanjmullan.

This pull request has now been integrated.

Changeset: e2d7ec38
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk17/commit/e2d7ec38af4e13cfbd303fa37e766aa2071cfd1f
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs

Co-authored-by: Sean Mullan 
Reviewed-by: hchao, xuelei

-------------

PR: https://git.openjdk.java.net/jdk17/pull/113

From weijun at openjdk.java.net  Tue Jun 22 02:10:29 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 22 Jun 2021 02:10:29 GMT
Subject: [jdk17] Integrated: 8268349: Provide clear run-time warnings about
 Security Manager deprecation
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Jun 2021 01:59:59 GMT, Weijun Wang  wrote:

> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.
> 
> This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added.

This pull request has now been integrated.

Changeset: ef4ba224
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk17/commit/ef4ba224c4887b2e307937754064d3623a2d3de5
Stats:     177 lines in 6 files changed: 102 ins; 33 del; 42 mod

8268349: Provide clear run-time warnings about Security Manager deprecation

Reviewed-by: lancea, mullan, alanb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/13

From yyang at openjdk.java.net  Tue Jun 22 02:39:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  correct exception type; use anonymous inner classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/3a8875ec..2330ee38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=05-06

  Stats: 21 lines in 1 file changed: 0 ins; 9 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Tue Jun 22 02:39:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: 

On Mon, 21 Jun 2021 20:49:56 GMT, Paul Sandoz  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more replacement 2
>
> src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:
> 
>> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
>> 77: 
>> 78:     public static final BiFunction, StringIndexOutOfBoundsException> AIOOBE_FORMATTER
> 
> Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

Fixed.

FYI: Current exception message looks like this:

Exception in thread "main" java.lang.StringIndexOutOfBoundsException: Range [3, 1) out of bounds for length 6
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:77)
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:72)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:159)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:156)
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:62)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Preconditions.java:76)
	at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Preconditions.java:295)
	at CheckIndex.main(CheckIndex.java:110)

I think now it expresses more exception information than before(and more consistent).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From dongbohe at openjdk.java.net  Tue Jun 22 02:46:02 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 22 Jun 2021 02:46:02 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v4]
In-Reply-To: 
References: 
Message-ID: 

> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
> 
> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
> Baseline results before patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
> 
> Benchmark results after patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
> 
> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
> 
> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
> Before patch:
> 
> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> After patch:
> 
> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> 
> Testing: tier1, tier2

Dongbo He has updated the pull request incrementally with one additional commit since the last revision:

  refactor the code && fix some errors

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4424/files
  - new: https://git.openjdk.java.net/jdk/pull/4424/files/0253fdb2..b863e2b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=02-03

  Stats: 9 lines in 3 files changed: 1 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424

PR: https://git.openjdk.java.net/jdk/pull/4424

From yyang at openjdk.java.net  Tue Jun 22 03:01:35 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 03:01:35 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>

On Tue, 22 Jun 2021 02:39:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct exception type; use anonymous inner classes

I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From xuelei at openjdk.java.net  Tue Jun 22 03:53:34 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Jun 2021 03:53:34 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 02:46:02 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code && fix some errors

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 133:

> 131: 
> 132:         // Check for alias
> 133:         Pattern INCLUDE_PATTERN = Pattern.compile(

You may miss my previous comment.  This variable is not static, hence all capital letters naming does not apply here.

As you are already here, it may be nice if you'd like to have this variable as a static final class field.  Then, the compile() will be called one time at most for this class.  As a static class field, you could use the capitalized name.

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 139:

> 137:             if ((matcher = INCLUDE_PATTERN.matcher(s)).matches()) {
> 138:                 disabledAlgorithms.remove(matcher.group());
> 139:                 disabledAlgorithms.addAll(getAlgorithms(PROPERTY_DISABLED_EC_CURVES));

I guess this line exceed 80 characters?  Please keep it in 80 characters for each line.

src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 139:

> 137:             if ((matcher = INCLUDE_PATTERN.matcher(s)).matches()) {
> 138:                 disabledAlgorithms.remove(matcher.group());
> 139:                 disabledAlgorithms.addAll(getAlgorithms(PROPERTY_DISABLED_EC_CURVES));

It may increase the readability a little bit if having the assignment in the declaration line:

-             Matcher matcher;
-             if ((matcher = INCLUDE_PATTERN.matcher(s)).matches()) {
+             Matcher matcher = INCLUDE_PATTERN.matcher(s);
+             if (matcher.matches()) {

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From ssahoo at openjdk.java.net  Tue Jun 22 04:37:26 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Tue, 22 Jun 2021 04:37:26 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 13:24:17 GMT, Abdul Kolarkunnu  wrote:

>> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.
>
> Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

Marked as reviewed by ssahoo (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4413

From dongbohe at openjdk.java.net  Tue Jun 22 06:41:06 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 22 Jun 2021 06:41:06 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <5R1xPpfUXpXjmq6T0iaC3sdcTQy0S8rZD_gxlT5rNBc=.bb2594a4-e690-4c86-9bac-298c418fc10a@github.com>

On Tue, 22 Jun 2021 03:45:32 GMT, Xue-Lei Andrew Fan  wrote:

>> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor the code && fix some errors
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 133:
> 
>> 131: 
>> 132:         // Check for alias
>> 133:         Pattern INCLUDE_PATTERN = Pattern.compile(
> 
> You may miss my previous comment.  This variable is not static, hence all capital letters naming does not apply here.
> 
> As you are already here, it may be nice if you'd like to have this variable as a static final class field.  Then, the compile() will be called one time at most for this class.  As a static class field, you could use the capitalized name.

Sorry, I misunderstood what you meant before, I will fix it. Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From dongbohe at openjdk.java.net  Tue Jun 22 06:41:02 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 22 Jun 2021 06:41:02 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v5]
In-Reply-To: 
References: 
Message-ID: 

> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
> 
> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
> Baseline results before patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
> 
> Benchmark results after patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
> 
> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
> 
> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
> Before patch:
> 
> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> After patch:
> 
> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> 
> Testing: tier1, tier2

Dongbo He has updated the pull request incrementally with one additional commit since the last revision:

  fix the code style

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4424/files
  - new: https://git.openjdk.java.net/jdk/pull/4424/files/b863e2b3..02b09719

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4424&range=03-04

  Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4424/head:pull/4424

PR: https://git.openjdk.java.net/jdk/pull/4424

From pconcannon at openjdk.java.net  Tue Jun 22 11:04:42 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 11:04:42 GMT
Subject: RFR: 8268967: Update java.security to use switch expressions
Message-ID: 

Hi,

Could someone please review my code for updating the code in the `java.security` packages to make use of the switch expressions?

Kind regards,
Patrick

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8268967
 - 8268967: Update java.security to use switch expressions

Changes: https://git.openjdk.java.net/jdk/pull/4553/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4553&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268967
  Stats: 107 lines in 3 files changed: 0 ins; 61 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4553.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4553/head:pull/4553

PR: https://git.openjdk.java.net/jdk/pull/4553

From coffeys at openjdk.java.net  Tue Jun 22 12:08:46 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:08:46 GMT
Subject: RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
Message-ID: 

Sufficient permissions missing if this code was ever to run with SecurityManager. 

Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
Test case coverage extended to cover the SecurityManager scenario.

Reviewer request: @valeriepeng

-------------

Commit messages:
 - 8269034: AccessControlException for SunPKCS11 daemon threads

Changes: https://git.openjdk.java.net/jdk/pull/4555/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4555&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
  Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4555/head:pull/4555

PR: https://git.openjdk.java.net/jdk/pull/4555

From coffeys at openjdk.java.net  Tue Jun 22 12:38:27 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:38:27 GMT
Subject: Withdrawn: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4555

From coffeys at openjdk.java.net  Tue Jun 22 12:38:27 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:38:27 GMT
Subject: RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Please ignore - I'm going to open a PR against jdk17 for this

-------------

PR: https://git.openjdk.java.net/jdk/pull/4555

From github.com+10835776+stsypanov at openjdk.java.net  Tue Jun 22 12:59:35 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 22 Jun 2021 12:59:35 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov  wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4482

From coffeys at openjdk.java.net  Tue Jun 22 13:32:45 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 13:32:45 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
Message-ID: 

Sufficient permissions missing if this code was ever to run with SecurityManager. 

Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
Test case coverage extended to cover the SecurityManager scenario.

Reviewer request: @valeriepeng

-------------

Commit messages:
 - 8269034: AccessControlException for SunPKCS11 daemon threads

Changes: https://git.openjdk.java.net/jdk17/pull/117/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
  Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From xuelei at openjdk.java.net  Tue Jun 22 14:43:29 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Jun 2021 14:43:29 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v5]
In-Reply-To: 
References: 
 
Message-ID: <1xwudpZzS8YuHZLdvH7DzhHeBIRIYjMt2Sev7aOdYlQ=.e363d5c9-54ca-4695-9afc-efeaa8c7972c@github.com>

On Tue, 22 Jun 2021 06:41:02 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the code style

Looks good to me.  Thank you!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4424

From xuelei at openjdk.java.net  Tue Jun 22 14:50:27 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Jun 2021 14:50:27 GMT
Subject: RFR: 8268967: Update java.security to use switch expressions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 10:56:00 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.security` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

Looks good to me.  Thanks for the nice update.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4553

From xuelei at openjdk.java.net  Tue Jun 22 14:55:26 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 22 Jun 2021 14:55:26 GMT
Subject: RFR: 8266182: Create a manual test for
 jdk/sun/security/pkcs12/ParamsTest.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 13:24:17 GMT, Abdul Kolarkunnu  wrote:

>> ParamsTest is an interop test between keytool <-> openssl. There are some manual steps listed in jdk/sun/security/pkcs12/params/README to perform after the execution of jtreg execution. So this test is to perform that manual steps.
>
> Abdul Kolarkunnu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266182: Create a manual test for jdk/sun/security/pkcs12/ParamsTest.java

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4413

From psandoz at openjdk.java.net  Tue Jun 22 17:57:27 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 22 Jun 2021 17:57:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
Message-ID: 

On Tue, 22 Jun 2021 02:58:28 GMT, Yi Yang  wrote:

> I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

Yes, I think that helps to review. It's often easier, review-wise, to have separate PRs for specific areas, rather than keep expanding an existing PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From coffeys at openjdk.java.net  Tue Jun 22 20:08:03 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 20:08:03 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
Message-ID: 

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Move TokenPoller to Runnable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/117/files
  - new: https://git.openjdk.java.net/jdk17/pull/117/files/2a168946..03af6494

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From peter.firmstone at zeus.net.au  Tue Jun 22 21:40:12 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 23 Jun 2021 07:40:12 +1000
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: 
References: 
Message-ID: <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>

Was ever to run with SecurityManager?

When you see an AccessControlException, I'd recommend setting the 
following security debug property, so you can capture the 
ProtectionDomain that failed the access check: 
-Djava.security.debug=access:failure? Clearly there's a ProtectionDomain 
on the calling threads stack that doesn't have the necessary 
permission.? If you knew which one it was, you could just grant it 
java.lang.RuntimePermission "setContextClassLoader" permission in the 
policy file.

In NativeResourceCleaner the original constructor is setting the Context 
ClassLoader of the calling thread to null, prior to calling the Thread 
superclass constructor, so that both the calling thread and new thread 
will nave a null context ClassLoader.? In your new implementation, you 
are asserting the context class loader of the created thread is null, 
without setting the context ClassLoader of the original calling thread, 
is that the intended behaviour?

Alternatively you could set the context ClassLoader of the calling 
thread to null using a PrivilegedAction, prior to creating the new 
thread and restore it?

If the original intent was to set the context ClassLoader of the new 
thread to null, then why not just do that, rather than use an assertion?

If assertions are not enabled it may run with a non null context 
ClassLoader??? What are the consequences?? It appears to me, the fix has 
created a bigger problem, rather than fixed it.? Just my 2 cents.

We use SecurityManager by default following principles of least 
privilege (only the code paths we need to execute), and the original 
reported bug is a non problem for us, we would capture the missing 
permission and grant it, these are permission grants for Java 16:

grant codebase "jrt:/jdk.crypto.cryptoki"
{
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.crypto.ec"
{
 ??? permission java.security.SecurityPermission 
"putProviderProperty.SunEC";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.jca";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.pkcs";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math.intpoly";
 ??? permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.x509";
};

Good call making NativeResourceCleaner implement Runnable instead of extending Thread though.

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


On 22/06/2021 11:32 pm, Sean Coffey wrote:
> Sufficient permissions missing if this code was ever to run with SecurityManager.
>
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
>
> Reviewer request: @valeriepeng
>
> -------------
>
> Commit messages:
>   - 8269034: AccessControlException for SunPKCS11 daemon threads
>
> Changes: https://git.openjdk.java.net/jdk17/pull/117/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
>    Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
>    Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117
>
> PR: https://git.openjdk.java.net/jdk17/pull/117


From jwilhelm at openjdk.java.net  Wed Jun 23 00:31:30 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 00:31:30 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"
 - 8267652: c2 loop unrolling by 8 results in reading memory past array
 - 8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion
 - 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken
 - 8268524: nmethod::post_compiled_method_load_event racingly called on zombie
 - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
 - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
 - 8268349: Provide clear run-time warnings about Security Manager deprecation
 - 8268293: VectorAPI cast operation on mask and shuffle is broken
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0c693e2f...7bf4b35f

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
  Stats: 1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge
 - 8268290: Improve LockFreeQueue<> utility
   
   Reviewed-by: iwalulya, tschatzl
 - 8264941: Remove CodeCache::mark_for_evol_deoptimization() method
   
   Reviewed-by: kvn, vlivanov, sspitsyn
 - 8269031: linux x86_64 check for binutils 2.25 or higher after 8265783
   
   Reviewed-by: ihse, erikj
 - 8267657: Add missing PrintC1Statistics before incrementing counters
   
   Reviewed-by: iveresov
 - 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
   
   Reviewed-by: dholmes
 - 8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest
   
   Reviewed-by: tschatzl, kbarrett
 - Merge
 - 8268458: Add verification type for evacuation failures
   
   Reviewed-by: kbarrett, iwalulya
 - 8268952: Automatically update heap sizes in G1MonitoringScope
   
   Reviewed-by: kbarrett, iwalulya
 - ... and 49 more: https://git.openjdk.java.net/jdk/compare/35e4c272...7bf4b35f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4562&range=01
  Stats: 16267 lines in 261 files changed: 13210 ins; 2433 del; 624 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: <_z9pXnmkit5l3vbQ1LT3mAP67fTQ2wh8P8g7ScaZVGw=.91f3374b-1abd-416d-a80b-d0a540f6889e@github.com>

On Wed, 23 Jun 2021 00:21:57 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9
Stats:     1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4562

From dongbohe at openjdk.java.net  Wed Jun 23 02:42:33 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 23 Jun 2021 02:42:33 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 06:41:02 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the code style

Thank you for your review, Xuelei.

Hi, mullan, ascarpino. Can I get some comments from you? @seanjmullan @ascarpino

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From peter.firmstone at zeus.net.au  Wed Jun 23 03:02:10 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 23 Jun 2021 13:02:10 +1000
Subject: Authorization layer API and low level access checks.
Message-ID: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>

Java developers such as myself need a light weight API that allows 
developers to continue to support authorization and access controls, 
without dictating how that should be implemented or whether these 
controls are fine grained, course grained, based solely on user 
authorization or also includes code authorization.

SecurityManager has been deprecated, we need to commence removal of 
dependencies on deprecated Java API's, however we are unable to make a 
decision on how to proceed without understanding the level of support 
that OpenJDK will provide for an authorization layer in future. (If this 
is zero, we at least need to know).

Currently there is no such API that allows developers who require an 
authorization layer to continue to supporting Java 8 as well future 
versions Java with one development codebase.? It's a non goal of this to 
debate the need for cross version support.?? I simply wish to open 
discussions on alternatives and whether OpenJDK is considering them.

SecurityManager API low level functionality replacements:

 1. StackWalker - Can stack walker be back ported to Java 8?
 2. Permission checks - Can we have low level Guard service hooks to
    replace existing permission checks?

Note: I'm not sure how to replace an inherited AccessControlContext 
(with a new implementation based on StackWalker functionality) at thread 
creation time, as it must be created when threads are created, possibly 
by using ThreadFactory everywhere, but this doesn't cover all threads.? 
How to cater for virtual threads?

For replacement of permission checks, I propose using a Guard service 
authorization API (feel free to propose alternatives).

The proposed authorization layer API would utilize the existing Provider 
Service mechanism to register authorization layer hooks, for use in 
permission checks by JDK code, and library code that implements their 
own Permission's:

GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);

// Permission check

createClassLoader.check();

Guard exitVM = runtimeGuardFactory.orders("exitVM", null);

exitVM.check();


GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

// Permission check
socketGuardFactory.orders(host, action).check();

GuardFactory fileGuardFactory = GuardFactory.getInstance("FILE");

fileGuardFactory.orders(path, actions).check();


Guard service hooks, are based on existing Permission types (independent 
instances to avoid circular deadlocks), developers only need implement 
those relevant to them and may only use checks for users if they wish:

"AWT"
 ?"FILE"
 ?"SERIALIZABLE"
 ?"MANAGEMENT"
 ?"REFLECT"
 ?"RUNTIME"
 ?"NET"
 ?"SOCKET"
 ?"URL"
 ?"FILE-LINK"
 ?"SECURITY"
 ?"SQL"
 ?"LOGGING"
 ?"PROPERTY"
 ?"MBEAN"
 ?"MBEAN-SERVER"
 ?"MBEAN-TRUST"
 ?"SUBJECT-DELEGATION"
 ?"TLS"
 ?"AUTH"
 ?"KERBEROS-DELEGATION"
 ?"KERBEROS-SERVICE"
 ?"PRIVATE-CREDENTIAL"
 ?"AUDIO"
 ?"JAXB"
 ?"WEB-SERVICE"

I would like to suggest adding a new provider type:

"PARSE-DATA" - To be called by any code about to parse data, eg 
deserialization, XML, JSON, SQL, etc. ? The use case for this is for 
servers to grant it to authenticated users (user supplied input data), 
so that it can only be performed following user authentication.

Existing Permission implementations

-- 
Regards,
  
Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From yyang at openjdk.java.net  Wed Jun 23 03:54:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 23 Jun 2021 03:54:55 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  tests rely on IOOBE exception message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/2330ee38..ab1b509d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06-07

  Stats: 104 lines in 2 files changed: 18 ins; 2 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From alanb at openjdk.java.net  Wed Jun 23 06:23:28 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 06:23:28 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

src/java.base/share/classes/module-info.java line 202:

> 200:         jdk.charsets,
> 201:         jdk.compiler,
> 202:         jdk.crypto.cryptoki,

At some point I'd like to see this re-visited so we can avoid exporting this package to modules defined to the platform class loader.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From Alan.Bateman at oracle.com  Wed Jun 23 06:34:23 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 23 Jun 2021 07:34:23 +0100
Subject: Authorization layer API and low level access checks.
In-Reply-To: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
Message-ID: <34cff817-a624-9e4b-60f9-d831f6aa448d@oracle.com>

On 23/06/2021 04:02, Peter Firmstone wrote:
>
> Note: I'm not sure how to replace an inherited AccessControlContext 
> (with a new implementation based on StackWalker functionality) at 
> thread creation time, as it must be created when threads are created, 
> possibly by using ThreadFactory everywhere, but this doesn't cover all 
> threads. How to cater for virtual threads?
>
I don't think the inherited AccessControlContext is widely known or even 
clearly specified. In any case, virtual threads do not want to be 
burdened with this field. For now they are specified to not support any 
permissions. The FJ common pool is another example, the threads don't 
have any permissions either (see FJP class description has more on that).

-Alan

From sean.coffey at oracle.com  Wed Jun 23 07:10:45 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 23 Jun 2021 08:10:45 +0100
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
References: 
 <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
Message-ID: <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>

Thank for the feedback Peter. Comments inline.

On 22/06/2021 22:40, Peter Firmstone wrote:
> Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a 
configuration file with the SunPKCS11 Provider by default - We have 
tests to register Providers while SecurityManager is in place. This 
failed for SunPKCS11.
>
> When you see an AccessControlException, I'd recommend setting the 
> following security debug property, so you can capture the 
> ProtectionDomain that failed the access check: 
> -Djava.security.debug=access:failure? Clearly there's a 
> ProtectionDomain on the calling threads stack that doesn't have the 
> necessary permission.? If you knew which one it was, you could just 
> grant it java.lang.RuntimePermission "setContextClassLoader" 
> permission in the policy file.
Yes - that was one of my first actions. [1]. The jdk.crypto.cryptoki 
ProtectionDomain lacks the permission and rightly so IMO. The default 
policy doesn't grant "setContextClassLoader" permission to any JDK 
module. It's not required when we use InnocuousThread.
>
> In NativeResourceCleaner the original constructor is setting the 
> Context ClassLoader of the calling thread to null, prior to calling 
> the Thread superclass constructor, so that both the calling thread and 
> new thread will nave a null context ClassLoader.? In your new 
> implementation, you are asserting the context class loader of the 
> created thread is null, without setting the context ClassLoader of the 
> original calling thread, is that the intended behaviour?
>
> Alternatively you could set the context ClassLoader of the calling 
> thread to null using a PrivilegedAction, prior to creating the new 
> thread and restore it?
Use of InnocuousThread is made in various JDK classes for similar 
purpose where daemon threads need to be run with limited privilege. 
Similar use seen in networking and ldap classes.

>
> If the original intent was to set the context ClassLoader of the new 
> thread to null, then why not just do that, rather than use an assertion?
InnocuousThread sets this to null. The assert is just a belt and braces 
approach which is a useful check during test runs. Again, similar 
approach done in other JDK libraries.
>
> If assertions are not enabled it may run with a non null context 
> ClassLoader??? What are the consequences?? It appears to me, the fix 
> has created a bigger problem, rather than fixed it.? Just my 2 cents.

see above. We shouldn't have an issue. A non-null classloader would lead 
to classloader memory leak in some environments.

regards,
Sean.

>
> We use SecurityManager by default following principles of least 
> privilege (only the code paths we need to execute), and the original 
> reported bug is a non problem for us, we would capture the missing 
> permission and grant it, these are permission grants for Java 16:
>
> grant codebase "jrt:/jdk.crypto.cryptoki"
> {
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util";
> };
>
> grant codebase "jrt:/jdk.crypto.ec"
> {
> ??? permission java.security.SecurityPermission 
> "putProviderProperty.SunEC";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.jca";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.pkcs";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util.math";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util.math.intpoly";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.x509";
> };
>
> Good call making NativeResourceCleaner implement Runnable instead of 
> extending Thread though.


[1]

access: domain that failed ProtectionDomain (jrt:/jdk.crypto.cryptoki 
)
 ?jdk.internal.loader.ClassLoaders$PlatformClassLoader at 5433274e
 ?
 ?java.security.Permissions at 7006c658 (
 ?("java.io.FilePermission" "<>" "read")
 ?("java.net.SocketPermission" "localhost:0" "listen,resolve")
 ?("java.security.SecurityPermission" "clearProviderProperties.*")
 ?("java.security.SecurityPermission" 
"getProperty.auth.login.defaultCallbackHandler")
 ?("java.security.SecurityPermission" "putProviderProperty.*")
 ?("java.security.SecurityPermission" "authProvider.*")
 ?("java.security.SecurityPermission" "removeProviderProperty.*")
 ?("java.util.PropertyPermission" "java.specification.version" "read")
 ?("java.util.PropertyPermission" "java.vm.vendor" "read")
 ?("java.util.PropertyPermission" "path.separator" "read")
 ?("java.util.PropertyPermission" "os.version" "read")
 ?("java.util.PropertyPermission" "java.vendor.url" "read")
 ?("java.util.PropertyPermission" "java.vm.name" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.version" "read")
 ?("java.util.PropertyPermission" "os.name" "read")
 ?("java.util.PropertyPermission" 
"sun.security.pkcs11.allowSingleThreadedModules" "read")
 ?("java.util.PropertyPermission" 
"sun.security.pkcs11.disableKeyExtraction" "read")
 ?("java.util.PropertyPermission" "java.version" "read")
 ?("java.util.PropertyPermission" "os.arch" "read")
 ?("java.util.PropertyPermission" "java.specification.vendor" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.name" "read")
 ?("java.util.PropertyPermission" "file.separator" "read")
 ?("java.util.PropertyPermission" "line.separator" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.vendor" "read")
 ?("java.util.PropertyPermission" "java.specification.name" "read")
 ?("java.util.PropertyPermission" "java.vendor" "read")
 ?("java.util.PropertyPermission" "java.vm.version" "read")
 ?("java.util.PropertyPermission" "jdk.crypto.KeyAgreement.legacyKDF" 
"read")
 ?("java.util.PropertyPermission" "java.class.version" "read")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")
 ?("java.lang.RuntimePermission" "accessClassInPackage.sun.security.*")
 ?("java.lang.RuntimePermission" 
"accessClassInPackage.com.sun.crypto.provider")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")
 ?("java.lang.RuntimePermission" 
"accessClassInPackage.com.sun.java.swing.plaf.*")
 ?("java.lang.RuntimePermission" "accessSystemModules")
 ?("java.lang.RuntimePermission" "accessClassInPackage.sun.nio.ch")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")
 ?("java.lang.RuntimePermission" "loadLibrary.j2pkcs11")
)

Exception in thread "main" java.security.ProviderException: 
Initialization failed
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:386)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:117)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:114)
 ??????? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:114)
 ??????? at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:257)
 ??????? at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)
 ??????? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
 ??????? at 
java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:248)
 ??????? at 
java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:226)
 ??????? at 
java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:317)
 ??????? at 
java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:334)
 ??????? at 
java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:175)
 ??????? at java.base/java.security.Security.getProviders(Security.java:458)
 ??????? at DefaultPKCS11.main(DefaultPKCS11.java:13)
Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "setContextClassLoader")
 ??????? at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485)
 ??????? at 
java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
 ??????? at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
 ??????? at 
java.base/java.lang.Thread.setContextClassLoader(Thread.java:1525)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$NativeResourceCleaner.(SunPKCS11.java:982)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:1193)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:377)
 ??????? ... 14 more


From shade at openjdk.java.net  Wed Jun 23 07:45:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 07:45:36 GMT
Subject: RFR: 8269216: Useless initialization in
 com/sun/crypto/provider/PBES2Parameters.java
Message-ID: 

SonarCloud reports:
"Remove or correct this useless self-assignment."


        if (cipherAlgo.equals("AES")) {
            this.keysize = keysize; // <---- here
            switch (keysize) {
            case 128:
                cipherAlgo_OID = aes128CBC_OID;


Seems to be here since initial addition in JDK-6383200.

Additional testing:
 - [x] `jdk_security` pass

-------------

Commit messages:
 - 8269216: Useless initialization in com/sun/crypto/provider/PBES2Parameters.java

Changes: https://git.openjdk.java.net/jdk/pull/4570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4570&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269216
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4570/head:pull/4570

PR: https://git.openjdk.java.net/jdk/pull/4570

From shade at openjdk.java.net  Wed Jun 23 08:17:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 08:17:56 GMT
Subject: [jdk17] RFR: 8269218: GaloisCounterMode.overlapDetection misses the
 JDK-8263436 fix again
Message-ID: 

SonarCloud again complains about GaloisCounterMode.overlapDetection, in the similar way JDK-8263436 did. I think JDK-8255557 accidentally reintroduced the old code.

The tangential question if JDK-8255557 reverted anything else.

Additional testing:
 - [x] `jdk_security` passes

-------------

Commit messages:
 - 8269218: GaloisCounterMode.overlapDetection misses the JDK-8263436 fix again

Changes: https://git.openjdk.java.net/jdk17/pull/124/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=124&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269218
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/124.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/124/head:pull/124

PR: https://git.openjdk.java.net/jdk17/pull/124

From adinn at redhat.com  Wed Jun 23 09:19:42 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 23 Jun 2021 10:19:42 +0100
Subject: Authorization layer API and low level access checks.
In-Reply-To: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
Message-ID: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>

OHi Peter,

n 23/06/2021 04:02, Peter Firmstone wrote:
>  1. StackWalker - Can stack walker be back ported to Java 8?

The right place to ask about this is the jdk8u updates project list. 
However, you probably don't need to ask there because the answer is 
almost certainly going to be a very loud no.

JDK8u is in long term maintenance mode. The goal of the updates project 
for that release is to fix security issues and critical bugs *and 
nothing else* so that existing deployments remain stable as far as 
possible. Except when required to meet those goals backporting of new 
functionality is done only under exceptional circumstances.

The only recent examples of new function backports that I am aware of 
have involved merging up functionality from downstream releases in order 
to 1) unify the platform and 2) enable downstream contributors to help 
to maintain a single, standard release i.e. highly exceptional cases 
where there was a problem for existing users. Your request, by contrast, 
is exactly the sort of case that maintainers are trying to avoid -- it 
will introduce change with no gain and the potential of breakage for the 
vast majority of users.

If you want to deal with  deployments pre and post removal of the 
Authorization support that you currently rely on I suggest you consider 
doing that by using a multi-release implementation and package it using 
the multi-release jar format. If you don't like the idea of 
multi-release jars you can still implement a standard jar format 
solution using a provider model. However, you will still need to build 
the alternative provider jars using the relevant JDK releases so that 
different providers can rely on different JDK capabilities..

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From forax at univ-mlv.fr  Wed Jun 23 10:02:14 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 23 Jun 2021 12:02:14 +0200 (CEST)
Subject: Authorization layer API and low level access checks.
In-Reply-To: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
Message-ID: <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Andrew Dinn" 
> ?: "Peter Firmstone" , "discuss" 
> Cc: "security-dev" 
> Envoy?: Mercredi 23 Juin 2021 11:19:42
> Objet: Re: Authorization layer API and low level access checks.

> OHi Peter,
> 
> n 23/06/2021 04:02, Peter Firmstone wrote:
>>  1. StackWalker - Can stack walker be back ported to Java 8?
> 
> The right place to ask about this is the jdk8u updates project list.
> However, you probably don't need to ask there because the answer is
> almost certainly going to be a very loud no.
> 
> JDK8u is in long term maintenance mode. The goal of the updates project
> for that release is to fix security issues and critical bugs *and
> nothing else* so that existing deployments remain stable as far as
> possible. Except when required to meet those goals backporting of new
> functionality is done only under exceptional circumstances.
> 
> The only recent examples of new function backports that I am aware of
> have involved merging up functionality from downstream releases in order
> to 1) unify the platform and 2) enable downstream contributors to help
> to maintain a single, standard release i.e. highly exceptional cases
> where there was a problem for existing users. Your request, by contrast,
> is exactly the sort of case that maintainers are trying to avoid -- it
> will introduce change with no gain and the potential of breakage for the
> vast majority of users.
> 
> If you want to deal with  deployments pre and post removal of the
> Authorization support that you currently rely on I suggest you consider
> doing that by using a multi-release implementation and package it using
> the multi-release jar format. If you don't like the idea of
> multi-release jars you can still implement a standard jar format
> solution using a provider model. However, you will still need to build
> the alternative provider jars using the relevant JDK releases so that
> different providers can rely on different JDK capabilities..

Technically, you may not need several JDKs because you can ask javac to behave as if it was compiling like a previous JDK using the option "--release" (this option is also available with Maven and Gradle).
I believe that compiling as the release 8 will be supported up to Java 23.

> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill

regards,
R?mi

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jun 23 12:10:54 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 23 Jun 2021 12:10:54 GMT
Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v5]
In-Reply-To: 
References: 
Message-ID: 

> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented reviw comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4432/files
  - new: https://git.openjdk.java.net/jdk/pull/4432/files/295c2a56..4748d36b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4432&range=03-04

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4432.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4432/head:pull/4432

PR: https://git.openjdk.java.net/jdk/pull/4432

From michaelm at openjdk.java.net  Wed Jun 23 14:30:29 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 23 Jun 2021 14:30:29 GMT
Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 12:10:54 GMT, Mahendra Chhipa  wrote:

>> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented reviw comments.

Marked as reviewed by michaelm (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4432

From dfuchs at openjdk.java.net  Wed Jun 23 14:55:36 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 23 Jun 2021 14:55:36 GMT
Subject: RFR: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 12:10:54 GMT, Mahendra Chhipa  wrote:

>> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented reviw comments.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4432

From github.com+34924738+mahendrachhipa at openjdk.java.net  Wed Jun 23 15:22:36 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 23 Jun 2021 15:22:36 GMT
Subject: Integrated: JDK-8268464 : Remove dependancy of TestHttpsServer,
 HttpTransaction,
 HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Jun 2021 14:42:23 GMT, Mahendra Chhipa  wrote:

> ?HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests

This pull request has now been integrated.

Changeset: 7621fa37
Author:    Mahendra Chhipa 
Committer: Michael McMahon 
URL:       https://git.openjdk.java.net/jdk/commit/7621fa37efb2739b953da1cda87dca4762b5bd0c
Stats:     1729 lines in 7 files changed: 137 ins; 1506 del; 86 mod

8268464: Remove dependancy of TestHttpsServer, HttpTransaction, HttpCallback from open/test/jdk/sun/net/www/protocol/https/ tests

Reviewed-by: dfuchs, michaelm

-------------

PR: https://git.openjdk.java.net/jdk/pull/4432

From ascarpino at openjdk.java.net  Wed Jun 23 16:27:31 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 23 Jun 2021 16:27:31 GMT
Subject: [jdk17] RFR: 8269218: GaloisCounterMode.overlapDetection misses
 the JDK-8263436 fix again
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 08:10:40 GMT, Aleksey Shipilev  wrote:

> SonarCloud again complains about GaloisCounterMode.overlapDetection, in the similar way JDK-8263436 did. I think JDK-8255557 accidentally reintroduced the old code.
> 
> The tangential question if JDK-8255557 reverted anything else.
> 
> Additional testing:
>  - [x] `jdk_security` passes

Yes, that got let back in after a merge

-------------

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/124

From ascarpino at openjdk.java.net  Wed Jun 23 16:29:28 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 23 Jun 2021 16:29:28 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 08:16:42 GMT, Dongbo He  wrote:

>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
>> 
>> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
>> 
>> Benchmark results after patch:
>> 
>> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
>> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
>> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
>> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
>> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
>> 
>> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>> 
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
>> Before patch:
>> 
>> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
>> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> After patch:
>> 
>> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
>> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
>> 
>> 
>> Testing: tier1, tier2
>
> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace HashSet with TreeSet

Marked as reviewed by ascarpino (Reviewer).

test/micro/org/openjdk/bench/java/security/AlgorithmConstraintsPermits.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved.

I'm verifying if this copyright is ok or if it needs to be changed. Please don't integrate until I hear back from others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From ascarpino at openjdk.java.net  Wed Jun 23 16:29:29 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 23 Jun 2021 16:29:29 GMT
Subject: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 18 Jun 2021 21:27:41 GMT, Anthony Scarpino  wrote:

>> Dongbo He has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace HashSet with TreeSet
>
> test/micro/org/openjdk/bench/java/security/AlgorithmConstraintsPermits.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, Huawei Technologies Co., Ltd. All rights reserved.
> 
> I'm verifying if this copyright is ok or if it needs to be changed. Please don't integrate until I hear back from others.

This appears to be ok with the powers a be

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From valeriep at openjdk.java.net  Wed Jun 23 16:52:35 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 23 Jun 2021 16:52:35 GMT
Subject: RFR: 8269216: Useless initialization in
 com/sun/crypto/provider/PBES2Parameters.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 07:38:37 GMT, Aleksey Shipilev  wrote:

> SonarCloud reports:
> "Remove or correct this useless self-assignment."
> 
> 
>         if (cipherAlgo.equals("AES")) {
>             this.keysize = keysize; // <---- here
>             switch (keysize) {
>             case 128:
>                 cipherAlgo_OID = aes128CBC_OID;
> 
> 
> Seems to be here since initial addition in JDK-6383200.
> 
> Additional testing:
>  - [x] `jdk_security` pass

Changes look good. I also added the noreg-cleanup label to the bug record.

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4570

From github.com+44308314+jackh2000 at openjdk.java.net  Wed Jun 23 20:25:47 2021
From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein)
Date: Wed, 23 Jun 2021 20:25:47 GMT
Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS vectors
 in SunJSSE
Message-ID: 

8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE

-------------

Commit messages:
 - 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE
 - Changed ClientHello compression consumer loop to index by 1 instead of 2 (bytes vs shorts), and SupportedVersionsExt consumer get length to getInt8 vs getInt16
 - removed duplicate filtering in producer side constructors for AlpnExt, CertSignAlgsExt, ServNameExt, SigAlgsExt, SupGrpsExt, SupVersExt. Removed unnecessary intermediary array in consumer methods for SigAlgsExt, SupGrpsExt, SupVersExt. Improved byte array handling for compression methods in ClientHelloMessage. Overall code cleanup
 - reverted changes to produce method in AlpnExtension, CertSignAlgsExtension, SignatureAlgorithmsExtension, SupportedGroupsExtension, and SupportedVersionsExtension
 - added duplicate filtering to CertSignAlgsExtension, added first pass attempt at filtering compression methods to ClientHello. Added tests for duplicates in compression methods, CertSignAlgs, and ServerNames to test file.
 - added stream based duplicate fixes to SignatureAlgorithmExtension, SupportedGroupsExtension, and minor changes to previous fix on SupportedVersionsExtension. Added tests for SupGrp and SigAlg extensions to test file.
 - modified test file to check ALPNs, added duplicate check to SupportedGroupsSpec
 - formatting, adding ALPN check to test file
 - implemented IntStream duplicate clearing for ClientHello ciphersuites, SupportedVersionsExtensions, Stream duplicate clearing implementation for AlpnExtension
 - formatting fixes
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/51e8201e...83a887d1

Changes: https://git.openjdk.java.net/jdk/pull/4577/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8217408
  Stats: 660 lines in 9 files changed: 597 ins; 11 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4577/head:pull/4577

PR: https://git.openjdk.java.net/jdk/pull/4577

From github.com+44308314+jackh2000 at openjdk.java.net  Wed Jun 23 21:36:19 2021
From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein)
Date: Wed, 23 Jun 2021 21:36:19 GMT
Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS
 vectors in SunJSSE [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE

Jack Hartstein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge
 - 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE
 - Changed ClientHello compression consumer loop to index by 1 instead of 2 (bytes vs shorts), and SupportedVersionsExt consumer get length to getInt8 vs getInt16
 - removed duplicate filtering in producer side constructors for AlpnExt, CertSignAlgsExt, ServNameExt, SigAlgsExt, SupGrpsExt, SupVersExt. Removed unnecessary intermediary array in consumer methods for SigAlgsExt, SupGrpsExt, SupVersExt. Improved byte array handling for compression methods in ClientHelloMessage. Overall code cleanup
 - reverted changes to produce method in AlpnExtension, CertSignAlgsExtension, SignatureAlgorithmsExtension, SupportedGroupsExtension, and SupportedVersionsExtension
 - added duplicate filtering to CertSignAlgsExtension, added first pass attempt at filtering compression methods to ClientHello. Added tests for duplicates in compression methods, CertSignAlgs, and ServerNames to test file.
 - added stream based duplicate fixes to SignatureAlgorithmExtension, SupportedGroupsExtension, and minor changes to previous fix on SupportedVersionsExtension. Added tests for SupGrp and SigAlg extensions to test file.
 - modified test file to check ALPNs, added duplicate check to SupportedGroupsSpec
 - formatting, adding ALPN check to test file
 - implemented IntStream duplicate clearing for ClientHello ciphersuites, SupportedVersionsExtensions, Stream duplicate clearing implementation for AlpnExtension
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/0288a894...0f40ea13

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4577/files
  - new: https://git.openjdk.java.net/jdk/pull/4577/files/83a887d1..0f40ea13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=00-01

  Stats: 48739 lines in 935 files changed: 31127 ins; 13806 del; 3806 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4577/head:pull/4577

PR: https://git.openjdk.java.net/jdk/pull/4577

From github.com+44308314+jackh2000 at openjdk.java.net  Wed Jun 23 21:41:51 2021
From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein)
Date: Wed, 23 Jun 2021 21:41:51 GMT
Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS
 vectors in SunJSSE [v3]
In-Reply-To: 
References: 
Message-ID: 

> 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE

Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision:

  Delete CheckDuplicateCipherSuites.java
  
  Does not test final implementation.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4577/files
  - new: https://git.openjdk.java.net/jdk/pull/4577/files/0f40ea13..905c5963

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=01-02

  Stats: 580 lines in 1 file changed: 0 ins; 580 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4577/head:pull/4577

PR: https://git.openjdk.java.net/jdk/pull/4577

From github.com+44308314+jackh2000 at openjdk.java.net  Wed Jun 23 22:08:55 2021
From: github.com+44308314+jackh2000 at openjdk.java.net (Jack Hartstein)
Date: Wed, 23 Jun 2021 22:08:55 GMT
Subject: RFR: 8217408: Reduce storage of duplicate identifiers in TLS
 vectors in SunJSSE [v4]
In-Reply-To: 
References: 
Message-ID: <5QWKeJcqM8Xe2-IIWY1XULXvcp_y-1TTWTcUZIZmCOI=.2509e392-f2ff-49ad-ab64-35b137c288fc@github.com>

> 8217408: Reduce storage of duplicate identifiers in TLS vectors in SunJSSE

Jack Hartstein has updated the pull request incrementally with one additional commit since the last revision:

  import cleanup in SupportedGroupsExtension

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4577/files
  - new: https://git.openjdk.java.net/jdk/pull/4577/files/905c5963..4f84c7b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4577&range=02-03

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4577/head:pull/4577

PR: https://git.openjdk.java.net/jdk/pull/4577

From peter.firmstone at zeus.net.au  Thu Jun 24 00:18:31 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 10:18:31 +1000
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>
References: 
 <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
 <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>
Message-ID: 

Thanks Se?n,

A good explanation. :)

Solaris was a very good platform for exposing and debugging race 
conditions, of course we have very good static analysis now.

Regards,

Peter.

On 23/06/2021 5:10 pm, Se?n Coffey wrote:
> Thank for the feedback Peter. Comments inline.
>
> On 22/06/2021 22:40, Peter Firmstone wrote:
>> Was ever to run with SecurityManager?
> I found the issue while porting to jdk8u where Solaris uses a 
> configuration file with the SunPKCS11 Provider by default - We have 
> tests to register Providers while SecurityManager is in place. This 
> failed for SunPKCS11.
>>
>> When you see an AccessControlException, I'd recommend setting the 
>> following security debug property, so you can capture the 
>> ProtectionDomain that failed the access check: 
>> -Djava.security.debug=access:failure? Clearly there's a 
>> ProtectionDomain on the calling threads stack that doesn't have the 
>> necessary permission.? If you knew which one it was, you could just 
>> grant it java.lang.RuntimePermission "setContextClassLoader" 
>> permission in the policy file.
> Yes - that was one of my first actions. [1]. The jdk.crypto.cryptoki 
> ProtectionDomain lacks the permission and rightly so IMO. The default 
> policy doesn't grant "setContextClassLoader" permission to any JDK 
> module. It's not required when we use InnocuousThread.
>>
>> In NativeResourceCleaner the original constructor is setting the 
>> Context ClassLoader of the calling thread to null, prior to calling 
>> the Thread superclass constructor, so that both the calling thread 
>> and new thread will nave a null context ClassLoader.? In your new 
>> implementation, you are asserting the context class loader of the 
>> created thread is null, without setting the context ClassLoader of 
>> the original calling thread, is that the intended behaviour?
>>
>> Alternatively you could set the context ClassLoader of the calling 
>> thread to null using a PrivilegedAction, prior to creating the new 
>> thread and restore it?
> Use of InnocuousThread is made in various JDK classes for similar 
> purpose where daemon threads need to be run with limited privilege. 
> Similar use seen in networking and ldap classes.
>
>>
>> If the original intent was to set the context ClassLoader of the new 
>> thread to null, then why not just do that, rather than use an assertion?
> InnocuousThread sets this to null. The assert is just a belt and 
> braces approach which is a useful check during test runs. Again, 
> similar approach done in other JDK libraries.
>>
>> If assertions are not enabled it may run with a non null context 
>> ClassLoader??? What are the consequences?? It appears to me, the fix 
>> has created a bigger problem, rather than fixed it.? Just my 2 cents.
>
> see above. We shouldn't have an issue. A non-null classloader would 
> lead to classloader memory leak in some environments.
>
> regards,
> Sean.
>
>>
>> We use SecurityManager by default following principles of least 
>> privilege (only the code paths we need to execute), and the original 
>> reported bug is a non problem for us, we would capture the missing 
>> permission and grant it, these are permission grants for Java 16:
>>
>> grant codebase "jrt:/jdk.crypto.cryptoki"
>> {
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util";
>> };
>>
>> grant codebase "jrt:/jdk.crypto.ec"
>> {
>> ??? permission java.security.SecurityPermission 
>> "putProviderProperty.SunEC";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.jca";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.pkcs";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util.math";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util.math.intpoly";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.x509";
>> };
>>
>> Good call making NativeResourceCleaner implement Runnable instead of 
>> extending Thread though.
>
>
> [1]
>
> access: domain that failed ProtectionDomain (jrt:/jdk.crypto.cryptoki 
> )
> ?jdk.internal.loader.ClassLoaders$PlatformClassLoader at 5433274e
> ?
> ?java.security.Permissions at 7006c658 (
> ?("java.io.FilePermission" "<>" "read")
> ?("java.net.SocketPermission" "localhost:0" "listen,resolve")
> ?("java.security.SecurityPermission" "clearProviderProperties.*")
> ?("java.security.SecurityPermission" 
> "getProperty.auth.login.defaultCallbackHandler")
> ?("java.security.SecurityPermission" "putProviderProperty.*")
> ?("java.security.SecurityPermission" "authProvider.*")
> ?("java.security.SecurityPermission" "removeProviderProperty.*")
> ?("java.util.PropertyPermission" "java.specification.version" "read")
> ?("java.util.PropertyPermission" "java.vm.vendor" "read")
> ?("java.util.PropertyPermission" "path.separator" "read")
> ?("java.util.PropertyPermission" "os.version" "read")
> ?("java.util.PropertyPermission" "java.vendor.url" "read")
> ?("java.util.PropertyPermission" "java.vm.name" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.version" "read")
> ?("java.util.PropertyPermission" "os.name" "read")
> ?("java.util.PropertyPermission" 
> "sun.security.pkcs11.allowSingleThreadedModules" "read")
> ?("java.util.PropertyPermission" 
> "sun.security.pkcs11.disableKeyExtraction" "read")
> ?("java.util.PropertyPermission" "java.version" "read")
> ?("java.util.PropertyPermission" "os.arch" "read")
> ?("java.util.PropertyPermission" "java.specification.vendor" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.name" "read")
> ?("java.util.PropertyPermission" "file.separator" "read")
> ?("java.util.PropertyPermission" "line.separator" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.vendor" "read")
> ?("java.util.PropertyPermission" "java.specification.name" "read")
> ?("java.util.PropertyPermission" "java.vendor" "read")
> ?("java.util.PropertyPermission" "java.vm.version" "read")
> ?("java.util.PropertyPermission" "jdk.crypto.KeyAgreement.legacyKDF" 
> "read")
> ?("java.util.PropertyPermission" "java.class.version" "read")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")
> ?("java.lang.RuntimePermission" "accessClassInPackage.sun.security.*")
> ?("java.lang.RuntimePermission" 
> "accessClassInPackage.com.sun.crypto.provider")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")
> ?("java.lang.RuntimePermission" 
> "accessClassInPackage.com.sun.java.swing.plaf.*")
> ?("java.lang.RuntimePermission" "accessSystemModules")
> ?("java.lang.RuntimePermission" "accessClassInPackage.sun.nio.ch")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")
> ?("java.lang.RuntimePermission" "loadLibrary.j2pkcs11")
> )
>
> Exception in thread "main" java.security.ProviderException: 
> Initialization failed
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:386)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:117)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:114)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:114)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:257)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:248)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:226)
> ??????? at 
> java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:317)
> ??????? at 
> java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:334)
> ??????? at 
> java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:175)
> ??????? at 
> java.base/java.security.Security.getProviders(Security.java:458)
> ??????? at DefaultPKCS11.main(DefaultPKCS11.java:13)
> Caused by: java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "setContextClassLoader")
> ??????? at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485)
> ??????? at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
> ??????? at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
> ??????? at 
> java.base/java.lang.Thread.setContextClassLoader(Thread.java:1525)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$NativeResourceCleaner.(SunPKCS11.java:982)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:1193)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:377)
> ??????? ... 14 more
>

From peter.firmstone at zeus.net.au  Thu Jun 24 01:03:12 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 11:03:12 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <34cff817-a624-9e4b-60f9-d831f6aa448d@oracle.com>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <34cff817-a624-9e4b-60f9-d831f6aa448d@oracle.com>
Message-ID: 

Hi Alan,

It is important to understand the reason for the inherited 
AccessControlContext, in order to consider alternatives.

The motivation for inherited context, was simply to avoid privilege 
escalation, prior to Executors.

Whenever a permission check is made, the DomainCombiner, combines the 
inherited context, with the thread's current context, in case there are 
any less privileged domains in the inherited context.

But there is an alternative, higher performance option, that avoids 
privilege escalation for executors as well.

A ProtectionDomain with a null CodeSource has AllPermission, while a 
ProtectionDomain that contains a CodeSource with a null URL has only the 
Permission's given to it when created, or to blanket grant statements in 
policy files.

Rather than inherit context from the calling thread, all threads upon 
creation could be initialized with one shared immutable unprivileged 
AccessControlContext, containing a single element array, with a 
ProtectionDomain, containing a CodeSource with a null URL.

Code cannot assume that calling code is privileged, hence the 
AccessController.doPrivileged method, so an unprivileged context could 
replace system threads inherited context as well.?? There will be some 
minor impacts in older code where developers create a system thread for 
cleanup tasks or other things, but nothing that couldn't be worked 
around, until it can be addressed properly. This is an existential 
moment for Java authorization, as a developer with extensive use of Java 
authorization, I would most certainly welcome this change.

This would be a simplification that enhances security.?? This is far 
more preferable than an inherited AccessControlContext as it eliminates 
any risk that Executor tasks present, where domains in the context that 
creates Callable or Runnable, may not be in the inherited thread 
context.? JEP 411, presents an opportunity to address it.

A use case:

I would like to use virtual threads, in executors, to make blocking 
secure network connections, so I don't consume too many system 
threads.?? When network failures occur, the number of threads created 
increase significantly, as blocked threads waiting on network are no 
longer available to the executor.

All our executor tasks are wrapped, with AccessControlContext, using 
Executors::callable(PrivilegedAction), we do this to capture the 
Subject, and to grant SocketPermission (to Principles and CodeSource) to 
make secure network calls from one node to another.? Across the network, 
the user Subject's Principals are preserved, from the thread in the 
client to the thread in the server during authentication.? 
DeserializationPermission is granted to the user Principal's and 
CodeSource in the server, so that the code cannot perform 
deserialization (not to be confused with Java serialization) without an 
authenticated user.?? The authenticated user represents the domain from 
which data to be deserialized originates.

Personally I would like to see AccessController and AccessControlContext 
retained, and all threads modified to be initialized with a single 
shared immutable unprivileged AccessControlContext, rather than an 
inherited AccessControlContext in system threads and virtual threads 
that do not support any permissions at all.

-- 
Regards,
  
Peter Firmstone

On 23/06/2021 4:34 pm, Alan Bateman wrote:
> On 23/06/2021 04:02, Peter Firmstone wrote:
>>
>> Note: I'm not sure how to replace an inherited AccessControlContext 
>> (with a new implementation based on StackWalker functionality) at 
>> thread creation time, as it must be created when threads are created, 
>> possibly by using ThreadFactory everywhere, but this doesn't cover 
>> all threads. How to cater for virtual threads?
>>
> I don't think the inherited AccessControlContext is widely known or 
> even clearly specified. In any case, virtual threads do not want to be 
> burdened with this field. For now they are specified to not support 
> any permissions. The FJ common pool is another example, the threads 
> don't have any permissions either (see FJP class description has more 
> on that).
>
> -Alan


From peter.firmstone at zeus.net.au  Thu Jun 24 01:50:25 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 11:50:25 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <34cff817-a624-9e4b-60f9-d831f6aa448d@oracle.com>
 
Message-ID: <112a6b52-811f-0f57-6f21-925f9ec0f334@zeus.net.au>

Clarification inline below.

On 24/06/2021 11:03 am, Peter Firmstone wrote:
> Hi Alan,
>
> It is important to understand the reason for the inherited 
> AccessControlContext, in order to consider alternatives.
>
> The motivation for inherited context, was simply to avoid privilege 
> escalation, prior to Executors.
>
> Whenever a permission check is made, the DomainCombiner, combines the 
> inherited context, with the thread's current context, in case there 
> are any less privileged domains in the inherited context.
>
> But there is an alternative, higher performance option, that avoids 
> privilege escalation for executors as well.
>
> A ProtectionDomain with a null CodeSource has AllPermission, while a 
> ProtectionDomain that contains a CodeSource with a null URL has only 
> the Permission's given to it when created, or to blanket grant 
> statements in policy files.
>
> Rather than inherit context from the calling thread, all threads upon 
> creation could be initialized with one shared immutable unprivileged 
> AccessControlContext, containing a single element array, with a 
> ProtectionDomain, containing a CodeSource with a null URL.
>
> Code cannot assume that calling code is privileged, hence the 
> AccessController.doPrivileged method, so an unprivileged context could 
> replace system threads inherited context as well.?? There will be some 
> minor impacts in older code where developers create a system thread 
> for cleanup tasks or other things, but nothing that couldn't be worked 
> around, until it can be addressed properly. This is an existential 
> moment for Java authorization, as a developer with extensive use of 
> Java authorization, I would most certainly welcome this change.
>
> This would be a simplification that enhances security.?? This is far 
> more preferable than an inherited AccessControlContext as it 
> eliminates any risk that Executor tasks present, where domains in the 
> context that creates Callable or Runnable, may not be in the inherited 
> thread context.? JEP 411, presents an opportunity to address it.
>
> A use case:
>
> I would like to use virtual threads, in executors, to make blocking 
> secure network connections, so I don't consume too many system 
> threads.?? When network failures occur, the number of threads created 
> increase significantly, as blocked threads waiting on network are no 
> longer available to the executor.
>
> All our executor tasks are wrapped, with AccessControlContext, using 
> Executors::callable(PrivilegedAction), we do this to capture the 
> Subject, and to grant SocketPermission (to Principles and CodeSource) 
> to make secure network calls from one node to another.? Across the 
> network, the user Subject's Principals are preserved, from the thread 
> in the client to the thread in the server during authentication.? 
> DeserializationPermission is granted to the user Principal's and 
> CodeSource in the server, so that the code cannot perform 
> deserialization (not to be confused with Java serialization) without 
> an authenticated user.?? The authenticated user represents the domain 
> from which data to be deserialized originates.
>
> Personally I would like to see AccessController and 
> AccessControlContext retained, and all threads modified to be 
> initialized with a single shared immutable unprivileged 
> AccessControlContext, rather than an inherited AccessControlContext in 
> system threads and virtual threads that do not support any permissions 
> at all.
All threads except bootstrap threads in the JVM, obviously they would 
need to be privileged.

-- 
Regards,
  
Peter Firmstone


From peter.firmstone at zeus.net.au  Thu Jun 24 02:24:10 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 12:24:10 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
Message-ID: <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>

Thanks Andrew,

For the simple case, of replacing the SecurityManager stack walk, one 
could use reflection.

Thank you for also confirming that is not possible (or at least very 
unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK code 
to use a provider mechanism, to intercept permission checks, so custom 
authentication layers can be implemented, this could be accepted in 
future versions of Java, but not existing. As it is said, there is no 
harm in asking.

The advantages of being able to address issues with Permission 
implementations and customise, for example,? by providing a replacement 
for SocketPermission, that doesn't call DNS, and allows wild cards for 
subnets, would be significant for the simplification of authorization.

So developers might hope to be able to implement a significantly 
improved authorization layer for a future version of Java, provided we 
have some basic things like JVM hooks for access checks.

-- 
Regards,
  
Peter Firmstone

On 23/06/2021 7:19 pm, Andrew Dinn wrote:
> OHi Peter,
>
> n 23/06/2021 04:02, Peter Firmstone wrote:
>> ?1. StackWalker - Can stack walker be back ported to Java 8?
>
> The right place to ask about this is the jdk8u updates project list. 
> However, you probably don't need to ask there because the answer is 
> almost certainly going to be a very loud no.
>
> JDK8u is in long term maintenance mode. The goal of the updates 
> project for that release is to fix security issues and critical bugs 
> *and nothing else* so that existing deployments remain stable as far 
> as possible. Except when required to meet those goals backporting of 
> new functionality is done only under exceptional circumstances.
>
> The only recent examples of new function backports that I am aware of 
> have involved merging up functionality from downstream releases in 
> order to 1) unify the platform and 2) enable downstream contributors 
> to help to maintain a single, standard release i.e. highly exceptional 
> cases where there was a problem for existing users. Your request, by 
> contrast, is exactly the sort of case that maintainers are trying to 
> avoid -- it will introduce change with no gain and the potential of 
> breakage for the vast majority of users.
>
> If you want to deal with? deployments pre and post removal of the 
> Authorization support that you currently rely on I suggest you 
> consider doing that by using a multi-release implementation and 
> package it using the multi-release jar format. If you don't like the 
> idea of multi-release jars you can still implement a standard jar 
> format solution using a provider model. However, you will still need 
> to build the alternative provider jars using the relevant JDK releases 
> so that different providers can rely on different JDK capabilities..
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>

From peter.firmstone at zeus.net.au  Thu Jun 24 06:29:26 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 16:29:26 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Thanks Remi,

We're still building on 8, for CORBA-IIOP stubs, but will look into this 
when we've found an alternative IIOP stub compiler.

-- 
Regards,
  
Peter

On 23/06/2021 8:02 pm, Remi Forax wrote:
> ----- Mail original -----
>> De: "Andrew Dinn" 
>> ?: "Peter Firmstone" , "discuss" 
>> Cc: "security-dev" 
>> Envoy?: Mercredi 23 Juin 2021 11:19:42
>> Objet: Re: Authorization layer API and low level access checks.
>> OHi Peter,
>>
>> n 23/06/2021 04:02, Peter Firmstone wrote:
>>>   1. StackWalker - Can stack walker be back ported to Java 8?
>> The right place to ask about this is the jdk8u updates project list.
>> However, you probably don't need to ask there because the answer is
>> almost certainly going to be a very loud no.
>>
>> JDK8u is in long term maintenance mode. The goal of the updates project
>> for that release is to fix security issues and critical bugs *and
>> nothing else* so that existing deployments remain stable as far as
>> possible. Except when required to meet those goals backporting of new
>> functionality is done only under exceptional circumstances.
>>
>> The only recent examples of new function backports that I am aware of
>> have involved merging up functionality from downstream releases in order
>> to 1) unify the platform and 2) enable downstream contributors to help
>> to maintain a single, standard release i.e. highly exceptional cases
>> where there was a problem for existing users. Your request, by contrast,
>> is exactly the sort of case that maintainers are trying to avoid -- it
>> will introduce change with no gain and the potential of breakage for the
>> vast majority of users.
>>
>> If you want to deal with  deployments pre and post removal of the
>> Authorization support that you currently rely on I suggest you consider
>> doing that by using a multi-release implementation and package it using
>> the multi-release jar format. If you don't like the idea of
>> multi-release jars you can still implement a standard jar format
>> solution using a provider model. However, you will still need to build
>> the alternative provider jars using the relevant JDK releases so that
>> different providers can rely on different JDK capabilities..
> Technically, you may not need several JDKs because you can ask javac to behave as if it was compiling like a previous JDK using the option "--release" (this option is also available with Maven and Gradle).
> I believe that compiling as the release 8 will be supported up to Java 23.
>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Red Hat Distinguished Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill
> regards,
> R?mi


From shade at openjdk.java.net  Thu Jun 24 06:39:33 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 06:39:33 GMT
Subject: Integrated: 8269216: Useless initialization in
 com/sun/crypto/provider/PBES2Parameters.java
In-Reply-To: 
References: 
Message-ID: <-1ZwN8tQZy7hGVqID4rfPyKBj4oGqUjpxUr1kkuAS_c=.ef626556-1777-400f-927e-e949207a4fe6@github.com>

On Wed, 23 Jun 2021 07:38:37 GMT, Aleksey Shipilev  wrote:

> SonarCloud reports:
> "Remove or correct this useless self-assignment."
> 
> 
>         if (cipherAlgo.equals("AES")) {
>             this.keysize = keysize; // <---- here
>             switch (keysize) {
>             case 128:
>                 cipherAlgo_OID = aes128CBC_OID;
> 
> 
> Seems to be here since initial addition in JDK-6383200.
> 
> Additional testing:
>  - [x] `jdk_security` pass

This pull request has now been integrated.

Changeset: e515873f
Author:    Aleksey Shipilev 
URL:       https://git.openjdk.java.net/jdk/commit/e515873f887ce4071ab4878a4bafca8eea67afea
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8269216: Useless initialization in com/sun/crypto/provider/PBES2Parameters.java

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/4570

From shade at openjdk.java.net  Thu Jun 24 06:40:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 06:40:36 GMT
Subject: [jdk17] Integrated: 8269218: GaloisCounterMode.overlapDetection
 misses the JDK-8263436 fix again
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 08:10:40 GMT, Aleksey Shipilev  wrote:

> SonarCloud again complains about GaloisCounterMode.overlapDetection, in the similar way JDK-8263436 did. I think JDK-8255557 accidentally reintroduced the old code.
> 
> The tangential question if JDK-8255557 reverted anything else.
> 
> Additional testing:
>  - [x] `jdk_security` passes

This pull request has now been integrated.

Changeset: 3fb28d30
Author:    Aleksey Shipilev 
URL:       https://git.openjdk.java.net/jdk17/commit/3fb28d3074dfb33d8b7e489c9a55f52d4e0b954b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269218: GaloisCounterMode.overlapDetection misses the JDK-8263436 fix again

Reviewed-by: ascarpino

-------------

PR: https://git.openjdk.java.net/jdk17/pull/124

From peter.firmstone at zeus.net.au  Fri Jun 25 08:01:41 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 25 Jun 2021 18:01:41 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <112a6b52-811f-0f57-6f21-925f9ec0f334@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <34cff817-a624-9e4b-60f9-d831f6aa448d@oracle.com>
 
 <112a6b52-811f-0f57-6f21-925f9ec0f334@zeus.net.au>
Message-ID: <6523b186-ea7d-6bc8-f8e3-eb8930c44ab8@zeus.net.au>

The more I think about it, allowing Thread to use a singleton immutable 
unprivileged AccessControlContext instead of the inherited context is 
the right thing to do, it achieves the original goal of avoiding 
privilege escalation, limits the the size of the context that needs to 
be checked and allows simple support for virtual threads.?? The 
AccessController.doPrivileged method allows code to make privileged actions.

The way to implement it, for compatible transition would be:

 1. Implement it first in virtual threads.
 2. When stubbing out SecurityManager, change system threads to also use
    the singleton unprivileged context, instead of the inherited
    context, which must be calculated for each thread at creation time.
 3. Alternative option to item 2, is to make generic grants in policy
    files for affected threads (which inherited privileged context).

I recently generated some principle of least privilege policy files for 
tests:

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuretest.policy.new

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new

For the generation of these policy files, a properties file was 
provided, to populate the policy files with properties, to replace local 
and platform specific paths and file names.

Note how many permissions are granted to code and principal's. This 
ensures that other code cannot use the principal's thread for privileged 
escalation, and code cannot perform certain tasks without a logged in 
Subject.

This is how we prevent deserialization (not Java deserialization) of 
untrusted data in our case, we have DeserializationPermission. So not 
only do we ensure there's a logged in Subject, that's providing the 
data, but we are also restricting the code that is allowed to parse 
it.?? Our deserialization uses constructors to validate invariants but, 
we still avoid using it to process untrusted data.

One pain point is SocketPermission, which doesn't allow IP Address 
subnet wild cards, hence the use of unlimited IP Address wild cards.? 
It's generally preferable not to use domain names in SocketPermission, 
due to blocking DNS calls, personally I'd like to replace that with 
RFC3986 normalization.

Note that the JGDMS SecurityManager and Policy implementations are 
performant and scalable, all hotspots in JGDMS are JDK native methods 
(Socket's basically).?? The use of virtual threads, would provide a 
significant scalability improvement for JGDMS.

If we could get the proposed GuardBuilder & GuardBuilderSpi happening 
(so developers are freed from the current Permission implementations) as 
well as the proposed changes to thread AccessControlContext below, we 
would have the best authorization layer available.

We can still stub out SecurityManager and remove the Policy and 
Permission implementations, to reduce the maintenance burden for OpenJDK 
developers.

The reality is, the overall result for us, will be much better, if we 
can retain AccessController and AccessControlContext for the following 
reasons:

 1. Allowing grants to be made to code and principals, to prevent
    parsing of untrusted data, while limiting the scope of those grants
    (refer to 3).
 2. Preserving current JAAS functionality, to authenticate and secure
    connections.
 3. Limiting or preventing viral authorization checks from spreading to
    an excessive number of ProtectionDomains (viral Permissions).?? For
    the libraries and JVM code that use doPrivileged will continue to
    function using common API's.
 4. To enable developers to implement an authorization layer. While this
    may be a small proportion of overall projects, the projects that do
    are usually significant.

We don't require SecurityManager, a Policy or Permission implementations 
to implement an authorization layer and these components are the 
majority of the maintenance burden for OpenJDK, as far as I can tell at 
least.

Basic components required for effective authorization layer implementations:

 1. Guard, GuardBuilder and GuardBuilderSpi (or equivalent).
 2. AccessController, AccessControlContext and DomainCombiner (These are
    difficult to re-implement in a Java version compatible manner, and
    re-implementations would not have the benefits of JDK support for
    AccessController.doPrivileged, or Thread context, which limits viral
    authorization checks).
 3. ProtectionDomain, CodeSource and Principal
 4. JAAS, Subject and LoginModule.
 5. GSS-API/Kerberos, JCA, JCE and JSSE.

-- 
Regards,
  
Peter Firmstone

On 24/06/2021 11:50 am, Peter Firmstone wrote:
> Clarification inline below.
>
> On 24/06/2021 11:03 am, Peter Firmstone wrote:
>> Hi Alan,
>>
>> It is important to understand the reason for the inherited 
>> AccessControlContext, in order to consider alternatives.
>>
>> The motivation for inherited context, was simply to avoid privilege 
>> escalation, prior to Executors.
>>
>> Whenever a permission check is made, the DomainCombiner, combines the 
>> inherited context, with the thread's current context, in case there 
>> are any less privileged domains in the inherited context.
>>
>> But there is an alternative, higher performance option, that avoids 
>> privilege escalation for executors as well.
>>
>> A ProtectionDomain with a null CodeSource has AllPermission, while a 
>> ProtectionDomain that contains a CodeSource with a null URL has only 
>> the Permission's given to it when created, or to blanket grant 
>> statements in policy files.
>>
>> Rather than inherit context from the calling thread, all threads upon 
>> creation could be initialized with one shared immutable unprivileged 
>> AccessControlContext, containing a single element array, with a 
>> ProtectionDomain, containing a CodeSource with a null URL.
>>
>> Code cannot assume that calling code is privileged, hence the 
>> AccessController.doPrivileged method, so an unprivileged context 
>> could replace system threads inherited context as well.?? There will 
>> be some minor impacts in older code where developers create a system 
>> thread for cleanup tasks or other things, but nothing that couldn't 
>> be worked around, until it can be addressed properly. This is an 
>> existential moment for Java authorization, as a developer with 
>> extensive use of Java authorization, I would most certainly welcome 
>> this change.
>>
>> This would be a simplification that enhances security.?? This is far 
>> more preferable than an inherited AccessControlContext as it 
>> eliminates any risk that Executor tasks present, where domains in the 
>> context that creates Callable or Runnable, may not be in the 
>> inherited thread context.? JEP 411, presents an opportunity to 
>> address it.
>>
>> A use case:
>>
>> I would like to use virtual threads, in executors, to make blocking 
>> secure network connections, so I don't consume too many system 
>> threads.?? When network failures occur, the number of threads created 
>> increase significantly, as blocked threads waiting on network are no 
>> longer available to the executor.
>>
>> All our executor tasks are wrapped, with AccessControlContext, using 
>> Executors::callable(PrivilegedAction), we do this to capture the 
>> Subject, and to grant SocketPermission (to Principles and CodeSource) 
>> to make secure network calls from one node to another.? Across the 
>> network, the user Subject's Principals are preserved, from the thread 
>> in the client to the thread in the server during authentication. 
>> DeserializationPermission is granted to the user Principal's and 
>> CodeSource in the server, so that the code cannot perform 
>> deserialization (not to be confused with Java serialization) without 
>> an authenticated user.?? The authenticated user represents the domain 
>> from which data to be deserialized originates.
>>
>> Personally I would like to see AccessController and 
>> AccessControlContext retained, and all threads modified to be 
>> initialized with a single shared immutable unprivileged 
>> AccessControlContext, rather than an inherited AccessControlContext 
>> in system threads and virtual threads that do not support any 
>> permissions at all.
> All threads except bootstrap threads in the JVM, obviously they would 
> need to be privileged.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pconcannon at openjdk.java.net  Fri Jun 25 15:06:41 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 15:06:41 GMT
Subject: RFR: 8268967: Update java.security to use switch expressions [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.security` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8268967
 - Merge remote-tracking branch 'origin/master' into JDK-8268967
 - 8268967: Update java.security to use switch expressions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4553/files
  - new: https://git.openjdk.java.net/jdk/pull/4553/files/f94b850d..917d4d26

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4553&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4553&range=00-01

  Stats: 12925 lines in 361 files changed: 3731 ins; 8374 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4553.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4553/head:pull/4553

PR: https://git.openjdk.java.net/jdk/pull/4553

From pconcannon at openjdk.java.net  Fri Jun 25 16:38:08 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 16:38:08 GMT
Subject: Integrated: 8268967: Update java.security to use switch expressions
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 10:56:00 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.security` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 35c47020
Author:    Patrick Concannon 
URL:       https://git.openjdk.java.net/jdk/commit/35c4702055ccf11975391df01f62a70e06ecae83
Stats:     107 lines in 3 files changed: 0 ins; 61 del; 46 mod

8268967: Update java.security to use switch expressions

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4553

From joe.darcy at oracle.com  Fri Jun 25 19:57:43 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 25 Jun 2021 12:57:43 -0700
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: <1af67d23-10a2-915a-8623-a38190fea6b3@oracle.com>

On 6/21/2021 2:02 PM, Paul Sandoz wrote:
> On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang  wrote:
>
>>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    more replacement 2
> All the updates to the check* methods look ok (requires some careful looking!).
>
> I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

Generally, the JDK does not have the text of exception message as a 
supported interface meant to be relied on by users. This doesn't stop 
developers from occasionally parsing those messages, but that is usually 
a sign of a missing API which we try to rectify more directly.

HTH,

-Joe


From weijun at openjdk.java.net  Fri Jun 25 20:11:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 20:11:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
Message-ID: 

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

-------------

Commit messages:
 - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Changes: https://git.openjdk.java.net/jdk17/pull/152/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 289 lines in 21 files changed: 161 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From lancea at openjdk.java.net  Fri Jun 25 20:27:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 25 Jun 2021 20:27:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Changes look good Max

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From valeriep at openjdk.java.net  Fri Jun 25 22:31:04 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 22:31:04 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

src/java.base/share/lib/security/default.policy line 131:

> 129:     permission java.lang.RuntimePermission "accessClassInPackage.com.sun.crypto.provider";
> 130:     permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc";
> 131:     permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";

Can we just do necessary changes? I noticed that this file seems to have mixed style, i.e. some lines are longer than 80 chars and some break into 2 lines with length less than 80 chars. Since the whole file is mixed, maybe just do what must be changed.

src/java.base/share/lib/security/default.policy line 142:

> 140:     permission java.security.SecurityPermission "clearProviderProperties.*";
> 141:     permission java.security.SecurityPermission "removeProviderProperty.*";
> 142:     permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";

Same "avoid unnecessary changes" comment here.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:

> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
> 951:             Thread t = InnocuousThread.newSystemThread(
> 952:                     "Poller " + getName(),

nit: "Poller " -> "Poller-" (like before)?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 956:

> 954:             assert t.getContextClassLoader() == null;
> 955:             t.setDaemon(true);
> 956:             t.setPriority(Thread.MIN_PRIORITY);

nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1033:

> 1031:         }
> 1032:         cleaner = new NativeResourceCleaner();
> 1033:         AccessController.doPrivileged((PrivilegedAction) () -> {

It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1039:

> 1037:             assert t.getContextClassLoader() == null;
> 1038:             t.setDaemon(true);
> 1039:             t.setPriority(Thread.MIN_PRIORITY);

nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1212:

> 1210: 
> 1211:         this.token = token;
> 1212:         if (cleaner == null) {

This check seems duplicate to the one in createCleaner() call.

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 56:

> 54:                 System.out.println("No NSS config found. Skipping.");
> 55:                 return;
> 56:             }

Move this if-check block of code up before the for-loop?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From valeriep at openjdk.java.net  Fri Jun 25 22:31:05 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 22:31:05 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <4qG15Dx-kJQ6q3hbn3iQ2ALOJpRbMg7YkWxBHGMLpxQ=.598d3a18-213f-4780-82f2-7d854a5c070b@github.com>

On Fri, 25 Jun 2021 19:39:22 GMT, Valerie Peng  wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move TokenPoller to Runnable
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:
> 
>> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
>> 951:             Thread t = InnocuousThread.newSystemThread(
>> 952:                     "Poller " + getName(),
> 
> nit: "Poller " -> "Poller-" (like before)?

It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From naoto at openjdk.java.net  Fri Jun 25 23:11:02 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 23:11:02 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From valeriep at openjdk.java.net  Fri Jun 25 23:37:06 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 23:37:06 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63:

> 61:             Policy.setPolicy(new SimplePolicy());
> 62:             System.setSecurityManager(new SecurityManager());
> 63:         }

Just curious, why split the loop into 2 and set the SecurityManager in between the two loops? Can't we just set the policy/security manager before the loop?

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 137:

> 135:             perms.add(new SecurityPermission("insertProvider.*"));
> 136:             perms.add(new SecurityPermission("removeProvider.*"));
> 137:         }

The test still pass without the following permission:

             perms.add(new RuntimePermission("accessClassInPackage.sun.*"));
             perms.add(new RuntimePermission("accessClassInPackage.sun.security.pkcs11.*"));
             perms.add(new SecurityPermission("clearProviderProperties.*"));

Remove them?

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 142:

> 140:         -Dtest.src=${TESTSRC} \
> 141:         -Dtest.classes=${TESTCLASSES} \
> 142:         -Djava.security.debug=${DEBUG} \

Save these java options and use it for both invocation? This way it's easier to tell that there is no difference among these two except for the extra argument.

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 143:

> 141:         -Dtest.classes=${TESTCLASSES} \
> 142:         -Djava.security.debug=${DEBUG} \
> 143:         MultipleLogins ${TESTSRC}${FS}MultipleLogins.policy || exit 11

There is no MultipleLogins.policy file. The test just uses the internal SimplePolicy object. Maybe just use a string like "useSimplePolicy".

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From weijun at openjdk.java.net  Fri Jun 25 23:40:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 23:40:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
Message-ID: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/d8b384df..774eb9da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From peter.firmstone at zeus.net.au  Sat Jun 26 02:58:48 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 12:58:48 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
Message-ID: <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au>

Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
    checks without SecurityManager or Policy. (Note GuardFactory should
    never return null and instead return a no-op Guard that hotspot can
    optimize out.
 2. Existing Permission implementations to be obtained using
    GuardFactorySpi implementations, until their removal.? Note that
    when SecurityManager is stubbed out and Permission implementations
    are deprecated for removal, these should no longer be provided by
    default, but instead need to be enabled by entries in the
    java.security config file, in preparation for their removal.
 3. JDK code, no longer call Permission implementations directly,
    instances obtained using GuardFactory, only when enabled in the
    java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
    *unprivileged* AccessControlContext, instead of inherited
    AccessControlContext, this is more appropriate for Executors, the
    original inherited context was designed before Executors were
    introduced.
 5. Deprecation for removal of all Permission implementations from the
    JDK platform.?? The existing implementations of Permission introduce
    unnecessary complexity; they lack sufficient flexibility resulting
    in a proliferation of Permission grants required in policy files and
    some make blocking network calls.
 6. Introduce a system property to change AccessController default
    behaviour, disable the stack walk by default, but allow it to be
    re-enabled with a system property, replace the stack walk array
    result of ProtectionDomains with an *unprivileged*
    AccessControlContext, the SubjectDomainCombiner can replace it with
    a, AccessControlContext containing a single element array,
    containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by default,
    deprecate these methods, retain doPrivilegedWithCombiner methods
    that preserve the SubjectDomainCombiner.?? Developers should replace
    their doPrivileged methods with doPrivilegedWithCombiner
 8. Deprecate for removal the CodeSource::implies method.
 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
    modules mapped to the boot loader, rather than using a Shared
    ProtectionDomain with a null CodeSource.

To clarify what an *unprivileged* AccessControlContext is:

    An instance of AccessControlContext, that contains a single element
    array, containing a ProtectionDomain, with a non null CodeSource,
    containing a null URL.

Retention of AccessController, AccessControlContext, DomainCombiner and 
SubjectDomainCombiner and Subject::doAs methods.

Stubbing of SecurityManager and Policy, for runtime backward 
compatibility. Update ProtectionDomain::implies method, to *not* consult 
with the Policy.? Note it's possible to get access to the 
ProtectionDomain array contained within AccessControlContext using a 
DomainCombiner.

This is backward compatible with existing usages of JAAS and least 
painful method of transition for all concerned as well as allowing 
complete flexibility of implementation.

Regards,

Peter Firmstone.

On 25/06/2021 3:59 pm, Peter Firmstone wrote:
> Thanks Dalibor,
>
> Would targeting Java 18 be practical?
>
> Also it won't take long to code a prototype, just not sure of the 
> process.
>
> Cheers,
>
> Peter.
>
>
> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>> Thanks Andrew,
>>>
>>> For the simple case, of replacing the SecurityManager stack walk, 
>>> one could use reflection.
>>>
>>> Thank you for also confirming that is not possible (or at least very 
>>> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK 
>>> code to use a provider mechanism, to intercept permission checks, so 
>>> custom authentication layers can be implemented, this could be 
>>> accepted in future versions of Java, but not existing. As it is 
>>> said, there is no harm in asking.
>>
>> Generally speaking, adding any public APIs to a platform release 
>> after its specification has been published, is always going to be a 
>> very tall order involving the JCP, among other things. It's not 
>> really worth it, when other technical solutions, such as 
>> multi-release JARs, already exist, that alleviate the necessity.
>>
>> cheers,
>> dalibor topic
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sat Jun 26 03:11:18 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 13:11:18 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au>
Message-ID: 

One more proposed change inline:

On 26/06/2021 12:58 pm, Peter Firmstone wrote:
>
> Summary of Proposed Changes:
>
>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>     checks without SecurityManager or Policy. (Note GuardFactory
>     should never return null and instead return a no-op Guard that
>     hotspot can optimize out.
>  2. Existing Permission implementations to be obtained using
>     GuardFactorySpi implementations, until their removal.? Note that
>     when SecurityManager is stubbed out and Permission implementations
>     are deprecated for removal, these should no longer be provided by
>     default, but instead need to be enabled by entries in the
>     java.security config file, in preparation for their removal.
>  3. JDK code, no longer call Permission implementations directly,
>     instances obtained using GuardFactory, only when enabled in the
>     java.security configuration file.
>  4. Threads (system and virtual) updated to use a singleton
>     *unprivileged* AccessControlContext, instead of inherited
>     AccessControlContext, this is more appropriate for Executors, the
>     original inherited context was designed before Executors were
>     introduced.
>  5. Deprecation for removal of all Permission implementations from the
>     JDK platform.?? The existing implementations of Permission
>     introduce unnecessary complexity; they lack sufficient flexibility
>     resulting in a proliferation of Permission grants required in
>     policy files and some make blocking network calls.
>  6. Introduce a system property to change AccessController default
>     behaviour, disable the stack walk by default, but allow it to be
>     re-enabled with a system property, replace the stack walk array
>     result of ProtectionDomains with an *unprivileged*
>     AccessControlContext, the SubjectDomainCombiner can replace it
>     with a, AccessControlContext containing a single element array,
>     containing one ProtectionDomain with Principals.
>  7. AccessController::doPrivileged erases the DomainCombiner by
>     default, deprecate these methods, retain doPrivilegedWithCombiner
>     methods that preserve the SubjectDomainCombiner.?? Developers
>     should replace their doPrivileged methods with
>     doPrivilegedWithCombiner
>  8. Deprecate for removal the CodeSource::implies method.
>  9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
>     modules mapped to the boot loader, rather than using a Shared
>     ProtectionDomain with a null CodeSource.
>
 ??? 10. Deprecate for removal AccessController::checkPermission and 
AccessControlContext::checkPermission methods.

 ??? 11. Undeprecate AccessController, AccessControlContext, 
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
deprecating for removal methods stated in items above.

> To clarify what an *unprivileged* AccessControlContext is:
>
>     An instance of AccessControlContext, that contains a single
>     element array, containing a ProtectionDomain, with a non null
>     CodeSource, containing a null URL.
>
> Retention of AccessController, AccessControlContext, DomainCombiner 
> and SubjectDomainCombiner and Subject::doAs methods.
>
> Stubbing of SecurityManager and Policy, for runtime backward 
> compatibility. Update ProtectionDomain::implies method, to *not* 
> consult with the Policy.? Note it's possible to get access to the 
> ProtectionDomain array contained within AccessControlContext using a 
> DomainCombiner.
>
> This is backward compatible with existing usages of JAAS and least 
> painful method of transition for all concerned as well as allowing 
> complete flexibility of implementation.
>
> Regards,
>
> Peter Firmstone.
>
> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>> Thanks Dalibor,
>>
>> Would targeting Java 18 be practical?
>>
>> Also it won't take long to code a prototype, just not sure of the 
>> process.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>> Thanks Andrew,
>>>>
>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>> one could use reflection.
>>>>
>>>> Thank you for also confirming that is not possible (or at least 
>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is for 
>>>> JDK code to use a provider mechanism, to intercept permission 
>>>> checks, so custom authentication layers can be implemented, this 
>>>> could be accepted in future versions of Java, but not existing. As 
>>>> it is said, there is no harm in asking.
>>>
>>> Generally speaking, adding any public APIs to a platform release 
>>> after its specification has been published, is always going to be a 
>>> very tall order involving the JCP, among other things. It's not 
>>> really worth it, when other technical solutions, such as 
>>> multi-release JARs, already exist, that alleviate the necessity.
>>>
>>> cheers,
>>> dalibor topic
>>>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sat Jun 26 03:46:25 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 13:46:25 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au>
 
Message-ID: 

Inline below.

On 26/06/2021 1:11 pm, Peter Firmstone wrote:
>
> One more proposed change inline:
>
> On 26/06/2021 12:58 pm, Peter Firmstone wrote:
>>
>> Summary of Proposed Changes:
>>
>>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>>     checks without SecurityManager or Policy. (Note GuardFactory
>>     should never return null and instead return a no-op Guard that
>>     hotspot can optimize out.
>>  2. Existing Permission implementations to be obtained using
>>     GuardFactorySpi implementations, until their removal.? Note that
>>     when SecurityManager is stubbed out and Permission
>>     implementations are deprecated for removal, these should no
>>     longer be provided by default, but instead need to be enabled by
>>     entries in the java.security config file, in preparation for
>>     their removal.
>>  3. JDK code, no longer call Permission implementations directly,
>>     instances obtained using GuardFactory, only when enabled in the
>>     java.security configuration file.
>>  4. Threads (system and virtual) updated to use a singleton
>>     *unprivileged* AccessControlContext, instead of inherited
>>     AccessControlContext, this is more appropriate for Executors, the
>>     original inherited context was designed before Executors were
>>     introduced.
>>  5. Deprecation for removal of all Permission implementations from
>>     the JDK platform.?? The existing implementations of Permission
>>     introduce unnecessary complexity; they lack sufficient
>>     flexibility resulting in a proliferation of Permission grants
>>     required in policy files and some make blocking network calls.
>>  6. Introduce a system property to change AccessController default
>>     behaviour, disable the stack walk by default, but allow it to be
>>     re-enabled with a system property, replace the stack walk array
>>     result of ProtectionDomains with an *unprivileged*
>>     AccessControlContext, the SubjectDomainCombiner can replace it
>>     with a, AccessControlContext containing a single element array,
>>     containing one ProtectionDomain with Principals.
>>  7. AccessController::doPrivileged erases the DomainCombiner by
>>     default, deprecate these methods, retain doPrivilegedWithCombiner
>>     methods that preserve the SubjectDomainCombiner.?? Developers
>>     should replace their doPrivileged methods with
>>     doPrivilegedWithCombiner
>>

Just thinking out loud, it's possible someone might want to do perform 
some task without privileges enabled, that is without the Subject's 
principal's.?? In a system that grants privileges to code and 
principals, this is generally unnecessary, as grants are made to the 
combination of code and principals.? However while using the 
doPrivileged methods is possible, to remove privileges, it would be 
better to provide an AccessController::doUnprivileged method instead, 
which erase the DomainCombiner and use an *unprivileged* 
AccessControlContext.

Since the doPrivileged methods are utilised by other methods in 
AccessController, they should be made private when finally deprecated 
for removal.

I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.

The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.

However, if a user obtains this ProtectionDomain and asks the Policy for 
the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.

It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader.

I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL.? 
This is also considered by the Policy to be unprivileged.


>>  1. Deprecate for removal the CodeSource::implies method.
>>  2. Give unique ProtectionDomain's with a meaninful CodeSource to
>>     Java modules mapped to the boot loader, rather than using a
>>     Shared ProtectionDomain with a null CodeSource.
>>
> ??? 10. Deprecate for removal AccessController::checkPermission and 
> AccessControlContext::checkPermission methods.
>
> ??? 11. Undeprecate AccessController, AccessControlContext, 
> DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
> deprecating for removal methods stated in items above.
>
>> To clarify what an *unprivileged* AccessControlContext is:
>>
>>     An instance of AccessControlContext, that contains a single
>>     element array, containing a ProtectionDomain, with a non null
>>     CodeSource, containing a null URL.
>>
>> Retention of AccessController, AccessControlContext, DomainCombiner 
>> and SubjectDomainCombiner and Subject::doAs methods.
>>
>> Stubbing of SecurityManager and Policy, for runtime backward 
>> compatibility. Update ProtectionDomain::implies method, to *not* 
>> consult with the Policy.? Note it's possible to get access to the 
>> ProtectionDomain array contained within AccessControlContext using a 
>> DomainCombiner.
>>
>> This is backward compatible with existing usages of JAAS and least 
>> painful method of transition for all concerned as well as allowing 
>> complete flexibility of implementation.
>>
>> Regards,
>>
>> Peter Firmstone.
>>
>> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>>> Thanks Dalibor,
>>>
>>> Would targeting Java 18 be practical?
>>>
>>> Also it won't take long to code a prototype, just not sure of the 
>>> process.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>>> Thanks Andrew,
>>>>>
>>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>>> one could use reflection.
>>>>>
>>>>> Thank you for also confirming that is not possible (or at least 
>>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is 
>>>>> for JDK code to use a provider mechanism, to intercept permission 
>>>>> checks, so custom authentication layers can be implemented, this 
>>>>> could be accepted in future versions of Java, but not existing. As 
>>>>> it is said, there is no harm in asking.
>>>>
>>>> Generally speaking, adding any public APIs to a platform release 
>>>> after its specification has been published, is always going to be a 
>>>> very tall order involving the JCP, among other things. It's not 
>>>> really worth it, when other technical solutions, such as 
>>>> multi-release JARs, already exist, that alleviate the necessity.
>>>>
>>>> cheers,
>>>> dalibor topic
>>>>
> -- 
> Regards,
>   
> Peter Firmstone
> 0498 286 363
> Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sat Jun 26 03:48:37 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 13:48:37 +1000
Subject: Logic bug in AccessController.AccHolder.innocuousAcc
Message-ID: 

The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.

However, if a user obtains this ProtectionDomain and asks the Policy for 
the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.

It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader.

I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL. This 
is also considered by the Policy to be unprivileged.

-- 
Regards,
  
Peter Firmstone


From peter.firmstone at zeus.net.au  Sat Jun 26 04:06:38 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 14:06:38 +1000
Subject: Logic bug in AccessController.AccHolder.innocuousAcc
In-Reply-To: 
References: 
Message-ID: 


On 26/06/2021 1:48 pm, Peter Firmstone wrote:
> The innocuous AccessControlContext, is intended to have no permission, 
> hence it is constructed using the two argument ProtectionDomain 
> constructor, which causes ProtectionDomain to not consult the Policy.
>
> However, if a user obtains this ProtectionDomain and asks the Policy 
> for the ProtectionDomain's permission's by calling 
> Policy::getPermissions(ProtectionDomain), the Policy will return 
> AllPermission.


Apologies, the Policy won't return AllPermission, my mistake.


>
> It is generally understood that a ProtectionDomain with a null 
> CodeSource is a system ProtectionDomain loaded by the bootstrap 
> ClassLoader.
>
> I propose that innocuous AccessControlContext instead be given a 
> ProtectionDomain, with a non-null CodeSource, which has a null URL. 
> This is also considered by the Policy to be unprivileged.
>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


From peter.firmstone at zeus.net.au  Sat Jun 26 04:17:39 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 14:17:39 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au>
 
 
Message-ID: <2e97c041-41b7-f3b1-55d0-25eb01878832@zeus.net.au>

Inline.

On 26/06/2021 1:46 pm, Peter Firmstone wrote:
>
> Inline below.
>
> On 26/06/2021 1:11 pm, Peter Firmstone wrote:
>>
>> One more proposed change inline:
>>
>> On 26/06/2021 12:58 pm, Peter Firmstone wrote:
>>>
>>> Summary of Proposed Changes:
>>>
>>>  1. GuardFactory & GuardFactorySpi to provide hooks for
>>>     authorization checks without SecurityManager or Policy. (Note
>>>     GuardFactory should never return null and instead return a no-op
>>>     Guard that hotspot can optimize out.
>>>  2. Existing Permission implementations to be obtained using
>>>     GuardFactorySpi implementations, until their removal. Note that
>>>     when SecurityManager is stubbed out and Permission
>>>     implementations are deprecated for removal, these should no
>>>     longer be provided by default, but instead need to be enabled by
>>>     entries in the java.security config file, in preparation for
>>>     their removal.
>>>  3. JDK code, no longer call Permission implementations directly,
>>>     instances obtained using GuardFactory, only when enabled in the
>>>     java.security configuration file.
>>>  4. Threads (system and virtual) updated to use a singleton
>>>     *unprivileged* AccessControlContext, instead of inherited
>>>     AccessControlContext, this is more appropriate for Executors,
>>>     the original inherited context was designed before Executors
>>>     were introduced.
>>>  5. Deprecation for removal of all Permission implementations from
>>>     the JDK platform.?? The existing implementations of Permission
>>>     introduce unnecessary complexity; they lack sufficient
>>>     flexibility resulting in a proliferation of Permission grants
>>>     required in policy files and some make blocking network calls.
>>>  6. Introduce a system property to change AccessController default
>>>     behaviour, disable the stack walk by default, but allow it to be
>>>     re-enabled with a system property, replace the stack walk array
>>>     result of ProtectionDomains with an *unprivileged*
>>>     AccessControlContext, the SubjectDomainCombiner can replace it
>>>     with a, AccessControlContext containing a single element array,
>>>     containing one ProtectionDomain with Principals.
>>>  7. AccessController::doPrivileged erases the DomainCombiner by
>>>     default, deprecate these methods, retain
>>>     doPrivilegedWithCombiner methods that preserve the
>>>     SubjectDomainCombiner.?? Developers should replace their
>>>     doPrivileged methods with doPrivilegedWithCombiner
>>>
>
> Just thinking out loud, it's possible someone might want to do perform 
> some task without privileges enabled, that is without the Subject's 
> principal's.?? In a system that grants privileges to code and 
> principals, this is generally unnecessary, as grants are made to the 
> combination of code and principals.? However while using the 
> doPrivileged methods is possible, to remove privileges, it would be 
> better to provide an AccessController::doUnprivileged method instead, 
> which erase the DomainCombiner and use an *unprivileged* 
> AccessControlContext.
>
> Since the doPrivileged methods are utilised by other methods in 
> AccessController, they should be made private when finally deprecated 
> for removal.
>
> I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.
>

I need to make some clarifications here:

The ProtectionDomain::getPermissions() method determines whether a 
domain is privileged if it contains AllPermission.

Since future implementations might not use Permission's to determine 
privileges, and privileges may be determined by CodeSource or 
Principal's, a null CodeSource is used to indicate a domain belonging to 
the bootstrap ClassLoader.


> The innocuous AccessControlContext, is intended to have no permission, 
> hence it is constructed using the two argument ProtectionDomain 
> constructor, which causes ProtectionDomain to not consult the Policy.
>
> However, if a user obtains this ProtectionDomain and asks the Policy 
> for the ProtectionDomain's permission's by calling 
> Policy::getPermissions(ProtectionDomain), the Policy will return 
> AllPermission.
>

This is incorrect, as the ProtectionDomain contains a null 
PermissionCollection, my mistake.

However I still propose it be changed, due to the association of a null 
CodeSource with bootstrap ClassLoader domains.

> It is generally understood that a ProtectionDomain with a null 
> CodeSource is a system ProtectionDomain loaded by the bootstrap 
> ClassLoader.
>
> I propose that innocuous AccessControlContext instead be given a 
> ProtectionDomain, with a non-null CodeSource, which has a null URL.? 
> This is also considered by the Policy to be unprivileged.
>
>
>>> ??? 8. Deprecate for removal the CodeSource::implies method.
>>>
>>> ??? 9. Give unique ProtectionDomain's with a meaninful CodeSource to 
>>> Java modules mapped to the boot loader, rather than using a Shared 
>>> ProtectionDomain with a null CodeSource.
>>>
>> ??? 10. Deprecate for removal AccessController::checkPermission and 
>> AccessControlContext::checkPermission methods.
>>
>> ??? 11. Undeprecate AccessController, AccessControlContext, 
>> DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, 
>> while deprecating for removal methods stated in items above.
>>
>>> To clarify what an *unprivileged* AccessControlContext is:
>>>
>>>     An instance of AccessControlContext, that contains a single
>>>     element array, containing a ProtectionDomain, with a non null
>>>     CodeSource, containing a null URL.
>>>
>>> Retention of AccessController, AccessControlContext, DomainCombiner 
>>> and SubjectDomainCombiner and Subject::doAs methods.
>>>
>>> Stubbing of SecurityManager and Policy, for runtime backward 
>>> compatibility. Update ProtectionDomain::implies method, to *not* 
>>> consult with the Policy.? Note it's possible to get access to the 
>>> ProtectionDomain array contained within AccessControlContext using a 
>>> DomainCombiner.
>>>
>>> This is backward compatible with existing usages of JAAS and least 
>>> painful method of transition for all concerned as well as allowing 
>>> complete flexibility of implementation.
>>>
>>> Regards,
>>>
>>> Peter Firmstone.
>>>
>>> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>>>> Thanks Dalibor,
>>>>
>>>> Would targeting Java 18 be practical?
>>>>
>>>> Also it won't take long to code a prototype, just not sure of the 
>>>> process.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>>
>>>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>>>> Thanks Andrew,
>>>>>>
>>>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>>>> one could use reflection.
>>>>>>
>>>>>> Thank you for also confirming that is not possible (or at least 
>>>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is 
>>>>>> for JDK code to use a provider mechanism, to intercept permission 
>>>>>> checks, so custom authentication layers can be implemented, this 
>>>>>> could be accepted in future versions of Java, but not existing. 
>>>>>> As it is said, there is no harm in asking.
>>>>>
>>>>> Generally speaking, adding any public APIs to a platform release 
>>>>> after its specification has been published, is always going to be 
>>>>> a very tall order involving the JCP, among other things. It's not 
>>>>> really worth it, when other technical solutions, such as 
>>>>> multi-release JARs, already exist, that alleviate the necessity.
>>>>>
>>>>> cheers,
>>>>> dalibor topic
>>>>>
>> -- 
>> Regards,
>>   
>> Peter Firmstone
>> 0498 286 363
>> Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sat Jun 26 05:41:59 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 15:41:59 +1000
Subject: READ 1ST: Re: Authorization layer API and low level access checks
In-Reply-To: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
Message-ID: 

Apologies for multiple earlier emails, please ignore and read this instead.

This proposal is about stripping out and simplifying as much of the 
dilapidated and complex SecurityManager infrastructure as possible, 
while retaining the ability for developers to implement a better high 
scaling and performant Authorization layer, without prohibitively 
preventing it.

Summary of Proposed Changes:

 1. GuardFactory & GuardFactorySpi to provide hooks for authorization
    checks without SecurityManager or Policy. (Note GuardFactory should
    never return null and instead return a no-op Guard that hotspot can
    optimize out.
 2. Existing Permission implementations to be obtained using
    GuardFactorySpi implementations, until their removal.? Note that
    when SecurityManager is stubbed out and Permission implementations
    are deprecated for removal, these should no longer be provided by
    default, but instead need to be enabled by entries in the
    java.security config file, in preparation for their removal.
 3. JDK code to no longer call Permission implementations directly,
    instances obtained using GuardFactory, when enabled in the
    java.security configuration file.
 4. Threads (system and virtual) updated to use a singleton
    *unprivileged* AccessControlContext, instead of inherited
    AccessControlContext, this is more appropriate for Executors, the
    original inherited context was designed before Executors were
    introduced.
 5. Deprecation for removal of all Permission implementations from the
    JDK platform.?? The existing implementations of Permission introduce
    unnecessary complexity; they lack sufficient flexibility resulting
    in a proliferation of Permission grants required in policy files and
    some make blocking network calls.
 6. Introduce a system property to change AccessController's default
    behaviour, disable the stack walk by default, but allow it to be
    re-enabled with a system property, replace the stack walk array
    result of ProtectionDomains with an *unprivileged*
    AccessControlContext, the SubjectDomainCombiner can replace it with
    a, AccessControlContext containing a single element array,
    containing one ProtectionDomain with Principals.
 7. AccessController::doPrivileged erases the DomainCombiner by default,
    deprecate these methods for removal (make private), retain
    doPrivilegedWithCombiner methods that preserve the
    SubjectDomainCombiner.?? Developers should replace their
    doPrivileged methods with doPrivilegedWithCombiner.?? Create a new
    method AccessController::doUnprivileged, clear intent, to erase the
    DomainCombiner, and use the *unprivileged* AccessControlContext.?
    Update AccessController.AccHolder.innocuousAcc to refer to an
    *unprivileged* context, as per the definition below.
 8. Deprecate for removal the CodeSource::implies method.
 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
    modules mapped to the boot loader, rather than using a Shared
    ProtectionDomain with a null CodeSource.
10. Deprecate for removal AccessController::checkPermission and
    AccessControlContext::checkPermission methods.
11. Undeprecate AccessController, AccessControlContext, DomainCombiner,
    SubjectDomainCombiner and Subject::doAs methods, while deprecating
    for removal methods stated in items above.
12. Deprecate for removal ProtectionDomain::implies,
    ProtectionDomain::getPermissions and
    ProtectionDomain::staticPermissionsOnly
13. Replace PermissionCollection type argument with Object in
    ProtectionDomain constructors, ignore the permissions parameter, and
    deprecate existing constructors.?? Deprecate PermissionCollection
    for removal.
14. Create a new constructor: ProtectionDomain(CodeSource cs,
    ClassLoader cl, Principal[] p).
15. Create a new factory method
    ProtectionDomain::newInstance(Principal[] p), to allow a weak cache
    of ProtectionDomain instances for each Principal[], to be utilised
    by SubjectDomainCombiner to avoid unnecessary duplication of
    objects.?? This is an optimization for AccessControlContext::equals
    and ::hashCode methods.?? Using a cache of AccessControlContext, it
    is possible to avoid rechecking authorization that has already been
    checked.? For example, when using an Executor with many tasks, all
    with the same AccessControlContext, you only need to check once and
    return the same result for subsequent checks.?? This is an
    optimization I have used previously to great effect.

To clarify what an *unprivileged* AccessControlContext is:

    An instance of AccessControlContext, that contains a single element
    array, containing a ProtectionDomain, with a null ClassLoader, null
    Principal[] and a *non-null* CodeSource, containing a null URL.

    So as to distinguish between what is traditionally a JDK bootstrap
    ProtectionDomain and unprivileged domain after
    ProtectionDomain::getPermissions is removed.

Stubbing of SecurityManager and Policy, for runtime backward 
compatibility. Update ProtectionDomain::implies method, to *not* consult 
with the Policy.? Note it's possible to get access to the 
ProtectionDomain array contained within AccessControlContext using a 
DomainCombiner.

This is backward compatible with existing usages of JAAS and least 
painful method of transition for all concerned as well as allowing 
complete flexibility of implementation.

Regards,

Peter Firmstone.

On 25/06/2021 3:59 pm, Peter Firmstone wrote:
> Thanks Dalibor,
>
> Would targeting Java 18 be practical?
>
> Also it won't take long to code a prototype, just not sure of the 
> process.
>
> Cheers,
>
> Peter.
>
>
> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>> Thanks Andrew,
>>>
>>> For the simple case, of replacing the SecurityManager stack walk, 
>>> one could use reflection.
>>>
>>> Thank you for also confirming that is not possible (or at least very 
>>> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK 
>>> code to use a provider mechanism, to intercept permission checks, so 
>>> custom authentication layers can be implemented, this could be 
>>> accepted in future versions of Java, but not existing. As it is 
>>> said, there is no harm in asking.
>>
>> Generally speaking, adding any public APIs to a platform release 
>> after its specification has been published, is always going to be a 
>> very tall order involving the JCP, among other things. It's not 
>> really worth it, when other technical solutions, such as 
>> multi-release JARs, already exist, that alleviate the necessity.
>>
>> cheers,
>> dalibor topic
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dongbohe at openjdk.java.net  Sat Jun 26 09:58:05 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Sat, 26 Jun 2021 09:58:05 GMT
Subject: Integrated: 8268427: Improve AlgorithmConstraints:checkAlgorithm
 performance
In-Reply-To: 
References: 
Message-ID: 

On Wed, 9 Jun 2021 07:53:43 GMT, Dongbo He  wrote:

> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm has been disabled. It is less efficient when there are more disabled elements in the list, we can use Set instead of List to speed up the search.
> 
> Patch contains a benchmark that can be run with `make test TEST="micro:java.security.AlgorithmConstraintsPermits"`.
> Baseline results before patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score     Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   21.687 ?   1.118  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5  324.216 ?   6.233  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5  709.462 ?  51.259  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  687.497 ? 170.181  ns/op
> 
> Benchmark results after patch:
> 
> Benchmark                            (algorithm)  Mode  Cnt    Score    Error  Units
> AlgorithmConstraintsPermits.permits        SSLv3  avgt    5   46.407 ?  1.057  ns/op
> AlgorithmConstraintsPermits.permits          DES  avgt    5   65.722 ?  0.578  ns/op
> AlgorithmConstraintsPermits.permits         NULL  avgt    5   43.988 ?  1.264  ns/op
> AlgorithmConstraintsPermits.permits       TLS1.3  avgt    5  399.546 ? 11.194  ns/op
> 
> SSLv3, DES, NULL are the first, middle and last element in `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
> 
> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter:
> Before patch:
> 
> summary +  50349 in 00:00:30 = 1678.4/s Avg:   238 Min:   188 Max:   298 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 135183 in 00:01:22 = 1654.5/s Avg:   226 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50240 in 00:00:30 = 1674.1/s Avg:   238 Min:   200 Max:   308 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 185423 in 00:01:52 = 1659.7/s Avg:   229 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50351 in 00:00:30 = 1678.4/s Avg:   238 Min:   191 Max:   306 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 235774 in 00:02:22 = 1663.7/s Avg:   231 Min:    16 Max:  1281 Err:     0 (0.00%)
> summary +  50461 in 00:00:30 = 1681.9/s Avg:   237 Min:   174 Max:   303 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> After patch:
> 
> summary +  59003 in 00:00:30 = 1966.6/s Avg:   203 Min:   158 Max:   272 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 146675 in 00:01:18 = 1884.6/s Avg:   198 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  58965 in 00:00:30 = 1965.9/s Avg:   203 Min:   166 Max:   257 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 205640 in 00:01:48 = 1907.2/s Avg:   199 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59104 in 00:00:30 = 1969.1/s Avg:   203 Min:   157 Max:   266 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> summary = 264744 in 00:02:18 = 1920.7/s Avg:   200 Min:    26 Max:   697 Err:     0 (0.00%)
> summary +  59323 in 00:00:30 = 1977.6/s Avg:   202 Min:   158 Max:   256 Err:     0 (0.00%) Active: 400 Started: 400 Finished: 0
> 
> 
> Testing: tier1, tier2

This pull request has now been integrated.

Changeset: 3b83bc1b
Author:    Dongbo He 
Committer: Hamlin Li 
URL:       https://git.openjdk.java.net/jdk/commit/3b83bc1bc331d268987f56ea4f23124a7f6ee38b
Stats:     112 lines in 4 files changed: 72 ins; 17 del; 23 mod

8268427: Improve AlgorithmConstraints:checkAlgorithm performance

Co-authored-by: GaofengZhang 
Reviewed-by: xuelei, ascarpino

-------------

PR: https://git.openjdk.java.net/jdk/pull/4424

From lancea at openjdk.java.net  Sat Jun 26 11:09:00 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 26 Jun 2021 11:09:00 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From peter.firmstone at zeus.net.au  Sat Jun 26 12:05:48 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 26 Jun 2021 22:05:48 +1000
Subject: READ 1ST: Re: Authorization layer API and low level access checks
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 
Message-ID: 


On 26/06/2021 3:41 pm, Peter Firmstone wrote:
>
> Apologies for multiple earlier emails, please ignore and read this 
> instead.
>
> This proposal is about stripping out and simplifying as much of the 
> dilapidated and complex SecurityManager infrastructure as possible, 
> while retaining the ability for developers to implement a better high 
> scaling and performant Authorization layer, without prohibitively 
> preventing it.
>
> Summary of Proposed Changes:
>
>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>     checks without SecurityManager or Policy. (Note GuardFactory
>     should never return null and instead return a no-op Guard that
>     hotspot can optimize out.
>  2. Existing Permission implementations to be obtained using
>     GuardFactorySpi implementations, until their removal.? Note that
>     when SecurityManager is stubbed out and Permission implementations
>     are deprecated for removal, these should no longer be provided by
>     default, but instead need to be enabled by entries in the
>     java.security config file, in preparation for their removal.
>  3. JDK code to no longer call Permission implementations directly,
>     instances obtained using GuardFactory, when enabled in the
>     java.security configuration file.
>  4. Threads (system and virtual) updated to use a singleton
>     *unprivileged* AccessControlContext, instead of inherited
>     AccessControlContext, this is more appropriate for Executors, the
>     original inherited context was designed before Executors were
>     introduced.
>  5. Deprecation for removal of all Permission implementations from the
>     JDK platform.?? The existing implementations of Permission
>     introduce unnecessary complexity; they lack sufficient flexibility
>     resulting in a proliferation of Permission grants required in
>     policy files and some make blocking network calls.
>  6. Introduce a system property to change AccessController's default
>     behaviour, disable the stack walk by default, but allow it to be
>     re-enabled with a system property, replace the stack walk array
>     result of ProtectionDomains with an *unprivileged*
>     AccessControlContext, the SubjectDomainCombiner can replace it
>     with a, AccessControlContext containing a single element array,
>     containing one ProtectionDomain with Principals.
>  7. AccessController::doPrivileged erases the DomainCombiner by
>     default, deprecate these methods for removal (make private),
>     retain doPrivilegedWithCombiner methods that preserve the
>     SubjectDomainCombiner.?? Developers should replace their
>     doPrivileged methods with doPrivilegedWithCombiner.?? Create a new
>     method AccessController::doUnprivileged, clear intent, to erase
>     the DomainCombiner, and use the *unprivileged*
>     AccessControlContext.? Update
>     AccessController.AccHolder.innocuousAcc to refer to an
>     *unprivileged* context, as per the definition below.
>  8. Deprecate for removal the CodeSource::implies method.
>  9. Give unique ProtectionDomain's with a meaninful CodeSource to Java
>     modules mapped to the boot loader, rather than using a Shared
>     ProtectionDomain with a null CodeSource.
> 10. Deprecate for removal AccessController::checkPermission and
>     AccessControlContext::checkPermission methods.
>
AccessController.checkPermission calls AccessControlContext.optimize, 
which invokes the DomainCombiner, prior to calling 
AccessControlContext.checkPermission

In my implementation of SecurityManager, I call 
AccessController.getContext from within a PrivilegedAction, to optimise 
a newly created AccessControlContext, (AccessController.getContext also 
calls AcessControlConext.optimize), prior to calling 
AccessControlContext.checkPermission.

I think it would be simpler however, to create a new method in 
AccessController to replace checkPermission which also calls optimize.

I think something could be done here with Stream and Consumer to perform 
the function checking ProtectionDomain's.? Needs a little more thought, 
but basically we want to be able to check each ProtectionDomain, without 
being restricted to Permission or Policy implementations.

Eg:

AccessController.stream(AccessControlContext context).forEach(domain -> 
Check::domain)

Or

AccessController.checkDomains(AccessControlContext context, 
Consumer)

This method would have a relevant Guard.check "RUNTIME" 
"getProtectionDomain" prior to calling AccessControlContext.optimize and 
the developer would need to make the call from a PrivilegedAction, and 
remember pass the relevant guard check for it's own AccessControlContext.

> 11. Undeprecate AccessController, AccessControlContext,
>     DomainCombiner, SubjectDomainCombiner and Subject::doAs methods,
>     while deprecating for removal methods stated in items above.
> 12. Deprecate for removal ProtectionDomain::implies,
>     ProtectionDomain::getPermissions and
>     ProtectionDomain::staticPermissionsOnly
> 13. Replace PermissionCollection type argument with Object in
>     ProtectionDomain constructors, ignore the permissions parameter,
>     and deprecate existing constructors.?? Deprecate
>     PermissionCollection for removal.
> 14. Create a new constructor: ProtectionDomain(CodeSource cs,
>     ClassLoader cl, Principal[] p).
> 15. Create a new factory method
>     ProtectionDomain::newInstance(Principal[] p), to allow a weak
>     cache of ProtectionDomain instances for each Principal[], to be
>     utilised by SubjectDomainCombiner to avoid unnecessary duplication
>     of objects.?? This is an optimization for
>     AccessControlContext::equals and ::hashCode methods.?? Using a
>     cache of AccessControlContext, it is possible to avoid rechecking
>     authorization that has already been checked.? For example, when
>     using an Executor with many tasks, all with the same
>     AccessControlContext, you only need to check once and return the
>     same result for subsequent checks.?? This is an optimization I
>     have used previously to great effect.
>
The ProtectionDomain::newInstance is just a nice to have, 
SubjectDomainCombiner already caches PD's, just seems a better place to 
cache for the following reasons:

  * Cache can be utilised by other implementations.
  * Simplification of SubjectDomainCombiner.
  * Responsibility of ProtectionDomain.

It's not an essential item, however, just seems like an opportunity for 
a little refactoring.

> To clarify what an *unprivileged* AccessControlContext is:
>
>     An instance of AccessControlContext, that contains a single
>     element array, containing a ProtectionDomain, with a null
>     ClassLoader, null Principal[] and a *non-null* CodeSource,
>     containing a null URL.
>
>     So as to distinguish between what is traditionally a JDK bootstrap
>     ProtectionDomain and unprivileged domain after
>     ProtectionDomain::getPermissions is removed.
>
> Stubbing of SecurityManager and Policy, for runtime backward 
> compatibility. Update ProtectionDomain::implies method, to *not* 
> consult with the Policy.? Note it's possible to get access to the 
> ProtectionDomain array contained within AccessControlContext using a 
> DomainCombiner.
>
> This is backward compatible with existing usages of JAAS and least 
> painful method of transition for all concerned as well as allowing 
> complete flexibility of implementation.
>
> Regards,
>
> Peter Firmstone.
>
> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>> Thanks Dalibor,
>>
>> Would targeting Java 18 be practical?
>>
>> Also it won't take long to code a prototype, just not sure of the 
>> process.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>> Thanks Andrew,
>>>>
>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>> one could use reflection.
>>>>
>>>> Thank you for also confirming that is not possible (or at least 
>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is for 
>>>> JDK code to use a provider mechanism, to intercept permission 
>>>> checks, so custom authentication layers can be implemented, this 
>>>> could be accepted in future versions of Java, but not existing. As 
>>>> it is said, there is no harm in asking.
>>>
>>> Generally speaking, adding any public APIs to a platform release 
>>> after its specification has been published, is always going to be a 
>>> very tall order involving the JCP, among other things. It's not 
>>> really worth it, when other technical solutions, such as 
>>> multi-release JARs, already exist, that alleviate the necessity.
>>>
>>> cheers,
>>> dalibor topic
>>>
-- 
Regards,
  
Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.java.net  Sat Jun 26 16:55:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 16:55:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:

> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
> 52:             (PrivilegedAction) ProcessHandle::current).pid();
> 53: 

The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Sat Jun 26 23:59:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 26 Jun 2021 23:59:03 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
Message-ID: 

On Sat, 26 Jun 2021 16:53:30 GMT, Alan Bateman  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more
>
> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
> 
>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>> 52:             (PrivilegedAction) ProcessHandle::current).pid();
>> 53: 
> 
> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From peter.firmstone at zeus.net.au  Sun Jun 27 09:35:18 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 27 Jun 2021 19:35:18 +1000
Subject: READ 1ST: Re: Authorization layer API and low level access checks
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 
 
Message-ID: <1e4f94c6-a55e-fd44-505e-6c244fb6176a@zeus.net.au>

Since I need to implement an authorization layer, and move past the 
current uncertainty surrounding authorization and authentication in 
Java, I think I'll start small and completely independent and learn from 
history.

Requirements:

 1. Ability to perform authorization checks on code and Subjects.
 2. Compatible with all current Java LTS releases.
 3. Will need to use Java API's, nothing platform specific.

Uncertainty:

 1. New JAAS API's are unknown, will they be suitable for our
    application? Unclear.
 2. Will hooks be provided in OpenJDK for Guard checks or not? Unclear.
 3. Lack of support for new features with existing API's going forward,
    eg virtual threads.
 4. How to authenticate TLS and Kerberos connections without using
    deprecated API's?
 5. Avoid other API's that may be removed in future due to
    under-utilisation.

What can we do with what we know, how can we do it better?

 1. Create a new Authorization.class with methods that return Callable
    objects that can be submitted to Executors, including virtual
    threads (assuming virtual threads support StackWalker).
 2. Methods:
      * Callable privilegedCall(Callable c) // Always preserves
        subject, if any.
      * Callable privilegedCall(Subject s, Callable c) // Uses
        provided Subject, from LoginModule, or executing in the context
        of an authenticated client over a secure connection.
      * Callable privilegedCall(AuthorizationContext ac, Callable
        c) // Uses provided AuthorizationContext combined with context
        of the privileged caller.
      * AuthorizationContext? getContext(); // Returns an optimized
        context (combines the inherited and calculated contexts, injects
        Principal[]'s from the Subject into each domain. Stored for
        later use when making privilegedCall's eg for TLS connection.

 3. The Authorization.class implementation will enure that the inherited
    context is stored in a ThreadLocal variable which is restored to
    it's original value using a try finally block to ensure the
    inherited context is only present during the wrapped Callable's
    call.?? It's possible that privilegedCall's are nested in one
    thread, in which case the ThreadLocal value will be changed after
    each privilegedCall to the outer calls context, until it is set to
    null, by the outermost privilegedCall.
 4. Callable returned can be submitted to an Executor, eg as a
    privileged task.
 5. Create a new AuthorizationContext class

      * Encapsulates the current Subject
      * Contains a snapshot of the ProtectionDomains when the Callable
        was passed to privilegedCall and includes the domain of the
        class that called the Authorization.privileged method as well as
        any domains of Callable implementation parameter classes, this
        is the inherited context.
      * Methods:
          o Subject getSubject() // For secure connections.
          o void checkEach(Consumer consumer) throws
            AuthorizationException // Consumer::andThen allows for
            debugging information to be printed to error, such as print
            the privileges of a domain, or to record the required
            privileges of each domain, without throwing a
            SecurityException (when recording allowed operations).
            AuthorizationContext implementation determines how to
            execute.? No mutable shared state.

 4. Use Agents to instrument Java Public API until hooks are provided by
    OpenJDK.
      * *ONLY* target LTS releases to minimize API analysis required.
      * Use static analysis to located methods in Java API's that return
        sensitive classes, eg ClassLoader, ProtectionDomain.
      * We could use some hooks here OpenJDK?
 5. How to capture domains and privileged scope?

      * It is not possible to inherit a call stack from a previous
        thread, so either the thread executes only platform code and is
        checked, assuming the platform code can be trusted to not allow
        sensitive object references to escape, or if application code is
        present, then it is unprivileged unless a privilegedCall is
        made.? It will be known by the presence of a ThreadLocal
        inherited context whether a privilegedCall is being executed.
      * The stack context is only captured after a privilegedCall is
        made on a Thread's call stack, with the exception of a call
        stack that contains *only* platform code.
      * If an inherited ThreadLocal AuthorizationContext isn't present,
        when checked, then an unprivileged domain will represent the
        entire stack, with the following exception:
          o Unless all code on the thread stack is platform code, in
            this case, capture all domains on the call stack since the
            thread started.?? This is a code only check, as no Subject
            will be present.
          o For bootloader system code construct ProtectionDomain, with
            CodeSource URL[] containing a jrt:/$MODULE , if Module
            isNamed(), retrieved from Class.getModule().
          o Authorization agents will be considered platform code.
      * At the time Authorization.getContext() is called, the inherited
        context will be combined with the stack walk from the current
        thread and the all domains will include the Subject's principals.

 6. GuardFactory and GuardFactorySpi, Authorization agents will need to
    call GuardFactory, to obtain Guard instances, the Guard
    implementation can call:
      * Authorization::getContext()checkEach(domain -> doSomething(domain));

-- 
Regards,
  
Peter Firmstone

On 26/06/2021 10:05 pm, Peter Firmstone wrote:
>
>
> On 26/06/2021 3:41 pm, Peter Firmstone wrote:
>>
>> Apologies for multiple earlier emails, please ignore and read this 
>> instead.
>>
>> This proposal is about stripping out and simplifying as much of the 
>> dilapidated and complex SecurityManager infrastructure as possible, 
>> while retaining the ability for developers to implement a better high 
>> scaling and performant Authorization layer, without prohibitively 
>> preventing it.
>>
>> Summary of Proposed Changes:
>>
>>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>>     checks without SecurityManager or Policy. (Note GuardFactory
>>     should never return null and instead return a no-op Guard that
>>     hotspot can optimize out.
>>  2. Existing Permission implementations to be obtained using
>>     GuardFactorySpi implementations, until their removal.? Note that
>>     when SecurityManager is stubbed out and Permission
>>     implementations are deprecated for removal, these should no
>>     longer be provided by default, but instead need to be enabled by
>>     entries in the java.security config file, in preparation for
>>     their removal.
>>  3. JDK code to no longer call Permission implementations directly,
>>     instances obtained using GuardFactory, when enabled in the
>>     java.security configuration file.
>>  4. Threads (system and virtual) updated to use a singleton
>>     *unprivileged* AccessControlContext, instead of inherited
>>     AccessControlContext, this is more appropriate for Executors, the
>>     original inherited context was designed before Executors were
>>     introduced.
>>  5. Deprecation for removal of all Permission implementations from
>>     the JDK platform.?? The existing implementations of Permission
>>     introduce unnecessary complexity; they lack sufficient
>>     flexibility resulting in a proliferation of Permission grants
>>     required in policy files and some make blocking network calls.
>>  6. Introduce a system property to change AccessController's default
>>     behaviour, disable the stack walk by default, but allow it to be
>>     re-enabled with a system property, replace the stack walk array
>>     result of ProtectionDomains with an *unprivileged*
>>     AccessControlContext, the SubjectDomainCombiner can replace it
>>     with a, AccessControlContext containing a single element array,
>>     containing one ProtectionDomain with Principals.
>>  7. AccessController::doPrivileged erases the DomainCombiner by
>>     default, deprecate these methods for removal (make private),
>>     retain doPrivilegedWithCombiner methods that preserve the
>>     SubjectDomainCombiner.?? Developers should replace their
>>     doPrivileged methods with doPrivilegedWithCombiner.?? Create a
>>     new method AccessController::doUnprivileged, clear intent, to
>>     erase the DomainCombiner, and use the *unprivileged*
>>     AccessControlContext.? Update
>>     AccessController.AccHolder.innocuousAcc to refer to an
>>     *unprivileged* context, as per the definition below.
>>  8. Deprecate for removal the CodeSource::implies method.
>>  9. Give unique ProtectionDomain's with a meaninful CodeSource to
>>     Java modules mapped to the boot loader, rather than using a
>>     Shared ProtectionDomain with a null CodeSource.
>> 10. Deprecate for removal AccessController::checkPermission and
>>     AccessControlContext::checkPermission methods.
>>
> AccessController.checkPermission calls AccessControlContext.optimize, 
> which invokes the DomainCombiner, prior to calling 
> AccessControlContext.checkPermission
>
> In my implementation of SecurityManager, I call 
> AccessController.getContext from within a PrivilegedAction, to 
> optimise a newly created AccessControlContext, 
> (AccessController.getContext also calls AcessControlConext.optimize), 
> prior to calling AccessControlContext.checkPermission.
>
> I think it would be simpler however, to create a new method in 
> AccessController to replace checkPermission which also calls optimize.
>
> I think something could be done here with Stream and Consumer to 
> perform the function checking ProtectionDomain's.? Needs a little more 
> thought, but basically we want to be able to check each 
> ProtectionDomain, without being restricted to Permission or Policy 
> implementations.
>
> Eg:
>
> AccessController.stream(AccessControlContext context).forEach(domain 
> -> Check::domain)
>
> Or
>
> AccessController.checkDomains(AccessControlContext context, 
> Consumer)
>
> This method would have a relevant Guard.check "RUNTIME" 
> "getProtectionDomain" prior to calling AccessControlContext.optimize 
> and the developer would need to make the call from a PrivilegedAction, 
> and remember pass the relevant guard check for it's own 
> AccessControlContext.
>
>> 11. Undeprecate AccessController, AccessControlContext,
>>     DomainCombiner, SubjectDomainCombiner and Subject::doAs methods,
>>     while deprecating for removal methods stated in items above.
>> 12. Deprecate for removal ProtectionDomain::implies,
>>     ProtectionDomain::getPermissions and
>>     ProtectionDomain::staticPermissionsOnly
>> 13. Replace PermissionCollection type argument with Object in
>>     ProtectionDomain constructors, ignore the permissions parameter,
>>     and deprecate existing constructors.?? Deprecate
>>     PermissionCollection for removal.
>> 14. Create a new constructor: ProtectionDomain(CodeSource cs,
>>     ClassLoader cl, Principal[] p).
>> 15. Create a new factory method
>>     ProtectionDomain::newInstance(Principal[] p), to allow a weak
>>     cache of ProtectionDomain instances for each Principal[], to be
>>     utilised by SubjectDomainCombiner to avoid unnecessary
>>     duplication of objects.?? This is an optimization for
>>     AccessControlContext::equals and ::hashCode methods.?? Using a
>>     cache of AccessControlContext, it is possible to avoid rechecking
>>     authorization that has already been checked.? For example, when
>>     using an Executor with many tasks, all with the same
>>     AccessControlContext, you only need to check once and return the
>>     same result for subsequent checks.?? This is an optimization I
>>     have used previously to great effect.
>>
> The ProtectionDomain::newInstance is just a nice to have, 
> SubjectDomainCombiner already caches PD's, just seems a better place 
> to cache for the following reasons:
>
>   * Cache can be utilised by other implementations.
>   * Simplification of SubjectDomainCombiner.
>   * Responsibility of ProtectionDomain.
>
> It's not an essential item, however, just seems like an opportunity 
> for a little refactoring.
>
>> To clarify what an *unprivileged* AccessControlContext is:
>>
>>     An instance of AccessControlContext, that contains a single
>>     element array, containing a ProtectionDomain, with a null
>>     ClassLoader, null Principal[] and a *non-null* CodeSource,
>>     containing a null URL.
>>
>>     So as to distinguish between what is traditionally a JDK
>>     bootstrap ProtectionDomain and unprivileged domain after
>>     ProtectionDomain::getPermissions is removed.
>>
>> Stubbing of SecurityManager and Policy, for runtime backward 
>> compatibility. Update ProtectionDomain::implies method, to *not* 
>> consult with the Policy.? Note it's possible to get access to the 
>> ProtectionDomain array contained within AccessControlContext using a 
>> DomainCombiner.
>>
>> This is backward compatible with existing usages of JAAS and least 
>> painful method of transition for all concerned as well as allowing 
>> complete flexibility of implementation.
>>
>> Regards,
>>
>> Peter Firmstone.
>>
>> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>>> Thanks Dalibor,
>>>
>>> Would targeting Java 18 be practical?
>>>
>>> Also it won't take long to code a prototype, just not sure of the 
>>> process.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>>> Thanks Andrew,
>>>>>
>>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>>> one could use reflection.
>>>>>
>>>>> Thank you for also confirming that is not possible (or at least 
>>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is 
>>>>> for JDK code to use a provider mechanism, to intercept permission 
>>>>> checks, so custom authentication layers can be implemented, this 
>>>>> could be accepted in future versions of Java, but not existing. As 
>>>>> it is said, there is no harm in asking.
>>>>
>>>> Generally speaking, adding any public APIs to a platform release 
>>>> after its specification has been published, is always going to be a 
>>>> very tall order involving the JCP, among other things. It's not 
>>>> really worth it, when other technical solutions, such as 
>>>> multi-release JARs, already exist, that alleviate the necessity.
>>>>
>>>> cheers,
>>>> dalibor topic
>>>>
> -- 
> Regards,
>   
> Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jwilhelm at openjdk.java.net  Sun Jun 27 23:14:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:14:43 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash
 - 8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class
 - 8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
 - 8269260: Add AVX512 and other SSE + AVX combinations testing for tests which generate vector instructions
 - 8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433
 - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"
 - 8269074: (fs) Files.copy fails to copy from /proc on some linux kernel versions
 - 8256919: BCEL: Utility.encode forget to close
 - 8269335: Unable to load svml library
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/8bed3534...2d9b73c0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4606/files
  Stats: 1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4606/head:pull/4606

PR: https://git.openjdk.java.net/jdk/pull/4606

From jwilhelm at openjdk.java.net  Sun Jun 27 23:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:55:06 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Sun, 27 Jun 2021 23:05:10 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a29953d8
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a29953d805ac6360bcfe005bcefa60e112788494
Stats:     1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4606

From dfuchs at openjdk.java.net  Mon Jun 28 12:24:05 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Jun 2021 12:24:05 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
 
Message-ID: 

On Sat, 26 Jun 2021 23:55:46 GMT, Weijun Wang  wrote:

>> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
>> 
>>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>>> 52:             (PrivilegedAction) ProcessHandle::current).pid();
>>> 53: 
>> 
>> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.
>
> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

Why not simply declare a local variable in the static initializer below?


    private static final long CURRENT_PID;
    private static final boolean ALLOW_ATTACH_SELF;
    static {
        PrivilegedAction pa = ProcessHandle::current;
        @SuppressWarnings("removal")
        long pid = AccessController.doPrivileged(pa).pid();
        CURRENT_PID = pid;
        String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
        ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:49 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

I'm going to move this to jdk18.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:47 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v3]
In-Reply-To: 
References: 
Message-ID: 

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more refinement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/774eb9da..2e4a8ba7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:51 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
 
 
Message-ID: <921aev1Be6BDt-9x6qkx-DqcgpCdUxkxD5nM8WQsNLs=.adbfc2ef-25cf-468a-8b6e-e8aa92aa8e3c@github.com>

On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs  wrote:

>> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.
>
> Why not simply declare a local variable in the static initializer below?
> 
> 
>     private static final long CURRENT_PID;
>     private static final boolean ALLOW_ATTACH_SELF;
>     static {
>         PrivilegedAction pa = ProcessHandle::current;
>         @SuppressWarnings("removal")
>         long pid = AccessController.doPrivileged(pa).pid();
>         CURRENT_PID = pid;
>         String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
>         ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
>     }

I've just pushed a commit with a different fix:

    private static final long CURRENT_PID = pid();

    @SuppressWarnings("removal")
    private static long pid() {
        PrivilegedAction pa = () -> ProcessHandle.current();
        return AccessController.doPrivileged(pa).pid();
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From jai.forums2013 at gmail.com  Mon Jun 28 17:16:31 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 28 Jun 2021 22:46:31 +0530
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
Message-ID: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>

(resending from the correct subscribed address)

Given the recent changes around the Java SecurityManager deprecation, 
the Ant project has been asking for user feedback on how this change 
impacts them with their Ant build files/tasks. So far we have received 
two separate user reports around this. Both of them come down to the 
same issue. Before getting to that, let me provide some context around 
what Ant does with SecurityManager. I wasn't around when the intial 
design and discussions happened decades back on Ant's usage of Java 
SecurityManager, so my knowledge around this mostly based on what I see 
in the Ant project's code and its documentation.

Ant allows user defined builds to define (optional) permissions[2]. As 
you can see from that documentation, it's just a wrapper on top of what 
Java SecurityManager provides. We internally just set up the Java 
SecurityManager appropriately and invoke the relevant tasks.

Of course, "permissions" are optional and I am not sure how many of our 
users use any of them. However, there are some tasks in Ant, like the 
"java" task which by default apply certain permissions before launching 
these tasks. The internal implementation of the "java" task sets a 
custom security manager which overrides the checkPermission(...) API to 
match against the default permissions that are set for this task. All 
that code resides in the Permissions class (and its nested MySM class) 
here[3].

Many Ant tasks run within the same JVM as the one in which the Ant build 
has been triggered. Users are allowed to configure their builds to 
launch these tasks in a "forked" (separate) JVM. "java" is one such 
task. By default we do _not_ fork and instead launch the user configured 
class in the same VM as that of the Ant build. As noted earlier, when we 
do this, we first set a new security manager and then once the execution 
completes, reset the security manager back to the old one. The setting 
and resetting of the security manager happens using the 
System.setSecurityManager(...) API, from within the same (Ant project's 
internal Permissions.java) class.


With that background, let me now get to the issue that has been reported 
by more than one user. Up until these recent EA releases of Java 17, 
users who had Ant build files (some of them very large with many 
targets/tasks) had numerous build targets and many of these targets have 
the "java" task. And since this task by default doesn't fork, most of 
these build files aren't forking when this build target is executed. 
Starting these releases, these users have started to see a flood of the 
deprecation warning messages, due to Ant's (internal) calls to 
System.setSecurityManager(...).


Consider this simple Ant build file and a trivial Java program:



 ??? 
 ??? ??? 
 ??? 

 ??? 
 ??? ??? 

 ??? 



public class HelloWorld {

 ??? public static void main(final String[] args) throws Exception {
 ??? ??? System.out.println("Hello world");
 ??? }
}

All it does is, in its "helloworld" target, uses one single "java" task 
to launch the HelloWorld class. The output it generates (I use the term 
output loosely and don't really mean STDOUT but a combination of STDOUT 
and STDERR content that gets printed out) is as follows (this is against 
latest Java 17 build 17-ea+28-2534):


helloworld:
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by 
org.apache.tools.ant.types.Permissions 
(file:/home/me//apache-ant-1.10.9/lib/ant.jar)
WARNING: Please consider reporting this to the maintainers of 
org.apache.tools.ant.types.Permissions
WARNING: System::setSecurityManager will be removed in a future release
 ???? [java] Hello world
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by 
org.apache.tools.ant.types.Permissions 
(file:/home/me//apache-ant-1.10.9/lib/ant.jar)
WARNING: Please consider reporting this to the maintainers of 
org.apache.tools.ant.types.Permissions
WARNING: System::setSecurityManager will be removed in a future release

There are multiple things of note here:

1. For a single line of output from the program it ended up generating 8 
additional lines of warning messages. I know this is a visual thing, but 
I wanted to highlight what I (and the users who reported this) meant by 
"flooding" of the logs. This virtually makes it almost impossible to 
find any real output from the program when someone is viewing the logs.

2. Notice that although it's the same 
org.apache.tools.ant.types.Permissions which is the caller to the 
System.setSecurityManager(...) API, it's being reported more than once. 
I want to emphasize this part too, since although you see it twice here, 
the important bit to remember is, it gets printed twice for every single 
usage of "java" task in the build file. So the more number of "java" 
tasks, the more you will see these messages pointing to the same culprit 
org.apache.tools.ant.types.Permissions class. For example, just add 
another "java" task in that sample build file and you will 16 lines of 
warning messages with the exact same content as above for just 2 lines 
of output from the program. IMO, repeating this log message more than 
once for the same caller class adds no value. After all, being notified 
that the specific class is using setSecurityManager at least once should 
be enough to have that class reviewed for the usage of this method.

3. This is something I raised in a separate discussion thread a few 
weeks back. In the above warning message, it's good to see that the 
caller class is being printed. However, in the above case I still 
have/had no clue why the
org.apache.tools.ant.types.Permissions was being reported twice. It's 
only when I went back to the *source code* (I emphasize this part for 
the sake of my next point) that I realized that it's being reported 
twice because of the set new security manager and reset back to old 
security manager using the setSecurityManager calls in the Permissions 
class. Again this is a guess and in this case an accurate one. What 
would have helped (and will still help) is a way to "debug" this 
immediately instead of having of open an IDE and then review the code 
(I'm probably exaggerating this part, since it's just a matter of 
searching for setSecurityManager calls in that class). If I could 
somehow set some property and see a stacktrace of these calls, it 
wouldn't have been an initial surprise to see 2 warning messages coming 
from the Permissions class for a single invocation of the "java" task.

4. In that log message, like I noted in one of the recent PR review 
comments, I think printing the codesource (jar file location on the 
filesystem) of the class which calls the API isn't adding any value. 
Personally, if/when I see this warning message and want to look into why 
it's being reported, I don't go to a jar file containing compiled 
binaries. Instead, once I know the caller class (the one reported in 
that log message), I try and find its source code to see what's going 
on. I don't remember using a decompiler the past couple of years for 
debugging issues like these, so I am not too sure that codesource 
location of the class file is adding any value.


Out of all these 4 points, I think if point number 2 can be addressed 
such that it just prints only once the warning for each caller class, 
then the issue noted by users of Ant build file will be drastically 
reduced. I haven't yet tried or proved it, but I think we will end up 
with just one log message in their STDERR for the entire build for a 
majority of the cases. I will experiment with that this week to see if 
that's true.

Of course, none of this is a solution to Ant's usage of SecurityManager. 
We (Ant project) will still have to review and remove these usages 
(which will impact the users) but that's a given. What's become a bit 
painful right now for users is that although in practice nothing has 
changed (i.e. SecurityManager behaves just like it does today and will 
continue to do so in Java 17), yet all their builds are impacted or will 
be by the deluge of these warning messages which they have no control 
over (even when they don't care or use security manager). I would expect 
that a lot of the users would want to move to Java 17 given its expected 
support life, but I think these warning messages are going to be hard to 
manage or deal with.

On a slightly related note, I was wondering why we decided to go with 
what appears to be a bit more aggressive approach to these warning 
messages as compared to what was done with the illegal reflective access 
warnings? I would have thought that the illegal reflective access 
changes would be much more involved if not the same level as moving away 
from setSecurityManager calls. Yet, those log messages weren't these 
intrusive and I hadn't seen anyone complaining about those message 
interfering with their program output or flooding their logs. In fact, I 
just gave it a try today against a slightly lenient JDK 15 with the 
following code:

public class HelloWorld {

 ??? public static void main(final String[] args) throws Exception {
 ??? ??? java.lang.reflect.Method m = 
System.class.getDeclaredMethod("checkIO");
 ??? ??? m.setAccessible(true);


 ??? ??? java.lang.reflect.Method m2 = 
java.util.ArrayList.class.getDeclaredMethod("grow");
 ??? ??? m2.setAccessible(true);

 ??? }
}

Notice that it does 2 illegal reflective accesses and when I run this 
(against Java 15) I get:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by HelloWorld (file:HelloWorld.java) 
to method java.lang.System.checkIO()
WARNING: Please consider reporting this to the maintainers of HelloWorld
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release

So it reports only the first access by default and no more, which 
probably explains why not many users complained about these log 
messages. Of course, library owners and application server providers all 
enabled the additional flags like "warn", "debug" to get more details 
and fix their code. Why not the same or something similar with the 
setSecurityManager calls?


[1] https://www.mail-archive.com/user at ant.apache.org/msg43019.html
[2] http://ant.apache.org/manual/Types/permissions.html
[3] 
https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/types/Permissions.java 


-Jaikiran


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun at openjdk.java.net  Mon Jun 28 18:11:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:11:07 GMT
Subject: [jdk17] Withdrawn: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 18:15:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:15:30 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
Message-ID: 

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

-------------

Commit messages:
 - copy all code change from jdk17

Changes: https://git.openjdk.java.net/jdk/pull/4615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4615&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 293 lines in 21 files changed: 165 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4615/head:pull/4615

PR: https://git.openjdk.java.net/jdk/pull/4615

From lancea at openjdk.java.net  Mon Jun 28 18:44:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 18:44:06 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

The revisions you made as part of the push to JDK 18 look fine Max.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4615

From Alan.Bateman at oracle.com  Mon Jun 28 18:51:57 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Jun 2021 19:51:57 +0100
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
Message-ID: <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>

On 28/06/2021 18:16, Jaikiran Pai wrote:
>
> On a slightly related note, I was wondering why we decided to go with 
> what appears to be a bit more aggressive approach to these warning 
> messages as compared to what was done with the illegal reflective 
> access warnings? I would have thought that the illegal reflective 
> access changes would be much more involved if not the same level as 
> moving away from setSecurityManager calls.
The typical SM setup will be to set it once, the Ant "same JVM" scenario 
where it sets and then resets it may be unusual.

In any case, the original implementation patch did have caching to avoid 
duplicates. It wasn't quite right and had to be pulled, it may be time 
to re-visit that to avoid too much noise for code that sets it many times.

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun at openjdk.java.net  Mon Jun 28 19:09:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 19:09:15 GMT
Subject: Integrated: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

This pull request has now been integrated.

Changeset: e9b2c058
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/e9b2c058a4ed5de29b991360f78fc1c5263c9268
Stats:     293 lines in 21 files changed: 165 ins; 64 del; 64 mod

8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4615

From sean.coffey at oracle.com  Tue Jun 29 00:02:05 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 29 Jun 2021 01:02:05 +0100
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Valerie,

many thanks for the thorough review. I've taken all your feedback on 
board with the latest push. Some of the test anomalies were a result of 
previous iterations of test edits I had been making.

Regarding the extra edits in 
"src/java.base/share/lib/security/default.policy", I had assumed it 
would be ok to tidy up the module under edit but I've reverted the 
unrelated changes now.

I was doubtful about removing the AccessController.doPrivileged blocks 
around the InnocuousThread.newSystemThread calls given that I wasn't 
sure which path the calling code would come from but on re-examination, 
I think it's ok to remove. The module provides the necessary permissions 
already and use of InnocuousThread solves the original permissions 
issue. Thanks for spotting!

> In test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java 
> :
>
> > +        if (args.length > 0) {
> +            Policy.setPolicy(new SimplePolicy());
> +            System.setSecurityManager(new SecurityManager());
> +        }

> Just curious, why split the loop into 2 and set the SecurityManager in 
> between the two loops? Can't we just set the policy/security manager 
> before the loop?
The test infra requires various permissions including the problem 
setContextClassLoader permission. I figured it was better to set up the 
test infra first and then trigger the security manager.

New edits just pushed for review.

regards,
Sean.


On 25/06/2021 23:31, Valerie Peng wrote:
> On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:
>
>>> Sufficient permissions missing if this code was ever to run with SecurityManager.
>>>
>>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>>> Test case coverage extended to cover the SecurityManager scenario.
>>>
>>> Reviewer request: @valeriepeng
>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Move TokenPoller to Runnable
> src/java.base/share/lib/security/default.policy line 131:
>
>> 129:     permission java.lang.RuntimePermission "accessClassInPackage.com.sun.crypto.provider";
>> 130:     permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc";
>> 131:     permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";
> Can we just do necessary changes? I noticed that this file seems to have mixed style, i.e. some lines are longer than 80 chars and some break into 2 lines with length less than 80 chars. Since the whole file is mixed, maybe just do what must be changed.
>
> src/java.base/share/lib/security/default.policy line 142:
>
>> 140:     permission java.security.SecurityPermission "clearProviderProperties.*";
>> 141:     permission java.security.SecurityPermission "removeProviderProperty.*";
>> 142:     permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
> Same "avoid unnecessary changes" comment here.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:
>
>> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
>> 951:             Thread t = InnocuousThread.newSystemThread(
>> 952:                     "Poller " + getName(),
> nit: "Poller " -> "Poller-" (like before)?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 956:
>
>> 954:             assert t.getContextClassLoader() == null;
>> 955:             t.setDaemon(true);
>> 956:             t.setPriority(Thread.MIN_PRIORITY);
> nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1033:
>
>> 1031:         }
>> 1032:         cleaner = new NativeResourceCleaner();
>> 1033:         AccessController.doPrivileged((PrivilegedAction) () -> {
> It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1039:
>
>> 1037:             assert t.getContextClassLoader() == null;
>> 1038:             t.setDaemon(true);
>> 1039:             t.setPriority(Thread.MIN_PRIORITY);
> nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1212:
>
>> 1210:
>> 1211:         this.token = token;
>> 1212:         if (cleaner == null) {
> This check seems duplicate to the one in createCleaner() call.
>
> test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 56:
>
>> 54:                 System.out.println("No NSS config found. Skipping.");
>> 55:                 return;
>> 56:             }
> Move this if-check block of code up before the for-loop?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk17/pull/117
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From coffeys at openjdk.java.net  Tue Jun 29 00:07:41 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 29 Jun 2021 00:07:41 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v3]
In-Reply-To: 
References: 
Message-ID: 

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Edits from review
 - Merge remote-tracking branch 'origin/master' into pkcs11-perms
 - Move TokenPoller to Runnable
 - 8269034: AccessControlException for SunPKCS11 daemon threads

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/117/files
  - new: https://git.openjdk.java.net/jdk17/pull/117/files/03af6494..e961ff09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=01-02

  Stats: 3102 lines in 121 files changed: 2073 ins; 670 del; 359 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From jai.forums2013 at gmail.com  Tue Jun 29 07:04:46 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 29 Jun 2021 12:34:46 +0530
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
Message-ID: <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>


On 29/06/21 12:21 am, Alan Bateman wrote:
> On 28/06/2021 18:16, Jaikiran Pai wrote:
>>
>> On a slightly related note, I was wondering why we decided to go with 
>> what appears to be a bit more aggressive approach to these warning 
>> messages as compared to what was done with the illegal reflective 
>> access warnings? I would have thought that the illegal reflective 
>> access changes would be much more involved if not the same level as 
>> moving away from setSecurityManager calls.
> The typical SM setup will be to set it once, the Ant "same JVM" 
> scenario where it sets and then resets it may be unusual.
>
> In any case, the original implementation patch did have caching to 
> avoid duplicates. It wasn't quite right and had to be pulled, it may 
> be time to re-visit that to avoid too much noise for code that sets it 
> many times.
>
Thank you Alan. I see that 
https://bugs.openjdk.java.net/browse/JDK-8269543 has been created for 
this. I'll keep a watch on that one.


 > Out of all these 4 points, I think if point number 2 can be addressed 
such that it just prints only once the warning for each caller class, 
then the issue noted by users of Ant build file will be drastically 
reduced. I haven't yet tried or proved it, but I think we will end up 
with just one log message in their STDERR for the entire build for a 
majority of the cases. I will experiment with that this week to see if 
that's true.

FWIW - I implemented a very primitive cache in the System class to log 
this message just once and see if it helps for the general/regular 
usecase that I used as an example. That indeed helped and I see that the 
warning message just gets printed once for the entire lifetime of the 
build process, no matter how many "java" tasks get called. So the 
changes in JDK-8269543 will help us to a considerable extent.


-Jaikiran




From jai.forums2013 at gmail.com  Tue Jun 29 07:08:19 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 29 Jun 2021 12:38:19 +0530
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
Message-ID: 


On 29/06/21 12:34 pm, Jaikiran Pai wrote:
>
>
>
> > Out of all these 4 points, I think if point number 2 can be 
> addressed such that it just prints only once the warning for each 
> caller class, then the issue noted by users of Ant build file will be 
> drastically reduced. I haven't yet tried or proved it, but I think we 
> will end up with just one log message in their STDERR for the entire 
> build for a majority of the cases. I will experiment with that this 
> week to see if that's true.
>
> FWIW - I implemented a very primitive cache in the System class to log 
> this message just once and see if it helps for the general/regular 
> usecase that I used as an example.

To be clear, just once for each caller class.

-Jaikiran


From Alan.Bateman at oracle.com  Tue Jun 29 11:42:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Jun 2021 12:42:35 +0100
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
Message-ID: <2261038a-06b1-c011-7434-7b6274c21882@oracle.com>



On 29/06/2021 08:04, Jaikiran Pai wrote:
>
> Thank you Alan. I see that 
> https://bugs.openjdk.java.net/browse/JDK-8269543 has been created for 
> this. I'll keep a watch on that one.
>
Yes, that was the original intention but had to dropped because it 
wasn't thread safe.

BTW: I'm puzzled as to why Ant does this. I re-read your mail yesterday 
a few times and it seems a real outlier to run an Ant script like this. 
Maybe there are use-cases beyond building where this may be have been 
useful in the past? (I understand you may not have all the 
history/rational for this).

-Alan

From valeriep at openjdk.java.net  Tue Jun 29 17:47:07 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 29 Jun 2021 17:47:07 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Jun 2021 00:07:41 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Edits from review
>  - Merge remote-tracking branch 'origin/master' into pkcs11-perms
>  - Move TokenPoller to Runnable
>  - 8269034: AccessControlException for SunPKCS11 daemon threads

Update looks good. Thanks, Valerie

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/117

From dfuchs at openjdk.java.net  Tue Jun 29 18:50:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Jun 2021 18:50:08 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
Message-ID: 

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
> 336:     }
> 337: 

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From rriggs at openjdk.java.net  Tue Jun 29 19:26:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 19:26:04 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
Message-ID: 

On Tue, 29 Jun 2021 18:47:23 GMT, Daniel Fuchs  wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> src/java.base/share/classes/java/lang/System.java line 337:
> 
>> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
>> 336:     }
>> 337: 
> 
> I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From weijun at openjdk.java.net  Tue Jun 29 19:39:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 29 Jun 2021 19:39:03 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
Message-ID: 

On Tue, 29 Jun 2021 19:23:26 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/lang/System.java line 337:
>> 
>>> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
>>> 336:     }
>>> 337: 
>> 
>> I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.
>
> Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
> or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.

If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From chap at anastigmatix.net  Tue Jun 29 19:57:20 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Tue, 29 Jun 2021 15:57:20 -0400
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
Message-ID: <60DB7B20.7000706@anastigmatix.net>

On 06/29/21 15:39, Weijun Wang wrote:

> If I switch to a "non-weak" set or map, then it seems I can safely use
> the source string as the key. Will using the Class object as a key prevent
> them from unloading?

I understand that it's in principle possible for classes to get GC'd,
though I don't know how often it happens in typical practical settings.

This seems like a question to be approached from the angle of asking
what the wanted semantics should be. What should be the effect on warning
messages if class a.b.C is loaded and sets a security manager, and is later
GC'd, and then a class also named a.b.C is later loaded, and sets a security
manager?

It seems like a preferred answer to that question would determine
whether to make the set weak or not.

Regards,
-Chap

From rriggs at openjdk.java.net  Tue Jun 29 19:59:59 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 19:59:59 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
Message-ID: <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>

On Tue, 29 Jun 2021 19:35:40 GMT, Weijun Wang  wrote:

>> Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
>> or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.
>
> If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?

Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
Using a non-weak set or map to strings would keep the strings around for the life of the runtime.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From weijun.wang at oracle.com  Tue Jun 29 21:12:01 2021
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Tue, 29 Jun 2021 21:12:01 +0000
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: 
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
 
Message-ID: 



> On Jun 29, 2021, at 3:08 AM, Jaikiran Pai  wrote:
> 
> 
> On 29/06/21 12:34 pm, Jaikiran Pai wrote:
>> 
>> 
>> 
>> > Out of all these 4 points, I think if point number 2 can be addressed such that it just prints only once the warning for each caller class, then the issue noted by users of Ant build file will be drastically reduced. I haven't yet tried or proved it, but I think we will end up with just one log message in their STDERR for the entire build for a majority of the cases. I will experiment with that this week to see if that's true.
>> 
>> FWIW - I implemented a very primitive cache in the System class to log this message just once and see if it helps for the general/regular usecase that I used as an example.
> 
> To be clear, just once for each caller class.

In your case, is the class always the same object? I was thinking about if I should use a String or a Class as the map key. Is it possible for the same class to be loaded again and again?

Thanks,
Max

> 
> -Jaikiran
> 


From weijun at openjdk.java.net  Tue Jun 29 21:22:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 29 Jun 2021 21:22:05 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
 <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
Message-ID: 

On Tue, 29 Jun 2021 19:57:24 GMT, Roger Riggs  wrote:

>> If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?
>
> Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
> Using a non-weak set or map to strings would keep the strings around for the life of the runtime.

I hope this is uncommon but if that class is created by a `ClassLoader` again and again then it will be different each time. I'll investigate more.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From coffeys at openjdk.java.net  Tue Jun 29 22:56:07 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 29 Jun 2021 22:56:07 GMT
Subject: [jdk17] Integrated: 8269034: AccessControlException for SunPKCS11
 daemon threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 13:26:41 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

This pull request has now been integrated.

Changeset: 0d745ae8
Author:    Sean Coffey 
URL:       https://git.openjdk.java.net/jdk17/commit/0d745ae8fde5cab290dc8c695d2906f9a98c491c
Stats:     95 lines in 5 files changed: 53 ins; 17 del; 25 mod

8269034: AccessControlException for SunPKCS11 daemon threads

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From jwilhelm at openjdk.java.net  Wed Jun 30 00:39:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 00:39:07 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8269034: AccessControlException for SunPKCS11 daemon threads
 - 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build
 - 8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak
 - 8268884: C2: Compile::remove_speculative_types must iterate top-down
 - 8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}
 - 8268699: Shenandoah: Add test for JDK-8268127
 - 8269517: compiler/loopopts/TestPartialPeelingSinkNodes.java crashes with -XX:+VerifyGraphEdges
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
  Stats: 127 lines in 11 files changed: 70 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From xuelei at openjdk.java.net  Wed Jun 30 00:58:06 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Wed, 30 Jun 2021 00:58:06 GMT
Subject: RFR: 8268965: TCP Connection Reset when connecting simple socket
 to SSL server
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 13:20:54 GMT, Alexey Bakhtin  wrote:

> Please review the fix for JDK-8268965.
> 
> The new jtreg test is added for the described issue.
> sun/security/ssl and javax/net/ssl tests are passed

I would like to have a look.  I was wondering if there is a racing between close and read and if the closure could be hang.  But I have no time to think more about them currently.  Hopefully, I could have some cycles in the next couple of weeks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4520

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 00:31:34 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: ee526a2e
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/ee526a2ea840aedb97b23538f9d624acbccebc97
Stats:     127 lines in 11 files changed: 70 ins; 17 del; 40 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4630

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: <8_fkYpZLlCG8Nj5dx5WhuZsWDbFnUHu4OWWY735hdr0=.625da0e5-831e-4c10-afbc-aa5364fba16b@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:

 - Merge
 - 8269615: Fix for 8263640 broke Windows build
   
   Reviewed-by: iklam, dcubed
 - 8269268: JDWP: Properly fix thread lookup assert in findThread()
   
   Reviewed-by: kevinw, amenkov, sspitsyn
 - 8260540: serviceability/jdwp/AllModulesCommandTest.java failed with "Debuggee error: 'ERROR: transport error 202: bind failed: Address already in use'"
   
   Reviewed-by: sspitsyn, kevinw
 - 8263640: hs_err improvement: handle class path longer than O_BUFLEN
   
   Reviewed-by: iklam, minqi, dholmes
 - 8269417: Minor clarification on NonblockingQueue utility
   
   Reviewed-by: kbarrett, iwalulya
 - 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
   
   Reviewed-by: dholmes, coleenp
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC
   
   Reviewed-by: iwalulya, kbarrett
 - 8261579: AArch64: Support for weaker memory ordering in Atomic
   
   Reviewed-by: adinn, shade
 - 8268821: Split systemDictionaryShared.cpp
   
   Reviewed-by: erikj, ccheung, iklam
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/0d745ae8...be964f2e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4630&range=01
  Stats: 30219 lines in 619 files changed: 17676 ins; 10608 del; 1935 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From jai.forums2013 at gmail.com  Wed Jun 30 04:51:41 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 30 Jun 2021 10:21:41 +0530
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: 
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
 
 
Message-ID: <4ed92b60-59ff-c5d8-4ded-a0473d719f12@gmail.com>

Hello Max,

On 30/06/21 2:42 am, Wei-Jun Wang wrote:
>
>> On Jun 29, 2021, at 3:08 AM, Jaikiran Pai  wrote:
>>
>>
>> On 29/06/21 12:34 pm, Jaikiran Pai wrote:
>>>
>>>
>>>> Out of all these 4 points, I think if point number 2 can be addressed such that it just prints only once the warning for each caller class, then the issue noted by users of Ant build file will be drastically reduced. I haven't yet tried or proved it, but I think we will end up with just one log message in their STDERR for the entire build for a majority of the cases. I will experiment with that this week to see if that's true.
>>> FWIW - I implemented a very primitive cache in the System class to log this message just once and see if it helps for the general/regular usecase that I used as an example.
>> To be clear, just once for each caller class.
> In your case, is the class always the same object? I was thinking about if I should use a String or a Class as the map key. Is it possible for the same class to be loaded again and again?

In the case we are dealing with, the class is always 
"org.apache.tools.ant.types.Permissions". It will always be loaded by 
one single classloader (so classloaded just once). However, multiple 
different instances of this class will get created during the lifetime 
of the build and each such instance of 
org.apache.tools.ant.types.Permissions can/will invoke this 
setSecurityManager method.

One additional detail - this org.apache.tools.ant.types.Permissions is 
_not_ final, which means it can potentially have sub-classes. In the 
context of Ant, the fact that this class is not final shouldn't really 
have any implication in how the caching in java.lang.System gets 
implemented. I only bring this up here because maybe it has to be taken 
into account for the general cases? I haven't yet checked how the 
Reflection.getCallerClass() is implemented in the JDK and whether this 
caching logic that's being introduced needs to take into account 
sub-classes while deciding whether or not to issue a warning.

-Jaikiran




From alanb at openjdk.java.net  Wed Jun 30 06:35:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 30 Jun 2021 06:35:05 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
 <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
 
Message-ID: 

On Tue, 29 Jun 2021 21:18:35 GMT, Weijun Wang  wrote:

>> Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
>> Using a non-weak set or map to strings would keep the strings around for the life of the runtime.
>
> I hope this is uncommon but if that class is loaded by a `ClassLoader` again and again then it will be different each time. I'll investigate more.

WeakHashMap, Boolean>, where the key is the caller, should be okay (assume synchronization of course). Even with applications that do call setSecurityManager then the map is probably going to be one entry. I wouldn't expect it is common to create custom class loaders that load code that sets a security manager, meaning it is more likely that the container sets the SM rather have each plugin/application/whatever try to set the system-wide SM.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From Alan.Bateman at oracle.com  Wed Jun 30 06:40:47 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Jun 2021 07:40:47 +0100
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <4ed92b60-59ff-c5d8-4ded-a0473d719f12@gmail.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
 
 
 <4ed92b60-59ff-c5d8-4ded-a0473d719f12@gmail.com>
Message-ID: <5773e2b8-9412-82e6-cd17-fb8ad78e3f97@oracle.com>

On 30/06/2021 05:51, Jaikiran Pai wrote:
>
> In the case we are dealing with, the class is always 
> "org.apache.tools.ant.types.Permissions". It will always be loaded by 
> one single classloader (so classloaded just once). However, multiple 
> different instances of this class will get created during the lifetime 
> of the build and each such instance of 
> org.apache.tools.ant.types.Permissions can/will invoke this 
> setSecurityManager method.
If I read this correctly, the caller of setSecurityManager is code in 
org.apache.tools.ant.types.Permission. There may be many instances of 
Permissions but from the perspective of setSecurityManager then it's all 
the same caller Class.

-Alan

From jai.forums2013 at gmail.com  Wed Jun 30 06:43:25 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 30 Jun 2021 12:13:25 +0530
Subject: Initial feedback from Apache Ant users on recent security manager
 warning messages
In-Reply-To: <5773e2b8-9412-82e6-cd17-fb8ad78e3f97@oracle.com>
References: <35e2fae1-1bda-9bc5-45a2-43fc55c73bce@gmail.com>
 <6cf860ba-37e0-1839-7a37-4bc42c5e3ed7@oracle.com>
 <07a25547-58e5-02ef-c6df-489fcb1331f9@gmail.com>
 
 
 <4ed92b60-59ff-c5d8-4ded-a0473d719f12@gmail.com>
 <5773e2b8-9412-82e6-cd17-fb8ad78e3f97@oracle.com>
Message-ID: <80dd8399-86c0-aaae-fec5-559560f74e88@gmail.com>


On 30/06/21 12:10 pm, Alan Bateman wrote:
> On 30/06/2021 05:51, Jaikiran Pai wrote:
>>
>> In the case we are dealing with, the class is always 
>> "org.apache.tools.ant.types.Permissions". It will always be loaded by 
>> one single classloader (so classloaded just once). However, multiple 
>> different instances of this class will get created during the 
>> lifetime of the build and each such instance of 
>> org.apache.tools.ant.types.Permissions can/will invoke this 
>> setSecurityManager method.
> If I read this correctly, the caller of setSecurityManager is code in 
> org.apache.tools.ant.types.Permission. There may be many instances of 
> Permissions but from the perspective of setSecurityManager then it's 
> all the same caller Class.

Correct.

-Jaikiran


From ecki at zusammenkunft.net  Wed Jun 30 07:19:42 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 30 Jun 2021 07:19:42 +0000
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>,
 
Message-ID: 

Hello, sorry for being unpopular, but I just hate it to waste developer resources,

I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of time and on top of it, there is no clear replacement strategy published yet.

I would restrict deprication (for removal if you really insist) to javadoc and not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no need to further damage java reputation by breaking perfectly working inter process interfaces. (This is btw true for all such warnings). And I also think top priority should be to publish a go-forward route which should not depend solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev  im Auftrag von Daniel Fuchs 
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-dev at openjdk.java.net ; security-dev at openjdk.java.net 
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
> 336:     }
> 337:

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Alan.Bateman at oracle.com  Wed Jun 30 08:15:13 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Jun 2021 09:15:13 +0100
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
Message-ID: <81d9a604-8586-67fa-39f2-3cc447e1eade@oracle.com>

On 30/06/2021 08:19, Bernd Eckenfels wrote:
> Hello, sorry for being unpopular, but I just hate it to waste 
> developer resources,
>
> I realy think this deprecation message should be re-considered, it 
> broke a lot of things, the amount of work to implement a caching 
> solution feels like a waste of time and on top of it, there is no 
> clear replacement strategy published yet.
>
> I would restrict deprication (for removal if you really insist) to 
> javadoc and not poison stdout/stderr.
>

The purpose of the warning message is to make it very clear that 
applications that call System.setSecurityManager in a running VM will 
fail in the future. It is not hugely different to the "Illegal 
reflective access" warning that were emitted in JDK 9 to JDK 15. Maybe 
you could clarify what you mean by "it broke a lot of things". If you 
have something that is sensitive to warnings going to stderr then I 
would have expected the "Illegal reflective access" warnings to have 
caused a lot more issues.

-Alan.

From peter.firmstone at zeus.net.au  Wed Jun 30 11:38:06 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 30 Jun 2021 21:38:06 +1000
Subject: Authorization layer API and low level access checks.
In-Reply-To: 
References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au>
 <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com>
 <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au>
 <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com>
 <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au>
 
 <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au>
 <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com>
 
Message-ID: <974bd92d-4a7b-a454-af54-8b395e411abc@zeus.net.au>

A draft Authorization implementation, untested.

-- 
Regards,
  
Peter Firmstone


/**
 ?* Authorization class, instances contain the domains and Subject of the
 ?* Authorization context, used for Authorization decisions by Guard
 ?* implementations.? Provides static utility methods to make 
privilgedCall's
 ?* and record the current context.
 ?*
 ?* @author peter
 ?*/
public final class Authorization {

 ??? private static final ProtectionDomain MY_DOMAIN = 
Authorization.class.getProtectionDomain();

 ??? private static final Authorization PRIVILEGED =
 ??????????? new Authorization(new ProtectionDomain []{ MY_DOMAIN });

 ??? private static final Authorization UNPRIVILEGED
 ??????? = new Authorization(
 ??????????? new ProtectionDomain[]{
 ??????????????? new ProtectionDomain(
 ??????????????????????? new CodeSource(null, (Certificate [])null), null
 ??????????????? )
 ??????????? }
 ??????? );

 ??? private static final ThreadLocal INHERITED_CONTEXT
 ??????????? = new ThreadLocal();

 ??? private static final Guard GUARD_REGISTER_CHECK =
 ??????? GuardBuilder.getInstance("RUNTIME").get("registerGuard", 
(String) null);

 ??? private static final Guard GUARD_SUBJECT =
GuardBuilder.getInstance("AUTH").get("getSubjectFromAuthorization", null);

 ??? private static final Set> GUARDS =
 ??????????? RC.set(Collections.newSetFromMap(new 
ConcurrentHashMap<>()), Ref.WEAK, 0);



 ??? /**
 ???? * Elevates the privileges of the Callable to those granted to the 
Subject
 ???? * and ProtectionDomain's of the Callable and it's call stack, 
including the
 ???? * ProtectionDomain of the caller of this method.
 ???? *
 ???? * @param 
 ???? * @param c
 ???? * @return
 ???? */
 ??? public static  Callable privilegedCall(Callable c){
 ??????? Authorization auth = INHERITED_CONTEXT.get();
 ??????? try {
 ??????????? INHERITED_CONTEXT.set(PRIVILEGED);
 ??????????? if (auth != null){
 ??????????????? return privilegedCall(auth.getSubject(), c);
 ??????????? } else {
 ??????????????? return new CallableWrapper<>(new 
Authorization(captureCallerDomain(null), null), c);
 ??????????? }
 ??????? } finally {
 ??????????? INHERITED_CONTEXT.set(auth);
 ??????? }
 ??? }

 ??? /**
 ???? * Elevates the privileges of the Callable to those granted to the 
Subject
 ???? * and ProtectionDomain's of the Callable and it's call stack, 
including the
 ???? * ProtectionDomain of the caller of this method.
 ???? *
 ???? * @param 
 ???? * @param subject
 ???? * @param c
 ???? * @return
 ???? */
 ??? public static  Callable privilegedCall(Subject subject, 
Callable c){
 ??????? Authorization authorization = INHERITED_CONTEXT.get();
 ??????? try {
 ??????????? INHERITED_CONTEXT.set(PRIVILEGED);
 ??????????? Set p = subject != null ? 
subject.getPrincipals() : null;
 ??????????? Principal [] principals = p != null ? p.toArray(new 
Principal[p.size()]) : null;
 ??????????? return new CallableWrapper<>(new 
Authorization(captureCallerDomain(principals), subject), c);
 ??????? } finally {
 ??????????? INHERITED_CONTEXT.set(authorization);
 ??????? }
 ??? }

 ??? /**
 ???? * Elevates the privileges of the Callable to those granted to the 
Subject
 ???? * and ProtectionDomain's of the Callable and it's call stack, 
including the
 ???? * ProtectionDomain of the caller of this method and the Authorization
 ???? * context provided.
 ???? *
 ???? * @param 
 ???? * @param ac
 ???? * @param c
 ???? * @return
 ???? */
 ??? public static  Callable privilegedCall(Authorization ac, 
Callable c){
 ??????? if (c == null) throw new IllegalArgumentException("Callable 
cannot be null");
 ??????? if (ac != null){
 ??????????? Authorization authorization = INHERITED_CONTEXT.get();
 ??????????? try {
 ??????????????? INHERITED_CONTEXT.set(PRIVILEGED);
 ??????????????? Subject subject = ac.getSubject();
 ??????????????? Set p = subject != null ? 
subject.getPrincipals() : null;
 ??????????????? Principal [] principals = p != null ? p.toArray(new 
Principal[p.size()]) : null;
 ??????????????? Set domains = 
captureCallerDomain(principals);
 ??????????????? ac.checkEach((ProtectionDomain t) -> {
 ??????????????????? if (MY_DOMAIN.equals(t)) return;
 ??????????????????? if (principals != null){
 ??????????????????????? domains.add(
 ??????????????????????????? new ProtectionDomainKey(t, principals)
 ??????????????????????? );
 ??????????????????? } else {
 ??????????????????????? domains.add(new ProtectionDomainKey(t));
 ??????????????????? }
 ??????????????? });
 ??????????????? Authorization auth = new Authorization(domains, subject);
 ??????????????? return new CallableWrapper<>(auth, c);
 ??????????? } finally {
 ??????????????? INHERITED_CONTEXT.set(authorization);
 ??????????? }
 ??????? } else {
 ??????????? return privilegedCall(c);
 ??????? }
 ??? }

 ??? private static Set captureCallerDomain(Principal 
[] principals){
 ??????? Set