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[1]
It allows incoming streams of object-serialization data to be filtered
in order to improve both security and robustness.
The JEP[1] 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
ObjectInputStream.
The API of ObjectInputStream can be used to set a custom filter to
supersede or augment the process-wide filter.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/
SpecDiff:
http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html
Javadoc (subset)
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html
Comments appreciated, Roger
[1] JEP 290: https://bugs.openjdk.java.net/browse/JDK-8154961
