RFR 9: JEP 290: Filter Incoming Serialization Data

[Peter Firmstone]

Hi Roger,
Many collections classes don't read arrays in directly, instead they read in the size as a primitive integer and create the array before reading in each object.
Clearly the filter can only prevent deserialization of dangerous objects.
My personal opinion is collections classes should be replaced in streams with safe to deserialize serial forms, that are just containers backed by arrays in object form  Client classes need to type check and defensively copy their content into new Collection object instances during deserialization. 
Filters might be able to validate these types, however in general, since there is no way to atomically fail construction during deserialization, object construction should be delayed as long as possible, that is, after all fields have deserialized unless a circular link exists.
Circular links should probably be avoided or their recursion depth limited in untrusted streams.
Regards,
Peter.
Original message:
Hi Peter,

Since the filter is passed information about each object created, a 
stateful filter can tabulate
the cumulative size itself if that is a concern.

Also, a stateless filter can be constructed to check a combination of 
the total number of objects,
depth, array sizes, and stream size. Since arrays are initialized with 
data from the stream,
the stream size provides a practical limit.

Roger

On 8/29/16 10:07 PM, Peter Firmstone wrote:
>    Include original message
>
> A quick thought on the array size filter:
>
> The system creates an array with a size read from the stream.
>
> If Mallory sends a multidimensional array in the stream, then Mallory can consume all jvm memory without exceeding the array size limit or the stream data limit.
>
> We also need an array combined length limit.
>
> Thanks,
>
> Peter.
>
> Sent from my Samsung device.
>