<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>This are some very interesting comments in JEP 486:</p>
<blockquote type="cite">
<p><span
style="color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Various
early Java Platform features were designed around a vision of
mobile objects. They used serialization to move code and data
between JVMs, and assumed applications would enable the
Security Manager to defend against maliciously serialized
objects.</span></p>
<ul
style="margin-top: 1ex; margin-bottom: 1ex; margin-right: 2em; padding-left: 2em; list-style-type: square; color: rgb(0, 0, 0); font-family: "DejaVu Sans", "Bitstream Vera Sans", "Luxi Sans", Verdana, Arial, Helvetica; font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
<li style="margin-top: 0pt; margin-bottom: 0pt;">
<p style="padding: 0pt; margin: 1ex 0em;">RMI supports<span> </span><a
href="https://docs.oracle.com/en/java/javase/23/docs/specs/rmi/arch.html#dynamic-class-loading"
style="text-decoration: none; color: rgb(67, 114, 145);">dynamic
code loading</a>, but it is enabled only when the Security
Manager is enabled. This feature of RMI has been disabled by
default since 2013. With the removal of the Security
Manager, it is no longer possible to use this feature. We
may remove it in a future release.</p>
</li>
</ul>
</blockquote>
<p>The above failed due to multiple issues, it's worth noting these
were very difficult issue that took many years to solve, we did
however solve them comprehensively.<br>
</p>
<p>JGDMS is a modern evolution of Jini, it uses extensible remote
invocation (JERI), it's like Java RMI, but many of the problems
inherent in RMI have been eliminated over many years of
development:</p>
<ol>
<li>Secure protocols and invocation constraints, allows
administrators to configure the use of various encryption
protocols and ensure these are in force prior to establishing
connections.</li>
<li>Dynamic code loading, unlike Java RMI, JERI doesn't attempt to
duplicate the role of ClassLoaders, instead ClassLoaders are
assigned at endpoints and these are used to determine class
visibility. This addressed issues experienced with annotation
loss and compatibility with OSGi.</li>
<li>Codebase annotations are not used, CodeSource's are only
provided following authentication, the ClassLoaders at each
endpoint are established with necessary CodeSource URL's. This
addressed codebase annotation loss and nightmare class
resolution issues that plagued Jini in the early days.<br>
</li>
<li>Additionally if objects originating from a third party are
serialized within a stream, the third party will be
authenticated or that object cannot be deserialised, it will
also be deserialised into a separate ClassLoader and
ProtectionDomain unique to each originating party. <br>
</li>
<li>Distributed Garbage Collection, concurrency bugs and race
conditions were eliminated, DGC operates using the last
authenticated encrypted connection.</li>
<li>Authorization, during establishment of connections, both
endpoints are authenticated and limited permissions, such as
authorization of code to be dynamically loaded, based on a
checksum of the code, or a signer certificate and authorization
to unmarshal objects originating from the authenticated end
points.</li>
<li>Isolation of code at endpoints based on authenticated
identity.<br>
</li>
<li>Atomic serialization using constructors (does not support
circular object graphs) using input validation prior to object
instantiation. Additionally endpoints must be authenticated and
permission to deserialise granted, to the user and the code that
performs deserialisation and input validation before it can
proceed.<br>
</li>
<li>Principle of least privilege, with supporting tooling, so
developers don't need to write policy files, instead policy
files are generated, audited and edited during deployment. We
also have dynamic policy to manage permissions for remote
services, their proxy's and users.<br>
</li>
<li>Concurrent, high scaling SecurityManager and policy provider,
with very minimal impact on performance.</li>
<li>All hotspots eliminated.</li>
</ol>
<p>The cause of Jini's initial failure, were class resolution
issues, codebase annotation loss and IPv4 network address
translation.</p>
<p>While this sounds complex, the software is relatively simple to
use, developers can configure JERI to use insecure protocols for
testing and simply reconfigure it for secure deployment. The
complexity that existed in Jini was related to bugs, which have
now been solved.<br>
</p>
<p>The goals of Jini were realized. Mobile objects are just
parameters and returns for calls on remote services, if developers
follow domain driven design principles, ensures services method
calls are idempotent and parameter objects are immutable, then you
couldn't ask for an easier to develop mobile object framework.<br>
</p>
<p>I thought it interesting to see we succeeded where others failed
and nobody noticed, I guess that happens when you don't have major
funding, are small, dedicated, working quietly for decades to
solve some very difficult problems and don't attract attention.<br>
</p>
<p>Ironically Java, born of the Jini vision, is now deviating from
our path, features in JGDMS are just to damn good, I'm sure we'll
be using them for many years to come.<br>
</p>
<p>But very interesting comments, we successfully employ
SecurityManager to defend against maliciously serialized objects,
we do many things OpenJDK dev's think are impossible simply
because it's not possible with Java implementation code like RMI,
Serialization and policy provider with lack of tooling. ;) We
have permission checks in the deserialising stream, allowing
administrators to ensure the remote Principal, source of the
object bytes has been authenticated, while also limiting
de-serialization to designated and isolated checksummed code (not
every loaded class in the jvm), otherwise de-serialization doesn't
proceed, I mean you must have both the code and the user
principal, if you only have one of either, or there's other code
on your stack, you can't deserialize, our serialization code is
also hardened against gadget attacks, an attacker must first break
encryption, authentication, then bypass POLP authorization and
input validation (stream type checks, parameter and superclass
invariant checks) before it's possible to break into the JVM, very
good if you're running on OpenBSD on Sparc, not as good as if
you're running on a less secure architecture, but still difficult
nonetheless.</p>
<p>I think there's a hardened stripped down fork in our future,
where trusted platform code is limited to bootstrap code. I am
grateful that OpenJDK continues development of Java, although we
will no longer use official Java releases, we can still continue
to benefit from OpenJDK efforts.</p>
<p>Atomic serialization:<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/wiki">https://github.com/pfirmstone/JGDMS/wiki</a></p>
<p><a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/services/reggie/reggie-dl/src/main/java/org/apache/river/reggie/proxy/RegistrarEvent.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/services/reggie/reggie-dl/src/main/java/org/apache/river/reggie/proxy/RegistrarEvent.java</a><br>
</p>
<p><a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=mIbA2ymCWDs">https://www.youtube.com/watch?v=mIbA2ymCWDs</a><br>
</p>
<p></p>
<pre class="moz-signature" cols="72">--
Regards,
Peter</pre>
</body>
</html>