On Thu, 7 Nov 2024 20:09:59 GMT, Artur Barashev wrote:
>> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java
>> line 126:
>>
>>> 124: }
>>> 125:
>>> 126: Pattern p = patternCache.get(pattern);
>>
>> I think you want to use `putIfAbsent` her
On Tue, 5 Nov 2024 15:51:58 GMT, Weijun Wang wrote:
>> When an exception happens inside these stringToKey() methods, it returns a
>> null. This would lead to unexpected NPE some time in the future.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the
On 11/7/24 2:06 PM, Mikael Sterner wrote:
Hi!
I miss a more complete discussion in JEP 486 about the secondary effects
of having a security manager installed other than achieving sandboxing,
if they should be possible to achieve when a security manager cannot be
installed or if they should be
On Wed, 6 Nov 2024 21:27:05 GMT, Artur Barashev wrote:
>> The current syntax of the jdk.tls.disabledAlgorithms makes it difficult to
>> disable algorithms that affect both the key exchange and authentication
>> parts of a TLS cipher suite. For example, if you add "RSA" to the
>> jdk.tls.disabl
On Thu, 7 Nov 2024 04:44:25 GMT, Prasadrao Koppula wrote:
>> Using SharedSecrets, I attempted to expose FileInputStream::path
>> information. After implementing the fix, I validated the startup performance
>> tests. Observed no consistent pattern of performance drops or gains, can
>> disregard
On Tue, 5 Nov 2024 17:40:46 GMT, Artur Barashev wrote:
>> The current syntax of the jdk.tls.disabledAlgorithms makes it difficult to
>> disable algorithms that affect both the key exchange and authentication
>> parts of a TLS cipher suite. For example, if you add "RSA" to the
>> jdk.tls.disabl
On Tue, 5 Nov 2024 17:40:46 GMT, Artur Barashev wrote:
>> The current syntax of the jdk.tls.disabledAlgorithms makes it difficult to
>> disable algorithms that affect both the key exchange and authentication
>> parts of a TLS cipher suite. For example, if you add "RSA" to the
>> jdk.tls.disabl
On Tue, 5 Nov 2024 04:04:45 GMT, Ben Perez wrote:
>> Java implementation of ML-KEM, the [FIPS
>> 203](https://csrc.nist.gov/pubs/fips/203/final) post-quantum KEM scheme.
>> Depends on https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request incrementally with one add
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 Tue, 5 Nov 2024 04:04:45 GMT, Ben Perez wrote:
>> Java implementation of ML-KEM, the [FIPS
>> 203](https://csrc.nist.gov/pubs/fips/203/final) post-quantum KEM scheme.
>> Depends on https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request incrementally with one add
On Mon, 4 Nov 2024 22:39:05 GMT, Archie Cobbs wrote:
> But I think what you're really asking is: how & why they were put there in
> the first place? And how over time did they somehow became no longer
> necessary?
Yes.
> That's a great question, but I don't have any answers because these chan
On Mon, 4 Nov 2024 21:11:44 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert changes to imported sour
On Sun, 3 Nov 2024 03:08:12 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
On Tue, 1 Oct 2024 08:51:29 GMT, Fernando Guallini
wrote:
> The test
> **sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java** may
> fail with the following exception:
>
>
> test PreserveRawManifestEntryAndDigest.testNameImmediatelyContinued(): failure
> java.lang.AssertionEr
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 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 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 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 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 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
>
On Wed, 30 Oct 2024 18:12:30 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Wed, 30 Oct 2024 14:48:46 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Wed, 30 Oct 2024 13:09:26 GMT, Matthew Donovan wrote:
>> In this PR, I removed hard-coded security providers and replaced them with a
>> system property, test.provider.name. If the property is not specified, the
>> provider originally used in the test is used:
>>
>> Cipher c = Cipher.getIns
On Tue, 29 Oct 2024 08:15:58 GMT, Andrey Turbanov wrote:
> `Hashtable` doesn't allow `null` values.
> It means we can replace containsKey+get with get+null check.
> It's clearer and a bit faster.
Looks fine.
-
Marked as reviewed by mullan (Reviewer).
PR Review: https://git.openjdk
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, 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: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 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
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 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 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 Mon, 28 Oct 2024 12:29:07 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 Thu, 24 Oct 2024 15:01:44 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, 25 Oct 2024 20:59:07 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 Thu, 24 Oct 2024 15:04:08 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, 25 Oct 2024 20:31:40 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
>>
>>> 1: /*
>>
>> I think we can delete this test. It verifies that popup menus are displayed
>> in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for
On Fri, 25 Oct 2024 18:52:24 GMT, Alexey Ivanov wrote:
>> @aivanov-jdk
>> On macOS, popup is shifted up and does not cover the taskbar even without
>> SM.
>>
>>> The updated test bug6694823.java works correctly on Windows and displays
>>> its popup over the Windows taskbar — it is expected.
On Fri, 25 Oct 2024 23:20:02 GMT, Alexander Zuev wrote:
>> Right the JBS is about SM & SecurityException, but the test was repurposed
>> to check if InvalidMidiDataException is thrown and to test this case for
>> code coverage (when it was initially reviewed).
>> I can update the test summary
On Thu, 24 Oct 2024 15:57: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, 25 Oct 2024 23:58:33 GMT, Weijun Wang wrote:
>>> The class spec still mentions "permissions which are retrieved by the
>>> system policy by default". Shall we remove it?
>>
>> Yes I think we can remove that text.
>>
>>> Also, getPermissions always returns an empty Permissions object,
On Fri, 25 Oct 2024 21:02:37 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/security/Policy.java line 90:
>>
>>> 88: * and subject to removal in a future release. Consequently, this
>>> class
>>> 89: * is also depreca
On Fri, 25 Oct 2024 20:48:14 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
>>
>>> 30:
>>> 31: /**
>>> 32: * AccessControlContext was used with a SecurityManager for access
>>> contro
On Fri, 25 Oct 2024 23:45:26 GMT, Weijun Wang wrote:
>> I'm not sure what would be a useful message. All the `SecurityManager` check
>> methods throw a `SecurityException` with no message. We had to specify
>> something here because `AccessControlException` doesn't have a no-args ctor.
>
> I se
On Thu, 24 Oct 2024 19:33:23 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:34:31 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/security/Security.java line 489:
>>
>>> 487:
>>> 488: /**
>>> 489: * Adds a provider to the next position available..
>>
>> Two periods at t
On Wed, 23 Oct 2024 13:07:49 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java
>> line 342:
>>
>>> 340: throws Exception
>>> 341: {
>>> 342: action.run();
>>
>> testWithNoSecurityManager was previously a sanity check, the t
On Tue, 22 Oct 2024 20:55:30 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
>>
>>> 47: SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>>> 48: }
>>> 49:
>>
>> Is there any need to catch the exception and rethrow Runtime
On Tue, 22 Oct 2024 21:01:24 GMT, Harshitha Onkar wrote:
>> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
>>
>>> (failed to retrieve contents of file, check the PR for context)
>> I guess we can test this without SM since it tests SwingLazyValue?
>
> I believe I had removed thi
On Fri, 25 Oct 2024 13:44:56 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
>>
>>> 38: *
>>> 39: * @apiNote
>>> 40: * This permission cannot be used for controlling access to resources
>>>
On Mon, 21 Oct 2024 22:57:10 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 Tue, 22 Oct 2024 20:20:16 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 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Tue, 15 Oct 2024 22:09:59 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
>>
>>> 665: * @param codesource the codesource
>>> 666: * @throwsNullPointerException if {@code codesource} is {@code
>>
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 Fri, 25 Oct 2024 19:44:54 GMT, Weijun Wang 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
> about dynamic permissions. On the other han
On Tue, 22 Oct 2024 20:23:52 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 97 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into J
On Fri, 25 Oct 2024 12:16:55 GMT, Matthew Donovan wrote:
> I changed the name of the bug and PR. Yes there are cases where a test has
> more than one hardcoded provider.
How would that work then if the property only allows you to specify one
provider?
-
PR Comment: https://git.op
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
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 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
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, 22 Oct 2024 15:48:54 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8336665
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> more precise comment
Marked as reviewed by mullan (Reviewer).
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
On Tue, 22 Oct 2024 21:36:06 GMT, Mandy Chung wrote:
> Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.
Thanks for the comprehensive review. I have incorporated all of your comments
except for removing the enum from
`java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java`
On Wed, 23 Oct 2024 12:14:24 GMT, Alan Bateman 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, 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 Tue, 22 Oct 2024 12:51:45 GMT, Mark Powers wrote:
>> test/jdk/sun/security/x509/X509CRLImpl/UnexpectedCCE.java line 46:
>>
>>> 44: // "class sun.security.x509.OIDName cannot be cast
>>> 45: // to class sun.security.x509.X500Name"
>>> 46: byte[] encoded_1 = Base64.getDe
On Mon, 21 Oct 2024 15:28:47 GMT, Ben Perez wrote:
>> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
>> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
>> https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request increme
On Tue, 15 Oct 2024 18:41:59 GMT, Ben Perez wrote:
>> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
>> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
>> https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request increme
On Mon, 21 Oct 2024 17:12:04 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8336665
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> more precise exception message
test/jdk/sun/security/x509/X509CRLImpl/Unexp
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 18:47:44 GMT, Matthew Donovan wrote:
> In this PR, I removed hard-coded security providers and replaced them with a
> system property, test.provider.name. If the property is not specified, the
> provider originally used in the test is used:
>
> Cipher c = Cipher.getInstance
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 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 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 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 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 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
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, 8 Oct 2024 15:32:55 GMT, Mark Powers wrote:
>> Fixed.
>
> Does the test need to be modified to test for more than one name? I could go
> either way.
Are you able to easily create test CRLs with more than one entry? If not, I
think the existing test is ok.
-
PR Review Comm
On Tue, 8 Oct 2024 15:32:19 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8336665
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> allow more than one name
src/java.base/share/classes/sun/security/x509/X509C
On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang wrote:
>> In general, I tried to remove any text from the Permission classes that
>> described behavior if the permissions were granted. So in the above I
>> removed the text because it had words like "protect" and "accessed" and
>> referred to `co
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 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 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 Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs 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 c
On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung 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, 15 Oct 2024 21:17:37 GMT, Phil Race 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 chan
On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs 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 c
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
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 Mon, 14 Oct 2024 13:53:10 GMT, Weijun Wang wrote:
> Previous code change for
> [JDK-8340327](https://bugs.openjdk.org/browse/JDK-8340327) changed the
> display names for all keys with a `NamedParameterSpec` to be the parameter
> set name. This test is not updated.
>
> I understand the curr
On Fri, 11 Oct 2024 19:52:32 GMT, Weijun Wang wrote:
>> To prepare for new PQC algorithms like ML-KEM and ML-DSA where there are
>> only named standardized parameter sets, a common framework is introduced.
>>
>> A example of EdDSA implementation using this framework is included as a test.
>
> W
On Fri, 11 Oct 2024 16:34:51 GMT, Weijun Wang wrote:
>> To prepare for new PQC algorithms like ML-KEM and ML-DSA where there are
>> only named standardized parameter sets, a common framework is introduced.
>>
>> A example of EdDSA implementation using this framework is included as a test.
>
> W
On Wed, 9 Oct 2024 16:22:13 GMT, Weijun Wang wrote:
> Switch to `ExceptionCheck`.
>
> This is a part of an umbrella bug [JDK-8341542 JNI uses of
> ExceptionOccurred() treated as if function returns a
> bool](https://bugs.openjdk.org/browse/JDK-8341542).
Marked as reviewed by mullan (Reviewer)
1 - 100 of 853 matches
Mail list logo
