Towards better serialization
michal at kleczek.org
Wed Jun 12 21:26:31 UTC 2019
Seems like this is the only amber mailing list I can post to :)
------ Original Message ------
>wrong list btw, amber-dev is for the problem with the implementation, not with a spec proposal.
>----- Mail original -----
>> De: "Kłeczek, Michał" <michal at kleczek.org>
>> À: "amber-dev" <amber-dev at openjdk.java.net>
>> Envoyé: Mercredi 12 Juin 2019 14:23:30
>> Objet: Towards better serialization
>> To be honest I fail to see anything that would make it a better
>> serialization. This proposal is simply enforcement of implementing
>> writeReplace()/readResolve() pair (aka classic memento pattern) with
>> some syntactic sugar on top.
>nope, the idea is to decouple the data you need to write/read from the way you want to serialize those data.
>> And while it might make serialization more secure (which I doubt - see
>> below) it is not better for sure as it forces developers to do more
>> work. The whole premise of Java serialization was that it is supposed to
>> be transparent and cheap to implement. It is rooted in Smalltalk/Self
>> and the idea of a program image and transparent state migration. Why are
>> we giving this up? A better serialization should be simply a better
>> implementation of this idea - what we have here is retraction instead.
>It's more "secure" because the class writer is in control of the data exported and because it relies on constructor/factory, so the same checks are done if you construct an instance classically or by reflection.
>> What's more - it does not really address security concerns! Even the
>> example of non-serializable ServerConnection being recreated based on
>> serverName upon deserialization illustrates it - serverName is not
>> sanitized/validated and as such is a security hole (as may lead to
>> information leak) - the only real defense is SecurityManager and proper
>> security policy in place.
>If you serialize something by definition you are leaking it.
>That's said i agree that the example is not the best one because it doesn't show the validation that should be done.
>> The issue here is that we try to fix security problems in the wrong
>> place. Almost all security issues with serialization are not really
>> caused by serialization itself but by:
>> - huge classpath with all libraries accessible to each other (ie.
>> deserialization gadgets availability in classpath)
>> - running applications with no SecurityManager (starting a JVM with no
>> SecurityManager by default was the single biggest mistake Java designers
>> made in the past IMHO)
>huge classpath is a real issue, we have modules exactly for that, it's just that given the giant size of the ecosystem, things move slowly.
>> There are issues with current serialization but IMHO they can be fixed
>> with small adjustments to the spec/API:
>> - Add an @Unshared annotation on a member field - that would signal
>> requirement for the deserialization framework to make sure the instance
>> is unshared
>> - Use ObjectInput/ObjectOutput interface everywhere instead of
>> ObjectInputStream/ObjectOutputStream classes (which would allow
>> different easier provision of different serialization formats)
>> - Provide easy way to register invariants validation (right now
>> registering ObjectInputValidation is a PITA) - it can be done by
>> introducing @InvariantCheck annotation on a method.
>> - Provide an easy way to designate a constructor or a static method as a
>> deserialization facility (either similar to the one in the proposal or
>> taking ObjectInput as an argument)
>> - Make use of ObjectInputStream.GetField/ObjectOutputStream.PutField
>> interfaces easier/more obvious
>nope, more coupling and peppering the current implementation with more annotations are not a solution, they are the root of problems of the future as the diverse fixes to the serialization has shown.
>> My point here is - current serialization offers a lot and getting rid of
>> it instead of making it better is a huge step back. What's more -
>> getting rid of it is in reality only moving the problem around as the
>> need for transparent serialization is there and is witnessed by
>> existence of all Json/XML transparent serialization solutions. They will
>> not go away - quite the contrary - there will be more of them as there
>> will be no default in the standard library. And they will be worse than
>> the default one.
>serialization of records is transparent.
More information about the amber-dev