Towards better serialization

[Kłeczek, Michał]

Hi Remi,

Seems like this is the only amber mailing list I can post to :)

Comments inline.

------ Original Message ------

>Hi Mickael,
>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.
>
>regards,
>Rémi
>
>