On Fri, 24 May 2024 16:36:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Tue, 28 May 2024 16:27:24 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Mon, 10 Jun 2024 16:52:26 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Tue, 11 Jun 2024 16:51:11 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Sean comments
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
> line 1436:
On Tue, 11 Jun 2024 19:35:18 GMT, Alan Bateman wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove annotations
>
> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
>
>> 82:
>> 83: Syst
On Tue, 11 Jun 2024 21:05:43 GMT, Sean Mullan wrote:
>> src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:
>>
>>> 82:
>>> 83: System.err.println("Warning: jstatd is deprecated for removal
>>> in a future release.");
&g
On Wed, 12 Jun 2024 14:06:39 GMT, Kevin Walls wrote:
>> For the same reason you should be able to just call `Subject.current` in the
>> tests. I don't think you need the `SimpleStandard.useGetSubjectACC` property
>> to toggle the testing of either old or replacement APIs as long as the test
>>
On Wed, 12 Jun 2024 16:11:28 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Mon, 17 Jun 2024 15:59:37 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are needed to not require setting
>> -Djava.security.manager
On Mon, 17 Jun 2024 15:53:19 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 1314:
>>
>>> 1312: return AccessController.doPrivileged(action, acc);
>>> 1313: }
>>> 1314: }
On Fri, 21 Jun 2024 16:11:34 GMT, Rajan Halade wrote:
>> Updated all the tests that depend on external infrastructure services as
>> manual. These tests may fail with external reasons, for instance - change in
>> CA test portal, certificate status updates, or network issues.
>
> Rajan Halade ha
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Thu, 22 Sep 2022 15:57:56 GMT, Sean Coffey wrote:
> New JFR event to record state of initial security properties.
>
> Debug output is also now added for these properties via
> -Djava.security.debug=properties
src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 312:
>
On Wed, 28 Sep 2022 10:06:54 GMT, Sean Coffey wrote:
>> src/jdk.jfr/share/conf/jfr/default.jfc line 713:
>>
>>> 711:
>>> 712:
>>> 713: true
>>
>> The other security related events are not enabled by default. Is this one
>> enabled because it is only generated once? It seems it may
On Wed, 28 Sep 2022 12:52:02 GMT, Sean Coffey wrote:
>> Ok, just so I understand, you want to make sure that if JFR is started after
>> the security properties have already been read, then they are still
>> recorded, right?
>
> Correct - this type of event period (beginChunk) will fire once whe
On Thu, 29 Sep 2022 15:12:06 GMT, Sean Coffey wrote:
>> With event streaming, beginChunk is usually to prefer. Otherwise, a client
>> that monitors the JVM must wait until the first chunk rotation to get the
>> data.
>>
>> That said, we want startup to be quick. There should probably be a comm
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote:
> This is a test only change to remove the granting of
> RuntimePermission("stopThread") from the tests. With Thread.stop changed to
> throw UOE it means there is nothing that requires this permission.
Marked as reviewed by mullan (Reviewer)
On Mon, 3 Oct 2022 10:30:54 GMT, Sean Coffey wrote:
>> New JFR event to record state of initial security properties.
>>
>> Debug output is also now added for these properties via
>> -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with one additional
On Mon, 10 Oct 2022 07:31:29 GMT, Alan Bateman wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Check for 0 security events
>
> src/java.base/share/classes/java/security/ProtectionDomain.java line 76:
>
>> 74: s
On Mon, 10 Oct 2022 19:19:44 GMT, Sean Coffey wrote:
>> Agree, and alternatively, it seems cleaner to add a new SharedSecrets class
>> for `java.security.Security` and remove the dependency on PD.
>
> modified code to have Security class hold the initial properties and provided
> an accessor me
On Tue, 11 Oct 2022 11:28:10 GMT, Sean Coffey wrote:
>> What about creating a new `JavaSecurityPropertiesAccess` class and moving
>> the accessor method there? It seems it would be cleaner to remove the
>> dependency on PD in the long run.
>
> @seanjmullan - I looked at that approach. The
> `
On Thu, 13 Oct 2022 16:06:13 GMT, Sean Coffey wrote:
>> New JFR event to record state of initial security properties.
>>
>> Debug output is also now added for these properties via
>> -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request with a new target base due to a
On Thu, 13 Oct 2022 19:53:27 GMT, Sean Coffey wrote:
>> New JFR event to record state of initial security properties.
>>
>> Debug output is also now added for these properties via
>> -Djava.security.debug=properties
>
> Sean Coffey has updated the pull request incrementally with two additional
On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov
wrote:
> Trivial change, updated jdk problem list.
The `java/security/cert/pkix/policyChanges/TestPolicy.java` and
`java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java`
test failures are already fixed. There is
On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote:
> When referencing an RFC, it might be good to keep the RFC number in the text
> link.
+1.
-
PR: https://git.openjdk.org/jdk/pull/11073
On Wed, 8 Feb 2023 03:42:16 GMT, Mandy Chung wrote:
>> A trivial fix. Convert the use of anonymous inner classes in a few
>> Permission classes to lambdas to work around JDK-8076596, which has been
>> resolved.
>
> Mandy Chung has updated the pull request incrementally with one additional
>
On Wed, 8 Feb 2023 17:58:12 GMT, Mandy Chung wrote:
>> A trivial fix. Convert the use of anonymous inner classes in a few
>> Permission classes to lambdas to work around JDK-8076596, which has been
>> resolved.
>
> Mandy Chung has updated the pull request with a new target base due to a
> me
On Tue, 14 Feb 2023 18:56:29 GMT, Roger Riggs wrote:
>> It can be difficult to find the cause of calls to
>> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
>> runtime exits.
>> The status value and stack trace are logged using the System Logger named
>> `java.lang.
On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote:
> Please review this superficial documentation cleanup that was triggered by
> unrelated analysis of doc comments in JDK API.
>
> The only effect that this multi-area PR has on the JDK API Documentation
> (i.e. the observable effect on the ge
The LDAPCertStore implementation passes Distinguished Names in CRL and
Certificate URLs as Strings to JNDI APIs such as
LdapContext.getAttributes(String), which then treats them as CompositeNames.
This causes issues with URLs that have DNs with forward slashes. These are rare
but compliant wit
On Thu, 23 Feb 2023 16:42:17 GMT, Sean Mullan wrote:
> The LDAPCertStore implementation passes Distinguished Names in CRL and
> Certificate URLs as Strings to JNDI APIs such as
> LdapContext.getAttributes(String), which then treats them as CompositeNames.
> This causes issues wi
On Fri, 10 Mar 2023 15:27:54 GMT, Roger Riggs wrote:
>> Runtime.exec and ProcessBuilder.start methods create a new operating system
>> process with the program and arguments. Many applications configure a
>> logging subsystem to monitor application events. Logging a process start
>> message wi
On Tue, 14 Mar 2023 18:08:08 GMT, Roger Riggs wrote:
>> Runtime.exec and ProcessBuilder.start methods create a new operating system
>> process with the program and arguments. Many applications configure a
>> logging subsystem to monitor application events. Logging a process start
>> message wi
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote:
>> Please review a change to add `@spec` tags (and remove some equivalent
>> `@see` tags) to the main "core-libs" packages in `java.base` module.
>>
>> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and
>> base
[This should be discussed on the security alias so I am copying
security-dev and -bcc-ing core-libs-dev]
As Bernd noted, use of SHA1PRNG should ideally be replaced with a
stronger secure random algorithm, so the impact of this issue is
probably not that significant. That said, I think this is
On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn wrote:
> * This adds additional permissions to the jdk.random module
> (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`)
> * The annotations of the provider classes are now parsed early.
> This avoids putting the parts that
[reposting to core-libs-dev as this is in the JNDI/LDAP component]
Forwarded Message
Subject: Bug JDK-8176553
Date: Fri, 17 Jun 2022 14:23:11 +0200
From: Ricardo Martin Camarero
To: security-...@openjdk.org
Hi!
I decided to send an email to the security-dev email list as lda
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman wrote:
>> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
>> removal, and remove the remaining special handling of ThreadDeath from the
>> JDK.
>>
>> Thread.stop is inherently unsafe and has been deprecated since JDK 1.
On Wed, 27 Jul 2022 13:14:39 GMT, Sean Coffey wrote:
> Add a JFR Event for `java.security.Provider.getService(String type, String
> algorithm)` calls.
Looks good.
-
Marked as reviewed by mullan (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9657
On Mon, 19 Sep 2022 15:25:43 GMT, Sean Coffey wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1293:
>>
>>> 1291: }
>>> 1292:
>>> 1293: if (s != null && SecurityProviderServiceEvent.isTurnedOn()) {
>>
>> Would it be useful to generate an event even for the
On Mon, 19 Sep 2022 17:25:53 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Tue, 20 Sep 2022 17:47:03 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Tue, 20 Sep 2022 18:08:23 GMT, Lance Andersen wrote:
>> Please review this PR which updates the JarInputStream class description to
>> clarify when the Manifest is accessible via JarInputStream::getManifest and
>> JarInputStream::get[Jar]Entry.
>>
>> It is worth noting that with this updat
On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote:
> New functionality in the -XshowSettings menu to display relevant information
> about JDK security configuration
Did you consider only showing the security settings if the "security" option is
specified? Seems like a lot of data to show in t
On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey wrote:
> New functionality in the -XshowSettings menu to display relevant information
> about JDK security configuration
Another possibility is to put this under a new option, ex
`-XshowSecuritySettings`.
-
PR Comment: https://git.open
On Wed, 14 Jun 2023 11:52:35 GMT, Weijun Wang wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Incorporate review comments from Roger and tweak some code
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.ja
On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote:
> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.
The changes in the security classes look fine to me.
-
Marked as reviewed by mullan (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14718#pu
On Tue, 27 Jun 2023 15:06:45 GMT, Sean Coffey wrote:
>> New functionality in the -XshowSettings menu to display relevant information
>> about JDK security configuration
>
> Sean Coffey has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev exclu
On Fri, 7 Jul 2023 19:42:18 GMT, Sean Coffey wrote:
>> New functionality in the -XshowSettings menu to display relevant information
>> about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Harde
On Tue, 5 Sep 2023 11:56:19 GMT, Per Minborg wrote:
>> This PR proposes to read the system environment variable "SystemRoot" using
>> a privileged operation so it will work in the event a default
>> SecurityManager is in place.
>>
>> As the `SecurityManager` is deprecated for removal, no suppo
Please review this fix for a regression in the LDAP CertStore implementation
where a null CRL issuerName in an X509CRLSelector should be treated as a
CertStoreException instead of a NullPointerException.
A new test has been added but requires internal infrastructure so will only be
in the close
On Thu, 15 Feb 2024 17:06:25 GMT, Matthew Donovan wrote:
> In this PR I updated the tests to use the newer
> ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child
> processes.
test/jdk/java/lang/System/SecurityManagerWarnings.java line 135:
> 133: if (prop == n
On Tue, 27 Feb 2024 13:29:07 GMT, Matthew Donovan wrote:
>> In this PR I updated the tests to use the newer
>> ProcessTools.createTestJavaProcessBuilder methods to pass VM options to
>> child processes.
>
> Matthew Donovan has updated the pull request incrementally with one
> additional commit
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
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
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
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
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())
>>> {
>>>
On Tue, 5 Mar 2024 19:56:58 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 di
On Tue, 5 Mar 2024 19:56:58 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 di
On Wed, 20 Mar 2024 14:45:50 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
On Thu, 21 Mar 2024 17:13:46 GMT, Bill Huang wrote:
>> This task addresses an essential aspect of our testing infrastructure: the
>> proper handling and cleanup of temporary files and socket files created
>> during test execution. The motivation behind these changes is to prevent the
>> accumu
On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Tue, 23 Apr 2024 19:26:05 GMT, Lance Andersen wrote:
> > Also, how does one try out these property files? Is there a system property
> > that needs to be set? Can you add more details to the RN on that?
>
> java -Djava.xml.config.file=$JAVA_HOME/conf/jaxp-compat.properties
>
> The property
On Wed, 1 May 2024 22:33:29 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any m
On Sun, 19 May 2024 05:01:32 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>>> jaxp-compat.properties: used to regain compatibility from any
On Mon, 20 May 2024 12:55:24 GMT, Alan Bateman wrote:
>> src/java.xml/share/classes/module-info.java line 444:
>>
>>> 442: *
>>> 443: * Deploying with this configuration prevents processors from
>>> unknowingly making
>>> 444: * outbound network connections to fetch DTDs, or process XML that
On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd wrote:
>> OK
>
> While I disagree with this change on the principle of "the system should
> operate as if no security manager were installed", the workaround for callers
> is actually rather simple:
>
>
> if (System.getSecurityManager() != null
This is the implementation of JEP 486: Permanently Disable the Security
Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
[CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main
changes in the JEP and also includes an apidiff of the specification
On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd wrote:
>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>> it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad
>> idea. Always throwing a `SecurityException` is the s
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Wed, 16 Oct 2024 01:19:15 GMT, Tim Prinzing wrote:
> Adds a JFR event for socket connect operations.
>
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
> check for connect events.
I think this change should have a release note.
-
PR Comment: https
On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan wrote:
>> All JGSS permission classes follow the same style:
>>
>> In `javax.security.auth.kerberos.DelegationPermission`:
>>
>> * This class is used to restrict the usage of the Kerberos
>> * delegation
On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan wrote:
>>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>>> it could unconditionally permit operations that formerly required a
>>> permission check: clearly a bad idea. Always throwing a
On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan wrote:
>> The description for the SecurityException thrown by these methods were
>> adjusted to "if access to the screen is denied by desktop environment". If
>> you bring back the paragraphs that were removed then you
On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan wrote:
>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
>> line 225:
>>
>>> 223: */
>>> 224: public static JMXConnector connect(JMXServiceURL serviceURL)
>
On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman wrote:
>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker`
>> instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending
> SM to call getClassContext is very old code. If that old code is comp
On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman wrote:
> There are a couple of micro benchmarks in test/micro that fork with
> `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be
> examined.
Fixed, will be in next drop. There are a couple of other micro tests that test
th
On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman wrote:
>> **SLF4J** currently depends on this method when logger name mismatch
>> detection is enabled.
>>
>>
>>
>> See also:
>> - https://github.com/qos-ch/slf4j/pul
On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman wrote:
>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were
> adjusted to "if access to the screen is denied by desktop environment". If
> you bring back the paragraphs that were removed then you might
On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan
wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&#
On Mon, 28 Oct 2024 21:00:35 GMT, Sean Mullan wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Tue, 29 Oct 2024 06:32:59 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
>>
>>> 527: * execute the given {@code callable} under the current access
>>> 528: * control context, with the current context class loader as the
>>> 529:
On Mon, 28 Oct 2024 21:02:44 GMT, Sean Mullan wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 175 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' i
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Sun, 27 Oct 2024 00:15:24 GMT, Brent Christian wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' int
On Fri, 25 Oct 2024 19:55:33 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JD
On Fri, 25 Oct 2024 20:07:57 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov wrote:
>> @seanjmullan Can you please advice on some of the following src file javadoc
>> related review comments. Do they need to be handled in this PR? Some of them
>> seem out-of-scope for jep486 PR.
>
> @honkar-jdk I'm inclined to leave it as
On Mon, 21 Oct 2024 22:51:54 GMT, Mandy Chung wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman wrote:
>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>>
>>> 31: * @test
>>> 32: * @summary verify Lookup.revealDirect on a variety of input handles,
>>> with security manager
>>> 33: * @run
>>> main/othervm/policy=jtreg.security.p
ager enabled. After we integrate this JEP,
> those calls will be removed in each area (client-libs, core-libs, security,
> etc).
>
> I don't expect each reviewer to review all the code changes in this JEP.
> Rather, I advise that you only focus on the changes for the area
>
On Mon, 4 Nov 2024 16:09:33 GMT, Weijun Wang wrote:
> The test was mistakenly put in a package as the library class it's testing.
> This is unnecessary since there is no internal field/method it needs access
> to.
Marked as reviewed by mullan (Reviewer).
-
PR Review: https://git.
1 - 100 of 242 matches
Mail list logo
