Hi Peter,
>OIS relies on the context ClassLoader, or a stack walk when attempting
to resolve class types. A string allow list is simpler, but you might
also consider permitting the OIS to be given a specific ClassLoader for
type resolution, since these are different functions where a ClassLoader
can perform the function of the allow list, but perhaps shouldn't, but
still be responsible for class type resolution.
Given that Marshalling is envisioned to support use-site pluggable
input/output formats, we're having to consider the common capabilities
of formats to ensure the possibility of adapting to/from each of them.
Having implemented several such bridges over the past couple of years it
seems tractable. Of course there are a multitude of different risks to
account for and design around.
> We needed to support existing inheritance hierarchies of
Serializable objects, and we had code that is compiled separately and
comes together at runtime, so we couldn't rely on the compiler checks
for generic collections and built collection type validators to address
that.
Perhaps unsurprisingly, variants and especially dynamic type
restrictions tend to be challenging to encode in a non-cumbersome way.
On 2026-08-28 09:08, Peter Firmstone wrote:
Hi Victor,
Indeed, the ability to limit the types permitted to be loaded
(contextually to what is unmarshalled) is important to minimize
unmarshalling-associated risks. In my work on Marshalling I currently
rely on an allow-list (essentially String -> Class, as I currently
find ClassLoader to have a rather large API surface for this purpose)
since parsing a schema descriptor is resolving types.
Transparent protocols allow for more inspection than opaque protocols,
the latter limits the allow list to classes. Our current wire
protocol allows deep introspection, but I haven't given this enough
thought at this stage as to how an API might look for a transparent
protocol, vs opaque. OIS relies on the context ClassLoader, or a
stack walk when attempting to resolve class types. A string allow
list is simpler, but you might also consider permitting the OIS to be
given a specific ClassLoader for type resolution, since these are
different functions where a ClassLoader can perform the function of
the allow list, but perhaps shouldn't, but still be responsible for
class type resolution.
For schemaless payloads, the schema needs to be either known in
advance, or be determinable from the shape of the data itself.
I did consider this, and it really depends on the implementation, but
addressing transparency and deterministic behaviour is a
simplification that provides more certainty around security, favouring
the developer, or using inference which favours attackers by providing
options, similar to how a TLS protocol can be downgraded to a less
secure version. I didn't consider my capability sufficient to
implement the latter.
Current designs of Marshalling are essentially T -> record -> output
and input -> record -> T where the record serves both as schema
definition (using the record components as both names and types are
present at runtime). This encoding also permits versioning
(structure-as-version) as well as translation (record-to-enum-value,
record-to-cache-lookup, or equivalent).
This has the benefit of type safety, and since records don't support
inheritance hierarchies, it's an elegant solution. We needed to
support existing inheritance hierarchies of Serializable objects, and
we had code that is compiled separately and comes together at runtime,
so we couldn't rely on the compiler checks for generic collections and
built collection type validators to address that.
I've been trialling AI since April this year. I've developed
standards I can't share on this list, since I've had AI agents assist
with their documentation, they're available for viewing on GitHub and
anything prior to April is AI free, and all AI contributions are
documented in git commits.
I've attached a text file that demonstrates the capabilities of the
serialisation protocol. I haven't invented a new protocol; it's DER
ASN.1, with canonical ordering rules for Collection interfaces that
allow for cross-language collection types.
JGDMS/JGDMS/examples/wire-protocol-showcase at trunk ·
pfirmstone/JGDMS
<https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/examples/wire-protocol-showcase>
Note the adversarial test code that produced the attachment was
written with AI assistance, genuinely attacking it to find weaknesses
in the protocol.
>We don't think of the object's serial form as serialised fields;
they are serialised parameter arguments used to create new objects.
That resonates with how I view it as well.
:)
Cheers,
Peter.
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
