RFR 9: JEP 290: Filter Incoming Serialization Data
Chris Hegarty
chris.hegarty at oracle.com
Mon Jul 25 14:54:03 UTC 2016
Roger,
Mainly looks good. Some comments on the spec:
- Use the Present Simple Tense consistently, e.g.
"Return*S* an ObjectInputFilter computed from a string of patterns."
- ObjectInputFilter. Was there a comment already on the use of links?
For example the following is showing in the javadoc:
"ObjectInputStream.setObjectInputFilter(java.io.ObjectInputFilter)"
when "setObjectInputFilter" would be better.
Same comment applies to the links to ObjectInputFilter.Status, and
other places.
- ObjectInputFilter class description. "If set on an
ObjectInputStream, the method*(s)* are called ..."
- Looking at the example in the ObjectInputFilter class description
makes me think that maybe the default process-wide filter should
be a filter that simply returns UNDECIDED, rather than being null.
Is it important to discern whether, or not, it has been set?
- ObjectInputFilter.Config
The initial sentence in the class description should describe the
class itself, so maybe " A utility class for ..."
- "process-wide" is this an agreed upon term? I'm just curious where
it came from. Is there a more common term for this?
- Config.setSerialFilter: SecurityException - if there is security
manager and the SerializablePermission("serialFilter") is not
granted or if there is no securityManager set and the process-wide
filter has already been set non-null
It is a little odd to throw a SE if there is no SM, no ?
- Is there a class/package level statement covering null, or should
it be covered for each applicable method?
- ObjectInputStream
"... the serialization filter for the stream." ->
"... the serialization filter for THIS stream."
- setObjectInputFilter: "The checkInput method is called for each
class and reference in the stream". Does this apply to back
references too?
- setObjectInputFilter: "... when the ObjectInputStream is constructed
and CANNOT be re-set until an object has been deserialized."
-Chris.
On 19/07/16 15:02, 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
>
More information about the core-libs-dev
mailing list