Re: RFR: 8312444: Delete unused parameters and variables in SocketPermission [v2]

2024-03-04 Thread Andrey Turbanov
On Sat, 2 Mar 2024 13:51:04 GMT, Korov wrote: >> Removing unused parameter `defval` in `SocketPermission.initEphemeralPorts`, >> so the variable `PRIV_PORT_MAX` and `DEF_EPH_LOW` unused too. >> >> Removing unused parameter `cname` in `SocketPermission.authorizedIPv4` and >> `SocketPermission.a

Re: RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe

2024-03-04 Thread Jaikiran Pai
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote: > Please review this cleanup PR which suggests we remove the package-private, > unused and deprecated method `java.util.jar.Manifest.make72Safe`. > > This method was marked deprecated after a cleanup/refactoring in > [JDK-8066619](https://

Re: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation

2024-03-04 Thread Mat Carter
On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as > read-only (instead of failing). > > Please note that permissions to use a cert

Re: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation

2024-03-04 Thread Weijun Wang
On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as > read-only (instead of failing). > > Please note that permissions to use a cert

Re: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation

2024-03-04 Thread MustavData
On Wed, 24 Jan 2024 00:41:15 GMT, Mat Carter wrote: >> This fixes the defect described at >> https://bugs.openjdk.org/browse/JDK-8313367 >> >> If the process does not have write permissions, the store is opened as >> read-only (instead of failing). >> >> Please note that permissions to use a

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v4]

2024-03-04 Thread Weijun Wang
> This code change adds an alternative implementation of user-based > authorization `Subject` APIs that doesn't depend on Security Manager APIs. > Depending on if the Security Manager is allowed, the methods store the > current subject differently. See the spec change in the `Subject.java` file

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 16:17:14 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > src/java.base/share/classes/javax/security/auth/Subject.java line

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:47:41 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java l

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:15:54 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 69:

Re: RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe

2024-03-04 Thread Iris Clark
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote: > Please review this cleanup PR which suggests we remove the package-private, > unused and deprecated method `java.util.jar.Manifest.make72Safe`. > > This method was marked deprecated after a cleanup/refactoring in > [JDK-8066619](https://

Re: RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe

2024-03-04 Thread Lance Andersen
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote: > Please review this cleanup PR which suggests we remove the package-private, > unused and deprecated method `java.util.jar.Manifest.make72Safe`. > > This method was marked deprecated after a cleanup/refactoring in > [JDK-8066619](https://

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Sean Mullan
On Mon, 4 Mar 2024 19:51:38 GMT, Weijun Wang wrote: >> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java >> line 309: >> >>> 307: final Subject s; >>> 308: if (!SharedSecrets.getJavaLangAccess().allowSecurityManager()) >>> { >>>

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Weijun Wang
On Mon, 4 Mar 2024 15:28:28 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix MBeanServerFileAccessController, more test in SM > > src/java.management/share/classes/com/sun/jmx/remote/security/MBe

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread ExE Boss
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote: > Currently, JDK modules load by the bootstrap and platform ClassLoaders are > automatically granted the native access. I am working on an upgrade of JLine > inside the `jdk.internal.le` module, and I would like to replace the current > native

Re: RFR: 8319332: Security properties files inclusion [v6]

2024-03-04 Thread Francisco Ferrari Bihurriet
> The implementation of this proposal is based on the requirements, > specification and design choices described in the [JDK-8319332] ticket and > its respective CSR [JDK-8319333]. What follows are implementation notes > organized per functional component, with the purpose of assisting to naviga

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Sean Mullan
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject d

Re: RFR: 8319332: Security properties files inclusion [v5]

2024-03-04 Thread Francisco Ferrari Bihurriet
On Mon, 8 Jan 2024 18:59:54 GMT, Francisco Ferrari Bihurriet wrote: >> The implementation of this proposal is based on the requirements, >> specification and design choices described in the [JDK-8319332] ticket and >> its respective CSR [JDK-8319333]. What follows are implementation notes >>

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Sean Mullan
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject d

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Sean Mullan
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject d

Re: RFR: 8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs [v3]

2024-03-04 Thread Sean Mullan
On Tue, 30 Jan 2024 21:58:28 GMT, Weijun Wang wrote: >> This code change adds an alternative implementation of user-based >> authorization `Subject` APIs that doesn't depend on Security Manager APIs. >> Depending on if the Security Manager is allowed, the methods store the >> current subject d

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Erik Joelsson
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote: > Currently, JDK modules load by the bootstrap and platform ClassLoaders are > automatically granted the native access. I am working on an upgrade of JLine > inside the `jdk.internal.le` module, and I would like to replace the current > native

Re: RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Maurizio Cimadamore
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote: > Currently, JDK modules load by the bootstrap and platform ClassLoaders are > automatically granted the native access. I am working on an upgrade of JLine > inside the `jdk.internal.le` module, and I would like to replace the current > native

RFR: 8327218: Add an ability to specify modules which should have native access enabled

2024-03-04 Thread Jan Lahoda
Currently, JDK modules load by the bootstrap and platform ClassLoaders are automatically granted the native access. I am working on an upgrade of JLine inside the `jdk.internal.le` module, and I would like to replace the current native bindings with FFM-based bindings (which are now somewhat pro

RFR: 8327208: Remove unused method java.util.jar.Manifest.make72Safe

2024-03-04 Thread Eirik Bjørsnøs
Please review this cleanup PR which suggests we remove the package-private, unused and deprecated method `java.util.jar.Manifest.make72Safe`. This method was marked deprecated after a cleanup/refactoring in [JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall out of use.

Re: RFR: 8327182: Move serverAlias into the loop

2024-03-04 Thread Guoxiong Li
On Mon, 4 Mar 2024 03:58:18 GMT, John Jiang wrote: > In method `X509Authentication::createServerPossession`, it looks unnecessary > to define variable `serverAlias` out of the for-loop. > It may be better to move `serverAlias` into that loop to narrow down the > scope. Marked as reviewed by gl

Re: RFR: 8327182: Move serverAlias into the loop

2024-03-04 Thread Guoxiong Li
On Mon, 4 Mar 2024 08:43:33 GMT, John Jiang wrote: >>> If an alias can be used by the subsequent iterations, that looks a bug. >> >> Looks like a bug. So your patch is a bug fix instead of simple cleanup. >> Should we change the title of this issue or/and provide a test case? > > At the beginni

Re: RFR: 8327182: Move serverAlias into the loop

2024-03-04 Thread John Jiang
On Mon, 4 Mar 2024 08:26:28 GMT, Guoxiong Li wrote: >> With my understanding, in each iteration, firstly choose an alias from key >> manager with a key type, and then try to get the keys and certificates >> associated with this alias. >> If an alias or its associated keys and certificates have

Re: RFR: 8327182: Move serverAlias into the loop

2024-03-04 Thread Guoxiong Li
On Mon, 4 Mar 2024 06:57:23 GMT, John Jiang wrote: > If an alias can be used by the subsequent iterations, that looks a bug. Looks like a bug. So your patch is a bug fix instead of simple cleanup. Should we change the title of this issue or/and provide a test case? - PR Review Com