On 16/06/2021 11:18 pm, David Lloyd wrote:
There are already issues with Permission implementations, take for
example SocketPermission, it consults DNS and it isn't possible to enter
a range of IP addresses (such as the local subnet, and a list of public
IP addresses), for now, every single IP
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly complex in mind, could you give
some practical examples of
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
> SecurityManager depends on Permission, currently there are Permission
> checks throughout the JVM, however Permission implementation classes
> will be removed, although the Permission class itself won't be.
This is incorrect AFAICT. The
On 15/06/2021 10:35, Rafael Winterhalter wrote:
Hi Peter,
thanks for the suggestion. Byte Buddy still baselines to Java 5,
unfortunately method handles are not an option at this point. I am
looking into writing a Byte Buddy build plugin that discovers calls to
PrivilegedAction.run and wraps
Hi Peter,
thanks for the suggestion. Byte Buddy still baselines to Java 5,
unfortunately method handles are not an option at this point. I am looking
into writing a Byte Buddy build plugin that discovers calls to
PrivilegedAction.run and wraps those in a reflection-based AccessController
Hi Rafael,
On 13/06/2021 22:28, Rafael Winterhalter wrote:
Furthermore, it is difficult to create a working facade for dispatching to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a utility
to a library, this utility
On 15/06/2021 2:23 am, David Lloyd wrote:
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
> 1. Develop authorization layer security provider services in OpenJDK,
> back port it to Java 8 and Java 11 (these provide most of the
> utilised functionality of SecurityManager, allowing developers to
> only implement those
On 6/14/21 7:34 AM, Rafael Winterhalter wrote:
Why not add the property once this is the case, though? As it is now, I
read the 'forRemoval' property to indicate a problem that should be
instantly addressed. With Java 8 being a common baseline for libraries and
the version being supported
Why not add the property once this is the case, though? As it is now, I
read the 'forRemoval' property to indicate a problem that should be
instantly addressed. With Java 8 being a common baseline for libraries and
the version being supported until (at least) 2030, I don't see how this
removal
On 14/06/2021 6:37 pm, Alan Bateman wrote:
There are some libraries where the maintainers have put effort into
working with a SM.
Yes, I am one of them, very much so.
At first it's a shock, but the show must go on, it could be an
opportunity to address some long standing issues also.
The JEP addresses this:
> In future JDK releases, we will degrade the Security Manager APIs so that
> they
remain in place but have limited or no functionality. ... This will allow
libraries
that support the Security Manager and were compiled against previous Java
releases
to continue to
Binary compatibility only?
Security.getSecurityManager() always returns null.
Security.setSecurityManager() always throws a SecurityException
(compatible because existing SecurityManager is allowed to prevent the
call from succeeding).
SecurityManager constructor always throws a
One example for a currently necessary "doPrivileged" are Java agents where
a class loading triggers agent code where the agent shares the stack with
any code that loads a class for the first time. Otherwise, Byte Buddy wraps
anything that might require privileges as privileged action to allow
On 14/06/2021 08:35, Peter Firmstone wrote:
I wouldn't want to see SecurityManager and Policy be neutralized, it's
better to remove it and fail early so people update their software,
there's a risk they may update without realizing it's no longer fully
functional. Get rid of the baggage so
My thoughts on how to proceed with this is:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing developers to
only implement those which they need, without
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the first of several in a multi-release/multi-year effort.
It's way too early to give any guess as to when the APIs will be
removed. As the JEP says, future releases may degrade the SM APIs so
that System.getSM
- Mail original -
> De: "Rafael Winterhalter"
> À: "core-libs-dev"
> Envoyé: Dimanche 13 Juin 2021 22:28:33
> Objet: JEP 411: Deprecation with removal would break most existing Java
> libraries
> I am currently looking into how I should address JE
I am currently looking into how I should address JEP 411 in my library Byte
Buddy and I find it rather challenging. The problem I am facing is that I
know of several users who rely on the security manager in their Java 8/11
applications. I would like to continue to support those users' use cases
19 matches
Mail list logo
