On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote:
> The various Zip/Jar-file related Java APIs have some long-standing
> differences or peculiarities with respect to the ZIP-file specification or
> compared to other implementations which should be documented in the API-doc.
> This
On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda wrote:
>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But,
> the intent here is to provide more control over the modules with native
> access, not only being
On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>>
On Thu, 22 Feb 2024 18:47:45 GMT, Weijun Wang wrote:
> Add `@since` info. JAAS was included in JDK 1.4 and these classes were all in
> the initial release.
This pull request has now been integrated.
Changeset: a7280d1b
Author:Weijun Wang
URL:
On Thu, 22 Feb 2024 18:47:45 GMT, Weijun Wang wrote:
> Add `@since` info. JAAS was included in JDK 1.4 and these classes were all in
> the initial release.
Marked as reviewed by mullan (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17969#pullrequestreview-1917989848
> 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
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
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Tue, 5 Mar 2024 14:44:29 GMT, Weijun Wang wrote:
>> 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.
>> accessMap maps identity String to Access, and the checkAccess()
On Tue, Mar 5, 2024 at 5:43 PM Alan Bateman wrote:
> > Or are we better off just ignoring this, given the eventual removal of
> > SecurityManager?
> >
> I don't think it's worth spending time on this. There will be a JEP to
> remove the SM "feature" (not the APIs) so methods like this will
On 05/03/2024 16:38, Eirik Bjørsnøs wrote:
:
Or are we better off just ignoring this, given the eventual removal of
SecurityManager?
I don't think it's worth spending time on this. There will be a JEP to
remove the SM "feature" (not the APIs) so methods like this will likely
be
Hi,
I noticed that the long-deprecated
method SecurityManager.checkMulticast(InetAddress, byte) no longer has a
@deprecated note.
Some context:
o The method has been marked @Deprecated since the initial load of OpenJDK
code in 2007
o In 2016, JDK-8145468 [1] added since="1.4"
o In 2021,
On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai wrote:
>>> to make the intention clear as well as reduce the chances of missing some
>>> boot or platform module in this NATIVE_ACCESS_MODULES?
>>
>> The list to be be granted native access is a subset, it shouldn't be granted
>> all modules
> 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
On Tue, 5 Mar 2024 14:24:35 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use consistent names
>
> src/java.base/share/classes/sun/security/jca/ProviderList.java line 429:
>
>> 427: * Not
> Re-implement it as an `Iterator` to make sure it can only be iterated once
> and make debugger happy.
>
> No regression, just a refactoring.
Weijun Wang 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, 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.
>
Hello,
Sorry in advance for the inconvenience.
Would it be possible to do something about request JDK-8293345 ?
Thanks in advance.
Nicolas
On Fri, 12 Jan 2024 18:06:33 GMT, Weijun Wang wrote:
>> Re-implement it as an `Iterator` to make sure it can only be iterated once
>> and make debugger happy.
>>
>> No regression, just a refactoring.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since
On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman wrote:
>> make/conf/module-loader-map.conf line 95:
>>
>>> 93: #
>>> 94:
>>> 95: NATIVE_ACCESS_MODULES= \
>>
>> Hello Jan, does this make configuration allow for something like:
>>
>>
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>>
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Tue, 5 Mar 2024 12:01:38 GMT, Guoxiong Li wrote:
> > Seems good. If nobody disagrees such mixed patch, I will help you change
> > the title and content of the issue.
>
> Have changed just now! And please wait for a formal reviewer to review this
> path.
Thanks so much!!!
-
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native bindings with FFM-based bindings (which are now
On Tue, 5 Mar 2024 12:41:18 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Sat, 2 Mar 2024 11:43:27 GMT, Korov wrote:
> Seems good. If nobody disagrees such mixed patch, I will help you change the
> title and content of the issue.
Have changed just now! And please wait for a formal reviewer to review this
path.
-
PR Comment:
On Mon, 4 Mar 2024 19:57:25 GMT, Sean Mullan wrote:
>> I was not exactly sure if we will support this functionality when there is
>> no SM. The class name has `AccessControler` and the method names use
>> `checkAccess`, but they actually do not always depend on security manager.
>
> I think we
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
>
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
>
30 matches
Mail list logo
