JEP 411, removal of finalizers, a path forward.

Sean Mullan sean.mullan at oracle.com
Tue Aug 3 16:40:58 UTC 2021



On 8/2/21 8:28 PM, Peter Firmstone wrote:
> In JGDMS without SM, at least the following must be addressed to
> maintain security:
> 
>   1. TLS and Kerberos connections cannot be established.  (My software is
>      littered with doPrivileged calls that preserve the Subject, we don't
>      have anon TLS connections, we require client certificates).

As mentioned several times, this use case will be preserved and is 
already covered in JEP 411: https://openjdk.java.net/jeps/411#subject-doas

>   2. All remote connections are authorized to load classes.

Not sure why you can't do something with a custom ClassLoader that only 
loads classes for authorized users.

>   3. All remote connections are authorized to perform deserialization.

Depending on serialization long-term seems somewhat dubious.

> Having established that OpenJDK is not yet willing to compromise, I have
> been attempting to create an authorization layer using Agents, so that I
> can restore perimeter security following the removal of SM and support
> future versions of Java.   It is my hope that either I will be
> successful in recreating an authorization layer, or that enough people
> come forward and OpenJDK decides there are enough affected developers to
> find a compromise that either makes migration practical, or less expensive.

You may have some interesting ideas, but in my opinion you have not 
presented them in a clear and easily digestible manner, and your long 
emails are time consuming to read, repetitive and often diverge into 
rants. (Keep in mind there are many people on the jdk-dev alias, and a 
lot of them may not care about this topic). It is to the point where I 
only skim your emails quickly. I would take the time to write up your 
ideas in an external place. It may not go anywhere, but at least you 
would have a single place where your proposal, experiments, etc are 
documented.

--Sean


More information about the security-dev mailing list