On 4/29/21 2:44 AM, Geertjan Wielenga wrote:
Also, from the point of view of Apache NetBeans, here’s a list of our
concerns with these developments:
https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security
<https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security>
Apache NetBeans doesn't use java.lang.SecurityManager to guarantee
security, but rather to gain additional insight into the JVM's behavior.
Without having such insights, the IDE's user experience would be
severely affected.
Are replacement APIs being designed and will they be provided for
evaluation before JEP-411 is integrated?
One of the Goals [1] in JEP 411 is:
- Evaluate whether new APIs or mechanisms are needed to address specific
narrow use cases for which the Security Manager has been employed, such
as blocking System.exit().
Thus, it is not a goal of this JEP to design replacements; however it is
a goal of the JEP to identify potential use cases that may need
replacements. Those cases would be explored more and if considered
important enough defined in other Enhancements or JEPs.
The next update of the JEP will include additional text about some other
SM use cases.
Thanks,
Sean
[1] https://openjdk.java.net/jeps/411#Goals
Thanks,
Gj
On Thu, 29 Apr 2021 at 07:38, Peter Firmstone
<peter.firmst...@zeus.net.au <mailto:peter.firmst...@zeus.net.au>> 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.reinh...@oracle.com
<mailto:mark.reinh...@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
