On Mon, 17 Jun 2024 19:56:38 GMT, Sean Mullan wrote:
> AFAICT, the only test modified in this PR that actually enables a Security
> Manager is test/jdk/javax/management/security/AuthorizationTest.java. Is that
> test sufficient to exercise the code changes in this PR when an SM is enabled?
Whi
On Mon, 17 Jun 2024 10:03:27 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 Fri, 14 Jun 2024 15:26:54 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 Fri, 14 Jun 2024 14:00:58 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 1461:
>>
>>> 1459: throw rte;
>>> 1460: } else {
>>> 1461: throw new PrivilegedActionException(e);
On Fri, 14 Jun 2024 12:41:20 GMT, Kevin Walls wrote:
> Does noPermissionsACC add anything?
I don't know. My principal for this code change is that nothing is changed for
the SM-is-allowed case.
-
PR Comment: https://git.openjdk.org/jdk/pull/19624#issuecomment-2168203868
On Thu, 13 Jun 2024 20:54:25 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 18:04:45 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 1301:
>>
>>> 1299: }
>>> 1300: };
>>> 1301: if (acc == null) {
>>
>> This is a comment to all the
On Tue, 11 Jun 2024 16:18:23 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, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Wed, 17 Jan 2024 23:41:53 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
>
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
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull reques
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull reque
On Wed, 13 Mar 2024 19:53:40 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> revert changes to MBeanServerFileAccessController.java
>
> test/j
On Thu, 7 Mar 2024 22:00:13 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with three additional
> commits since the
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull reques
On Tue, 5 Mar 2024 16:49:01 GMT, Kevin Walls wrote:
>> Do you know where the subject is set? If it's set by a `doAs` call then it
>> will co-operate with `current()` no matter if SM is allowed. I tried to
>> search in the whole module and cannot find a `doAs` call. If it is also
>> through `Su
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull reque
On Tue, 5 Mar 2024 11:36:53 GMT, Kevin Walls wrote:
>> I think we need @kevinjwalls or @dfuch to help advise on this.
>
> Right, this does not depend on the SM. All we need to do is get the Subject.
> This method implements the basic monitor (readonly) and control (readwrite)
> access.
> acces
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull req
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/ja
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/Subj
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/
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/class
On Tue, 30 Jan 2024 16:41:28 GMT, Weijun Wang wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
>> line 307:
>>
>>> 305: AccessController.doPrivileged(new PrivilegedAction<>() {
>>&g
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the
On Tue, 30 Jan 2024 16:45:34 GMT, Weijun Wang wrote:
>> OK - things seem to be a bit convoluted here and some pieces might be
>> missing. I suspect that what needs to be done is more complicated:
>>
>> `RMIConnectionImpl` sets up an ACC and calls doPrivileged w
of the current `AccessControlContext`, then instead of storing the
> previous `AccessControlContext` object and passing it into `getSubject` to
> get the "previous" subject, the application should store the `current()`
> return value directly.
Weijun Wang has updated the pull reques
On Tue, 30 Jan 2024 13:56:53 GMT, Daniel Fuchs 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
On Tue, 30 Jan 2024 14:19:02 GMT, Daniel Fuchs wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
>> line 349:
>>
>>> 347: @SuppressWarnings("removal")
>>> 348: private Subject getSubject() {
>>> 349: return Subject.current();
>>
>
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 for deta
On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu wrote:
>> Please review this PR which updates the JDK's localized resources since the
>> previous L10n translation drop (1/26).
>>
>> To help with reviewing the changes, @jonathan-gibbons created a tool which
>> displays the localized changes next to
On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov wrote:
>> I didn't ask to revert the change. It's
>> `s/TARGET_OS_MAC/defined(__APPLE__)/`.
>
> This is rarely used in the code and is not the essence of the current changes.
> If you introduce such changes, then throughout the code.
> Moreover, thi
On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov wrote:
>> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
>>
>>> 45:
>>> 46: // Condition was copied from
>>> 47: //
>>> Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>>
On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov wrote:
>> When using the clang compiler to build OpenJDk on Linux, we encounter
>> various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional
> commit sin
On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes
On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file.
>> (Excluding the Unicode space and tab sequence). The conversion was done
>> using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in t
On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revisi
On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties
>> line 113:
>>
>>> 111:
>>> doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528
>>> @inher
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revisi
On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote:
>> Open l10n drop. Files have been updated with translated versions. Whitespace
>> tool has been ran on files.
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revisi
On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen wrote:
>> Yes, you can replace all "存在安全风险" (that is not after ""被视为") to "被视为存在安全风险".
>>
>> There are also similar usages in
>> `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`.
>
> Hi @wangweij , I believe I fixed the o
On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen wrote:
>> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
>> line 75:
>>
>>> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"},
>>> //-genseckey
>>> 74: {"key.algorithm.weak", "%1$s \u4F7F\u752
On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote:
>> Open l10n drop
>> All tests passed
>
> Damon Nguyen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert double quote as well
src/java.base/share/classes/sun/security/tools/keytool
On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote:
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increas
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increas
On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote:
>> Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`?
>
> This is correct.
> AccessBridge.h is published with the include/header files of the JDK and
> anyone reading it there can't exactly make use of "../"
Thanks @pr
On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> http -> https
>
> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line
> 34:
>
>> 32: * the follo
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and remov
ls sets will trigger a
> `NullPointerException`.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
more comment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9348/files
- new: https://git.openjdk.org/jdk/pull/9348
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
ls sets will trigger a
> `NullPointerException`.
Weijun Wang has updated the pull request incrementally with two additional
commits since the last revision:
- null not in code
- sean comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9348/files
- new: https://git.
On Mon, 11 Jul 2022 20:09:31 GMT, Sean Mullan wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and removing a null from
>> the `Sub
On Mon, 11 Jul 2022 18:49:26 GMT, Sean Mullan wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and removing a null from
>> the `Sub
Add null-checks in all `LoginModule` implementations. It's possible that an
application calls `logout` after a login failure, where most internal variables
for principals and credentials are null and removing a null from the
`Subject`'s principals and credentials sets will trigger a
`NullPointe
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
60 matches
Mail list logo
