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 a
On 18/06/2021 1:18 pm, Peter Firmstone wrote:
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
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 re
On 14/06/2021 9:34 pm, 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.
I too suggested and support this approach.
With Java 8 being a common baseline
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 d
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 whi
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 unti
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 woul
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
setti
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.
If
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 wor
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 SecurityExce
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 re
16 matches
Mail list logo
