Explicit Serialization API and Security

[Peter Firmstone]

As mentioned I've been experimenting with an invariant validating 
ObjectInputStream, that's backward and forward compatible with Java's 
Object Serialization stream protocol.

No changes have been made to ObjectOutputStream.

ObjectInputStream has been overridden and reading from the stream has 
been completely reimplemented.

Classes are still required to implement Serializable, however readObject 
methods are not called and fields are not set reflectively after 
construction.

After considering all possibilities, I still find myself favouring 
constructors.

Definition of "Cumbersome":
     Slow or complicated and therefore inefficient.

During implementation, I've found that static invarient check methods 
are often shared with other constructors.

If another constructor already has a static invariant checking method, 
you only need call that constructor.

Performance wise, constructors significantly outperform setting every 
field using reflection, the more fields an Object has, the greater the 
performance benefit.

My experience is using constructors is often easier to understand than 
readObject methods.

Because constructors can be chained, I can perform final freezes in one 
constructor, then publish safely using another, existing readObject 
methods cannot provide this functionality.  If a final freeze occurs 
after the readObject method terminates, there is no way to fix existing 
code that uses unsafe publication.

See that attached example, this is actual production code (with the 
addition of @AtomicSerial), Java's RMI also has a DGC implementation.  
In this example using standard Serialization, because a final freeze 
occurs after readObject exits, the implementation uses unsafe 
publication, all guarantees are off.

The annotations I've used are:
@AtomicSerial - indicates serial constructor is present.
@ReadInput - provides access to a ReadObject implementation for direct 
interaction with the stream, prior to object construction, provided for 
backward compatiblility.

However the existing readObject alternative is all too often:
     Insecure and unsafely published.

The real question:

Is secure Serialization worth the additional work?

To those who would value it, I think the answer will be yes, to those 
that don't, perhaps not?

Regards,

Peter.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: BasicObjectEndpoint.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20150202/6acd0b31/BasicObjectEndpoint.txt>