<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Ron,</p>
So far we have dealt with CORBA (external library), pack200 (working
on an external lib) and to support Java 17, removed some Activation
class dependencies (we don't use RMID, so grabbed the missing
Activation classes from Apache Harmony), thankfully these were not
challenging, although replacement of some Activation classes will
require downstream developers to edit their imports and recompile
their code, some are still stuck on Jini 2.1 api compatibility, I
have a Jini 2.1 compatibility layer, that allows them to use JGDMS
without re-compiling, they will be impacted by the changes. There
are a number of projects that use the Jini 2.1 api still.<br>
<p>We have a number of our own permission implementations of course,
such as DeSerialzationPermission and one that's misnamed called
DownloadPermission, which should have been called
"ClassLoadingPermission", because it doesn't prevent code
downloads, URLPermission does that.</p>
<p>These are actually external defenses, and are best granted to
authenticated services (dynamically granted incrementally
following successful authentication), these are gates in the
process of loading a service proxy.<br>
</p>
<p>We only let the good guys through the door, but we still have a
gun safe to stop the kids from accidentally shooting each other.</p>
<p>So we've figured out that we can recreate most of the
authentication layer, the challenges will be implementing Java
platform level guards.<br>
</p>
<p>That's why we still need authorization controls on things like
ClassLoading, network, filesystems and properties, once we allow
the service proxy to load code. It appears unlikely that OpenJDK
will provide hooks here, so we need to wait for finalizers to be
removed, so we can instrument constructors (we don't want to
inadvertently open any holes to the outside by making ClassLoader
sensitive to finalizer attacks).</p>
<p>Perhaps with ClassLoader, we should instead guard the actual
methods that load classes instead of the constructor, it's not
practical to do that with network connections however as it would
take a big performance hit, same with filesystems. Our
reimplementation of URLClassLoader is much faster because it
doesn't make unnecessary DNS calls, so a small impact with guards,
we may still be faster anyway.<br>
</p>
<p>The policy tool currently used for auditing to establish trust
will need to be replaced by new tools that OpenJDK is providing in
future. Clearly auditing needs to increase to offset missing
permission checks. Once we do that, then we can use SHA hashes to
identify codebases and allow their classes to be loaded.</p>
<p>It's still a moving target, with potentially significant
implications if we get it wrong.<br>
</p>
<p>Whether we continue developing in Java will depend on a number of
factors:</p>
<ol>
<li>How successful we are at navigating JEP 411.</li>
<li>Other future JEP disruptors (assuming we succeed with JEP
411).</li>
<li>Overall cost of development and maintenance in Java, v's
another language.</li>
<li>Cost / benefit of using another language.</li>
<li>API stability of other languages.</li>
<li>Longevity of other languages v's Java.</li>
</ol>
<p>I'm working on the assumption that OpenJDK will close any
external holes currently defended by permission checks. It would
be good if the JDK was secure by default, with properties required
to be set for allowing such things as agents, management, parsing
xml and serialization.</p>
<p>We still need some authorization layer controls for trusted users
and services, and balance it with increased auditing of code.
It's not possible with static analysis to determine the intended
use of reflection, so we'll need new observability tools to
replace the current policy tools. Perhaps we can link the
observability tools to a service watchdog, if a service proxy
misbehaves, then, it gets blacklisted and the affected JVM is
immediately restarted.<br>
</p>
<p>Our code is dynamic, so we might need to create an audit service
that provides a list of audited proxy codebases and their SHA-256
hashes.</p>
<p>Keep in mind this is all completely experimental and subject to
change.<br>
</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 31/07/2021 6:22 pm, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:A48A0793-0CFC-4725-941E-DBA648DD9810@oracle.com">
<pre class="moz-quote-pre" wrap="">Hi Peter.
- JEP 411, like every spec-changing JEP, is meant to allow those that use the removed functionality
a migration path forward. The API elements that are deprecated for removal have some years before
they are actually removed, so there’s nothing too urgent other than beginning to think of a migration
path. I think it’s still too soon to consider concrete suggestions for change, especially non-trivial
ones.
- If by Java 8 EOL you mean the time when the last vendor offers extended support for it, then
2030 is, I believe, the *earliest* possible date that is guaranteed *now. It’s possible that support
would be extended until 2130. Such offerings have no bearing on the development of current JDK
versions.
- The number of significant code changes required since JDK 8 to keep up with current JDK releases is,
for the vast majority of Java users, low (what’s affected most users is reliance on non-spec-compliant
libraries, and the need to import the external artefacts for EE). The most impactful change has probably
been the removal of some client deployment technologies from the Oracle JDK, but as far as OpenJDK is
concerned, the affected areas have been CORBA, pack200, Nashorn, and now the process to remove SM is
starting. The number of people using any one of these is low, and the number of those who need to work
hard for alternatives is very low. I think that advance warning, and then support offerings by multiple
vendors for those who have not managed to migrate in the advance warning period is reasonable; always
offering ways to support removed technologies together with new features in current releases with the
same code base is not. When compared with other ecosystems, Java’s strategy is exceptionally tolerant
of those that prefer slow change.
- Property-based testing is wonderful, I wish more people would use it, and I hope to see it used in
the JDK as well. Java has several PBT tools, but I believe the most popular one these days is
<a class="moz-txt-link-freetext" href="https://jqwik.net/">https://jqwik.net/</a>. As long as you’re still with Java, give it a try.
— Ron
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 31 Jul 2021, at 04:04, Peter Firmstone <a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a> wrote:
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, <a class="moz-txt-link-freetext" href="https://hackage.haskell.org/package/QuickCheck">https://hackage.haskell.org/package/QuickCheck</a>, 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
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.</pre>
</body>
</html>