Hacker News Reader

Comment by pron | Hacker News Reader

But the only reason core serialization is considered a "horrible mistake" has nothing to do with performance or with any aspect of the technical implementation. It is considered a mistake only because serialising arbitrary classes breaks invariants in a way that has serious correctness and security implications.

View on HN

The point is that security and bypassing constructors are completely orthogonal as serialisation by memcpy is completely viable strategy and is no less secure than calling constructors on objects.

Whether or not they're orthogonal, it is that aspect that we talk about when we talk about the mistake of core serialization in the JDK. Also, whether calling constructors is necessary for security depends on many details. When we talk about fixing serialization in Java, we talk about a design that is independent of the format used for the serialized data. I understand you're that this is a different layer from the one you're interested in, but that is the layer where the mistake was made, and so that is the layer that requires fixing.

The premise of the sentence you cited is that it is necessary to call application code (constructors) to maintain security/integrity.

What I am saying is that it is NOT necessary to implement secure serialisation and deserialisation because you CAN (and should?) implement it at a different layer and transparently to the application code.

It is necessary to call application code to maintain integrity (i.e. the guarantee of global program invariants), if you want to design classes for serialization that is agnostic to serialized format and that accounts for cases where not both sides of the communication are trusted. If program objects can be constructed from bits that arrive from external input that might not be trusted, some code needs to run to ensure that the objects maintain their invariants. Of course, you could say that objects cannot maintain any of their own invariants (that is the approach taken by Zig, where, unlike in Java, it is impossible to explicitly define, at the language level, an object that represents only prime integers), but that requires a very different language design, one that has not yet been proven to scale well (and one that isn't taken by Java specifically).

> if you want to design classes for serialization that is agnostic to serialized format

You mean XML/JSON/binary etc? This is impossible :) - the only thing that comes close is ASN.1.

But serialisation can be easy: just don't do anything and let runtime handle that. Any compacting GC can be seen as serialiser/deserialiser (it does move object graph from one place to another) - and it does not need to run any application code to perform its task. Criu and any other live program ("object") migration methods are similar.

> and that accounts for cases where not both sides of the communication are trusted

I don't believe Java serialisation will ever be capable of handling deserialisation of untrusted input.

Reply on news.ycombinator.com