Correct serialization can only be done for classes that are designed for it by having a well-known construction protocol, which are currently basic collections, enums, Strings, records, and classes that register specific serialization code.
Correct serialization can only be done for classes that are designed for it by having a well-known construction protocol, which are currently basic collections, enums, Strings, records, and classes that register specific serialization code.
Fury put much work on this to avoid the open dynamic deserialization risks.
But although `basic collections, enums, Strings, records, and classes that register specific serialization code` are the only objects should be allowed for serialization, and they are serialized by the construction protocol in fury already. There are so many applications has used the existing serialization protocol assumption, we have to keep compatible, otherwise most of application can't use fury.
Zero copy state transfer is a viable and high performance alternative.
Security and integrity can (should?) be implemented at a different layer.
The
Completely agreed, but also, adding my own emphasis there.
The technique has has enough gotchas, edge cases, and additional security considerations that it should really be an alternative that people can opt for when they need it, and never be the default approach.
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.
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.