JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

The current JEP 411 plan of action, if left unchanged, will leave 
developers who adopted the SM architecture as an authorization layer 
unable to upgrade to later versions of Java, until finalizers and the 
finalizer attack defensive methods in constructors are removed.  JEP 411 
has the potential to cause significant disruption for a small proportion 
of Java developers, but doesn't have to if managed appropriately.

The blocker is the ability to implement guard checks using Agents on 
public API, due to finalizer attack defensive private static methods in 
constructors.

Allan has advised when finalizers are removed, it will be practical to 
use Agents to instrument public API to implement an authorization layer, 
this is try, so can it be coordinated with JEP 411 et al?

Furthermore, as developers must support multiple Java releases, I 
propose the following amendments, to ease difficulties of multiple 
release support (with multi release jars):

  * AccessController, AccessControlContext, DomainCombiner and related
    Subject and Executors methods, remain until Java 8 is EOL in 2030. 
    Also consider un-deprecation of these methods, as their removal
    causes shotgun surgery (used in 1000's of locations in my software
    alone) and they are required for preservation of Subject, used for
    obtaining TLS and Kerberos connection credentials on all existing
    versions of Java.
  * AccessControlContext - remove inherited thread context, replace it
    with an unprivileged ProtectionDomain, such that doPrivileged
    methods are required for authorization checks and only the current
    thread stack needs to be walked when checks occur, and stack walks
    aren't unnecessarily performed when creating new threads.   This is
    compatible with Loom, update loom to allow the use of
    AccessControlContext to be used, to establish TLS and Kerberos
    connections.  Loom will be very useful for network connections,
    especially long latency connections over the internet, which are
    typically secured using TLS.   This removes the problem of viral
    checks, and Executor task privilege escalation.
  * Modules that are mapped to the boot loader should get a unique PD
    that includes a useful code source rather than using a "shared" PD,
    this allows us to reduce the privileged footprint of the Java
    platform libraries, to allow privileges to be granted to users, not
    code, or users and code.  This is useful to limit data parsing
    privileges to authenticated users on servers (a practise that should
    be more widely encouraged).
  * Remove finalizers, and defensive methods in constructors where
    permissions check points occur as these cause problems for Agents,
    prior to removal of SecurityManager.
  * Deprecate for removal Permission implementations, then remove them
    in a following release.
  * Remove SecurityManager.

This allows a forward migration path for poor sod's like myself who are 
currently using SM infrastructure as an authorization layer, and to 
establish TLS conenctions, this or at least some sort of compromise is 
far preferable to the thermonuclear option currently planned.

What I would like OpenJDK to consider, is to allow developers like 
myself to continue to stay current with Java, by coordinating the 
removal of finalizers and defensive methods in constructors, with JEP 
411, so we have a workable future migration path. Without these 
considerations, options are; go back to Java 8, and plan to redevelop 
existing software, if forced to do so, Java is unlikely to be on the 
list for redevelopment, simply because development costs are lower in 
newer languages, such as automated unit tests, 
https://hackage.haskell.org/package/QuickCheck, no need to worry about 
null pointers and less boilerplate.

Don't get me wrong, I like Java and have many years experience with it, 
but I have to be pragmatic, it won't just be me, many other developers, 
when Java 8 is EOL, will work for companies stuck on that platform, 
simply due to the number of changes required, because they haven't kept 
up (eg budgets) with the current release cadence and pace of 
development, will be looking at redevelopment and replacement instead of 
migration.   Clearly the current pace of development is a good thing for 
Java, but the overall strategy could be tweaked a little, to ensure 
migration doesn't become insurmountable.  A healthy and vibrant Java 
community is essential for the survival of Java, Java has already shed 
phone and client markets, lets not shed too many more.

Thanks,

  
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210731/5a72b6dc/attachment.htm>