On Tue, 29 Jul 2025 21:00:44 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Tue, 29 Jul 2025 19:19:15 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/X509KeyManager/CertChecking.java line 128:
>>
>>> 126: // --- Usage and expired test cases --
>>> 127:
>>> 128: // Both should fail with no usages at all
>>
>> Clarify what you mean by "Both sh
On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Tue, 29 Jul 2025 15:11:45 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Tue, 29 Jul 2025 14:47:29 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java
>> line 1:
>>
>>> 1: /*
>>
>> Needs copyright update.
>
> The year is set to 2025 already, maybe something else needs to be changed?
> Please elab
On Wed, 23 Jul 2025 21:20:49 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Mon, 14 Jul 2025 19:19:47 GMT, Sean Mullan wrote:
> `SocketPermission` should be deprecated for removal as has already been done
> for many other `Permission` subclasses. However, `CodeSource.implies()` has
> specification dependencies on `SocketPermission` which requires a
On Thu, 17 Jul 2025 16:11:00 GMT, Jaikiran Pai wrote:
>>> Hello Sean, the original text in `SocketPermission.implies()` lists these 2
>>> rules separately, as follows:
>>>
>>> > If this object was not initialized with a single IP address, and one
>>> > of this object's IP addresses equals one
On Thu, 17 Jul 2025 12:33:23 GMT, Jaikiran Pai wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add @SuppressWarnings("removal") to SocketPermissionCollection.
>
> s
On Thu, 17 Jul 2025 12:41:36 GMT, Jaikiran Pai wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add @SuppressWarnings("removal") to SocketPermissionCollection.
>
> test/jdk/ja
On Thu, 17 Jul 2025 12:43:52 GMT, Jaikiran Pai wrote:
> On a related note, I did a brief search for SocketPermission usages in the
> JDK and while doing so, I noticed that there's a
> `sun.security.util.SecurityConstants` class which has a lot of leftover
> unused security permission related c
e behavior is
> consistent.
>
> Note that we may also eventually deprecate `CodeSource.implies` for removal
> but that requires more investigation.
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Add @SuppressWarnings(&
`SocketPermission` should be deprecated for removal as has already been done
for many other `Permission` subclasses. However, `CodeSource.implies()` has
specification dependencies on `SocketPermission` which requires additional
changes to decouple those dependencies.
This change deprecates `So
On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev wrote:
>> SunX509 key manager should support the same certificate checks that are
>> supported by PKIX key manager.
>>
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeySto
On Fri, 6 Jun 2025 16:19:07 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
>>
>>> 1: /*
>>
>> I am trying to figure out when the algorithm constraints are enabled, why
>> the key isn't being selected. I don't see anywhere that you are s
On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev wrote:
>> When the deafult SunX509KeyManagerImpl is being used we are in violation of
>> TLSv1.3 RFC spec because we ignore peer supported certificate signatures
>> sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> h
On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev wrote:
>> When the deafult SunX509KeyManagerImpl is being used we are in violation of
>> TLSv1.3 RFC spec because we ignore peer supported certificate signatures
>> sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> h
On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev wrote:
>> When the deafult SunX509KeyManagerImpl is being used we are in violation of
>> TLSv1.3 RFC spec because we ignore peer supported certificate signatures
>> sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> h
On Tue, 3 Jun 2025 16:03:09 GMT, Matthew Donovan wrote:
> As a constructor, the code would look like this
Ah, I see. Well technically you could call the set methods from the ctor but
you would get `this-escape` compiler warnings, which you probably want to avoid.
> > it also means I can't us
On Tue, 3 Jun 2025 13:15:33 GMT, Matthew Donovan wrote:
> I think the way it currently is follows the builder pattern better. All of
> the 'set' methods return `this` which means if I change this method to a
> constructor, I'd have to duplicate the "set" code from all those methods.
I'm not su
On Fri, 18 Apr 2025 14:58:41 GMT, Matthew Donovan wrote:
>> This PR updates the CertificateBuilder with a new method that creates a new
>> instance with common fields (subject name, public key, serial number,
>> validity, and key uses) filled-in. One test, IPIdentities.java, is updated
>> to s
On Fri, 30 May 2025 14:50:28 GMT, Michael McMahon wrote:
>> src/java.base/share/conf/security/java.security line 1282:
>>
>>> 1280: # Exception messages may include potentially sensitive information
>>> such as file
>>> 1281: # names, host names, or port numbers. By default, socket related
>>>
On Fri, 30 May 2025 10:44:11 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Fri, 30 May 2025 06:55:07 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to add an
>> `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader`
>> to explain the current implementation of these constructors? This addresses
>> ht
On Thu, 29 May 2025 14:19:08 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to add an
>> `@apiNote` on the constructors of `URLClassLoader` and `SecureClassLoader`
>> to explain the current implementation of these constructors? This addresses
>> ht
On Thu, 15 May 2025 19:41:16 GMT, Weijun Wang wrote:
>> From a previous comment:
>>
>> IIUC, the exported keying material can be used for any purpose or algorithm,
>> so we really can't make an good educated guess what it might be. They could
>> be Keys (Ciphers), byte array/value challenges,
On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore wrote:
>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
>> respectively.
>>
>> CSR is underway.
>>
>> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
>> API (jck:api/java_security jck:
On Wed, 14 May 2025 04:03:44 GMT, Bradford Wetmore wrote:
>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
>> respectively.
>>
>> CSR is underway.
>>
>> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
>> API (jck:api/java_security jck:
On Tue, 13 May 2025 14:01:10 GMT, Artur Barashev wrote:
> > It is nice to refactor the common code for algorithm constraints checking
> > into a new class, `X509KeyManagerConstraints.java`, used by both
> > `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a
> > new syst
On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254:
>>
>>> 252: *
>>> 253: * @return a byte array of size {@code length} that contains the
>>> EKM
>>> 254: * material, or null if the deri
On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore wrote:
>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
>> respectively.
>>
>> CSR is underway.
>>
>> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
>> API (jck:api/java_security jck:
On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs wrote:
>> Please find her a patch that deprecate networking permission classes for
>> removal. The method `URL::getPermission` now serves little purpose and is
>> also deprecated. That method was overridden in subclasses and specified to
>> return
On Mon, 12 May 2025 15:21:46 GMT, Daniel Fuchs wrote:
>> Ah - good point - I will double check.
>
> Yes - it is needed as well. Apparently if you override a deprecated method
> you need both `@Deprecated` and `@SuppressWarning`:
>
>
> src/java.base/share/classes/java/net/HttpURLConnection.java
On Fri, 9 May 2025 21:38:07 GMT, Bradford Wetmore wrote:
>> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE
>> respectively.
>>
>> CSR is underway.
>>
>> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK
>> API (jck:api/java_security jck:a
On Thu, 8 May 2025 16:10:18 GMT, Daniel Fuchs wrote:
>> Please find her a patch that deprecate networking permission classes for
>> removal. The method `URL::getPermission` now serves little purpose and is
>> also deprecated. That method was overridden in subclasses and specified to
>> return
On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev wrote:
>> The current key manager is SunX509, which is configured in the
>> java.security. The SunX509 algorithm does not check the local certificate.
>> The PKIX algorithm should be preferred now so that the default key manager
>> could be more
On Thu, 24 Apr 2025 18:30:00 GMT, Artur Barashev wrote:
>> The current key manager is SunX509, which is configured in the
>> java.security. The SunX509 algorithm does not check the local certificate.
>> The PKIX algorithm should be preferred now so that the default key manager
>> could be more
On Thu, 24 Apr 2025 16:59:45 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a PR for the implementation of JEP [JDK-8291976: HTTP/3 for
>> the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8291976).
>>
>> The CSR can be viewed at [JDK-8350588: Implement HTTP/3 for the HTTP Clien
On Wed, 23 Apr 2025 13:07:31 GMT, Artur Barashev wrote:
>> A lot of (existing) HttpClient tests in `test/jdk/java/net/httpclient`
>> currently use this `SimpleSSLContext` construct to read the `testkeys`
>> keystore that's available in the JDK repo's test directory. Moving to a
>> dynamically
On Thu, 17 Apr 2025 01:36:30 GMT, Artur Barashev wrote:
>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>>
>>
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a
On Wed, 16 Apr 2025 14:57:20 GMT, Artur Barashev wrote:
>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>>
>>
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a
On Mon, 14 Apr 2025 15:19:18 GMT, Artur Barashev wrote:
>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>>
>>
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a
On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.UnresolvedPermission`,
> `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthP
in these classes was reused as the deprecation text.
>
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
Sean Mullan has updated the pull request incrementally with one additional
commit since the last revision:
Fix build error; add removal annotation.
-
Changes:
On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs wrote:
>> Now that the Security Manager is permanently disabled, the following
>> permission classes in the core libraries area can be deprecated for removal
>> as they are no longer useful: FilePermission, LinkPermission,
>> LoggingPermission, Prop
in these classes was reused as the deprecation text.
>
> Release Note: https://bugs.openjdk.org/browse/JDK-8353680
Sean Mullan has updated the pull request incrementally with three additional
commits since the last revision:
- Merge branch 'JDK-8348967' of gh:seanjmullan/jd
On Fri, 4 Apr 2025 14:49:36 GMT, David M. Lloyd wrote:
> `AllPermission` is an integral concept of permission sets, and thus we would
> be obliged to create our own if the JDK one disappeared, causing
> compatibility problems due to the class moving to a new package from the
> point of view of
On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLP
Please review this change to terminally deprecate the following security
related permission classes: `java.security.AllPermission`,
`java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
`javax.security.auth.AuthPermission`,
`javax.security.auth.PrivateCredentialPermission`,
`jav
On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote:
> This change adds an API note to these methods recommending that the caller
> should perform further validation steps on the code signers that signed the
> JAR file, such as validating the code signer's certificate chain, and
On Fri, 14 Feb 2025 13:57:12 GMT, Sean Mullan wrote:
> > Hello Sean, given the assertable change to the API documentation of
> > `java.net.JarURLConnection.getCertificates()`, which now specifies the
> > order of the returned certificates, would this require a CSR?
>
>
On Fri, 14 Feb 2025 07:33:58 GMT, Jaikiran Pai wrote:
> Hello Sean, given the assertable change to the API documentation of
> `java.net.JarURLConnection.getCertificates()`, which now specifies the order
> of the returned certificates, would this require a CSR?
Yes, I think we should. I'll do t
This change adds an API note to these methods recommending that the caller
should perform further validation steps on the code signers that signed the JAR
file, such as validating the code signer's certificate chain, and determining
if the signer should be trusted. There was already a similar wa
On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which adds the `final` modifier to non-subclassable
> classes in `java.base`.
>
> The classes were identified using an automated analysis. See CSR for details.
>
> Besides simply adding the `final` access modifier,
On Mon, 13 Jan 2025 13:36:53 GMT, Sean Mullan wrote:
> Some additional removal of calls to SM APIs from security library tests. One
> test is removed since it is no longer an issue.
This pull request has now been integrated.
Changeset: a49f8332
Author: Sean Mullan
URL:
> Some additional removal of calls to SM APIs from security library tests. One
> test is removed since it is no longer an issue.
Sean Mullan has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains two commits:
- Merge
- Initial c
Some additional removal of calls to SM APIs from security library tests. One
test is removed since it is no longer an issue.
-
Commit messages:
- Initial changes.
Changes: https://git.openjdk.org/jdk/pull/23070/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23070&range=00
On Thu, 2 Jan 2025 14:41:48 GMT, Sean Mullan wrote:
> Periodically, we review the security algorithm requirements to see if new
> algorithms should be added or existing ones should be removed. The
> requirements are intended to improve interoperability across different SE
> implem
hat are required by CNSA 1.0, which was added in JDK 19:
> https://bugs.openjdk.org/browse/JDK-8267319.
>
> No required algorithms or protocols are being removed at this time.
>
> See the CSR for the complete list of new requirements:
> https://bugs.openjdk.org/bro
hat are required by CNSA 1.0, which was added in JDK 19:
> https://bugs.openjdk.org/browse/JDK-8267319.
>
> No required algorithms or protocols are being removed at this time.
>
> See the CSR for the complete list of new requirements:
> https://bugs.openjdk.org/bro
On Thu, 2 Jan 2025 23:05:53 GMT, Bernd wrote:
>> Periodically, we review the security algorithm requirements to see if new
>> algorithms should be added or existing ones should be removed. The
>> requirements are intended to improve interoperability across different SE
>> implementations by re
Periodically, we review the security algorithm requirements to see if new
algorithms should be added or existing ones should be removed. The requirements
are intended to improve interoperability across different SE implementations by
requiring a set of commonly used algorithms. The algorithms ar
On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-only --pretty=format: | sort -u >
On Mon, 2 Dec 2024 16:11:57 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which removes usages of
>> SecurityManager related APIs and some leftover related to SecurityManager
>> changes?
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these
>>
On Thu, 21 Nov 2024 18:29:24 GMT, Sean Mullan wrote:
> Now that JEP 486 has been integrated, the `javax.net.ssl` and
> `sun.security.ssl` package implementation dependencies on
> `System.getSecurityManager`, `AccessController.doPrivileged` and
> `AccessControlContext` ca
On Fri, 22 Nov 2024 12:53:14 GMT, Sean Coffey wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert @see text in TrustManagerFactory.
>> Remove sun.security.action.OpenFileInputS
On Thu, 21 Nov 2024 23:21:35 GMT, Alexey Bakhtin wrote:
>> Why do you think it is an API change? It produces the exact same javadoc.
>> Technically it's not related, but minor cleanup changes like this are ok in
>> my opinion.
>
> Yes, you are right, javadoc is the same. So, not entirely correc
ntrol contexts anymore, which means it can store the keys as Strings
> instead of one that combines the key and the access control context.
> 3. `sun.security.ssl.TransportContext` does not need to capture the access
> control context anymore.
Sean Mullan has updated the pull request
On Thu, 21 Nov 2024 17:36:03 GMT, Sean Mullan wrote:
> Some additional text in two `javax.net.ssl` APIs related to access control
> context was missed as part of JEP 483. This behavior no longer applies now
> that the Security Manager is permanently disabled and has been removed.
On Thu, 21 Nov 2024 21:55:54 GMT, Alexey Bakhtin wrote:
>> Now that JEP 486 has been integrated, the `javax.net.ssl` and
>> `sun.security.ssl` package implementation dependencies on
>> `System.getSecurityManager`, `AccessController.doPrivileged` and
>> `AccessControlContext` can be removed.
>>
Now that JEP 486 has been integrated, the `javax.net.ssl` and
`sun.security.ssl` package implementation dependencies on
`System.getSecurityManager`, `AccessController.doPrivileged` and
`AccessControlContext` can be removed.
Most of the changes are straightforward: removal of code calling
`Syst
On Thu, 21 Nov 2024 18:12:20 GMT, Daniel Fuchs wrote:
> Looks reasonable. Good catch. I guess you will need a small CSR for those
> changes?
Yes, already approved: https://bugs.openjdk.org/browse/JDK-8344653
-
PR Comment: https://git.openjdk.org/jdk/pull/22299#issuecomment-2491953
Some additional text in two `javax.net.ssl` APIs related to access control
context was missed as part of JEP 483. This behavior no longer applies now that
the Security Manager is permanently disabled and has been removed.
The implementation changes associated with this will be posted in a separa
On Tue, 19 Nov 2024 01:17:55 GMT, Brian Burkhalter wrote:
> Expunge the use of the `SecurityManager`, `AccessController`, and the like
> from the `jdk.sctp` module.
src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpChannelImpl.java line 1085:
> 1083: }
> 1084:
> 1085: @SuppressWarnings({"
On Tue, 19 Nov 2024 16:21:11 GMT, Brian Burkhalter wrote:
>> Expunge the use of the `SecurityManager`, `AccessController`, and the like
>> from the `jdk.sctp` module.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 834
On Tue, 19 Nov 2024 17:01:12 GMT, Brian Burkhalter wrote:
>> Expunge the use of the `SecurityManager`, `AccessController`, and the like
>> from the `jdk.sctp` module.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 834
On Fri, 15 Nov 2024 11:37:55 GMT, Jaikiran Pai wrote:
> > No CSR needed for removing those permissions. There's no visible change to
> > the public APIs, and no behavior change that was not already covered by JEP
> > 486 CSR, since permissions checks have now become deadcode. Or am I missing
>
On Fri, 1 Nov 2024 19:40:03 GMT, Alexey Ivanov 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 200 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan 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 th
On Thu, 24 Oct 2024 17:03:25 GMT, Alexey Ivanov 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&
On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar wrote:
>> It has a value… when it's mentioned with `@see`, the link is present in the
>> *See Also* section, as you can see in the the specification of
>> [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desk
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
>
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
>
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 Tue, 5 Nov 2024 18:58:22 GMT, Sean Mullan 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 d
On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman wrote:
>> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file)
>> is no longer relevant and should be removed too. Thanks for spotting that.
>
> Removed in jep486 branch in sandbox so will get picked up when PR is
> refreshed.
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
>
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, 28 Oct 2024 20:12:27 GMT, Roger Riggs wrote:
> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around
> unnecessarily but otherwise looks fine.
JAXP test comments fixed in
https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d
On Fri, 25 Oct 2024 20:44:25 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 Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang wrote:
>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>>
>>> 1: /*
>>
>> @wangweij It looks like this test can be deleted as it was specifically
>> trying to check that a `SecurityException` wasn't thrown, or did you think
On Tue, 29 Oct 2024 18:35:05 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 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486&#
On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan wrote:
> Comments on `java.security` classes.
>
> Also, I'd like to see some clarifications on what "the installed policy" or
> "the current policy" is. The `ProtectionDomain` mentions this when talking
>
On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan 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 d
On Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar wrote:
>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>>
>>> 1611: * interpreted as a {@code Font} object according to the
>>> 1612: * specification of {@code Font.decode(String)}
>>> 1613: * If the specified prope
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
>
1 - 100 of 186 matches
Mail list logo
