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
