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

[Peter Firmstone]

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 wrote:
>> 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
>