New candidate JEP: 411: Deprecate the Security Manager for Removal

[Peter Firmstone]

Thanks David, will make a note of it for future reference.

Cheers,

Peter.

On 30/04/2021 12:57 am, David Lloyd wrote:
> If it helps, we've solved this particular problem in a couple of 
> places by using an MR-JAR which selects an implementation using 
> `StackWalker` when Java 9+ is used.  I will say however that it 
> appears to be slightly less performant, which is unfortunate (but 
> hopefully fixable at some point in the future).
>
> On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone 
> <peter.firmstone at zeus.net.au <mailto:peter.firmstone at zeus.net.au>> wrote:
>
>     We also use the SecurityManager for caller sensitive method calls.
>
>     I re-implemented a secure implementation of Java Serialization,
>     using a
>     public API and fewer features (eg no circular links), in this
>     implementation, each class in an object's hierarchy has its own
>     namespace, the calling class is discovered using a SecurityManager
>     subclass.
>
>     -- 
>     Regards,
>
>     Peter Firmstone
>     0498 286 363
>     Zeus Project Services Pty Ltd.
>
>     On 29/04/2021 3:37 pm, Peter Firmstone wrote:
>     > Which version of Java is this planned for?   Will the last version
>     > supporting the security manager be a long term support version, eg
>     > back ports of security patches and TLS technologies?
>     >
>     > We have our own security manager implementation and policy provider
>     > implementations.  Both of these are high performance and
>     non-blocking
>     > and we are able to dynamically grant and revoke some permissions.
>     > While I acknowledge the Java policy implementation has a
>     significant
>     > performance impact, due to blocking permission checks, ours is less
>     > than 1%.  Our software doesn't share PermissionCollection instances
>     > among threads, or even have a Permissions cache,
>     > PermissionCollection's are generated for each permission check and
>     > discarded for garbage collection, the Permission object
>     themselves are
>     > cached (after initialization and safe publication), as are the
>     results
>     > of repeated permission checks.  We also have our own Permission
>     > implementations.
>     >
>     > We have tools that generate policy files with least privilege,
>     > although we will manually alter them with wildcards, for network
>     > connections for instance.
>     >
>     > In our software, dynamic permissions are granted after
>     authentication
>     > of TLS connections.
>     >
>     > It is too early for me to tell if there are suitable replacement
>     > technologies available.  I can understand the motivation for
>     reducing
>     > Java's software development burden, but I think this version of
>     Java
>     > might be the last for us, it would certainly be good if a long term
>     > support version was available, perhaps indefinitely lol.
>     >
>     > Regards,
>     >
>     > Peter Firmstone
>     > Zeus Project Services Pty Ltd.
>     >
>     >
>     > On 16/04/2021 4:05 am, mark.reinhold at oracle.com
>     <mailto:mark.reinhold at oracle.com> wrote:
>     >> https://openjdk.java.net/jeps/411
>     <https://openjdk.java.net/jeps/411>
>     >>
>     >>    Summary: Deprecate the Security Manager for removal in a future
>     >>    release. The Security Manager dates from Java 1.0. It has
>     not been
>     >> the
>     >>    primary means of securing client-side Java code for many years,
>     >> and it
>     >>    has rarely been used to secure server-side code. To move Java
>     >> forward,
>     >>    we intend to deprecate the Security Manager for removal in
>     concert
>     >> with
>     >>    the legacy Applet API (JEP 398).
>     >>
>     >> - Mark
>     >
>
>
>
> -- 
> - DML • he/him

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210430/27da06ac/attachment.htm>