RFR 9: JEP 290: Filter Incoming Serialization Data
brian.goetz at oracle.com
Mon Jul 25 17:05:41 UTC 2016
A few more comments:
- Do you want to tag OIF as a functional interface? (I think yes, you
intend to use this with lambdas.)
- Need explanation of what happens when someone returns UNDECIDED --
and perhaps some motivating explanation of why it is there at all,
rather than just returning boolean.
- Are we sure we want to pass a Class, rather than a class name, to
the filter? Passing a Class means that the serialization layer may
cause the class to be loaded, even if the deserialization is ultimately
rejected -- and therefore a malicious stream can force class loading
(whose <clinit> may have side-effects.) It would be nicer if a rejected
stream didn't cause extraneous classes to be loaded.
On 7/19/2016 10:02 AM, Roger Riggs wrote:
> Please review the design, implementation, and tests of JEP 290: Filter
> Incoming Serialization Data
> It allows incoming streams of object-serialization data to be filtered
> in order to improve both security and robustness.
> The JEP has more detail on the background and scope.
> The core mechanism is a filter interface implemented by serialization
> clients and set on an |ObjectInputStream|. The filter is called during
> the deserialization process to validate the classes being
> deserialized, the sizes of arrays being created, and metrics
> describing stream length, stream depth, and number of references as
> the stream is being decoded.
> A process-wide filter can be configured that is applied to every
> The API of ObjectInputStream can be used to set a custom filter to
> supersede or augment the process-wide filter.
> Javadoc (subset)
> Comments appreciated, Roger
>  JEP 290: https://bugs.openjdk.java.net/browse/JDK-8154961
More information about the core-libs-dev