RE: RFR 9: JEP 290: Filter Incoming Serialization Data

  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 

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

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.

RFR 9: JEP 290: Filter Incoming Serialization Data

  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.

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Daniel, On 7/27/2016 9:15 AM, Daniel Fuchs wrote: Hi Roger, ObjectInputStream.java: 179 * If a {@link #setObjectInputFilter(ObjectInputFilter) filter is set} 184 * A {@link ObjectInputFilter.Config#setSerialFilter(ObjectInputFilter) process-wide filter} these two lines should be

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Roger, ObjectInputStream.java: 179 * If a {@link #setObjectInputFilter(ObjectInputFilter) filter is set} 184 * A {@link ObjectInputFilter.Config#setSerialFilter(ObjectInputFilter) process-wide filter} these two lines should be using {@linkplain, not {@link. 308 private

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi, Updated the specdiff and javadoc with SerializablePermission and misc editorial cleanups. 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

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Chris, yes, its in the webrev, but I neglected to include it in the javadoc and specdiff updates. Thanks, Roger On 7/26/2016 12:20 PM, Chris Hegarty wrote: Another final thought that just occurred to me… java.io.SerializablePermission will need its class-level javadoc updated to

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Another final thought that just occurred to me… java.io.SerializablePermission will need its class-level javadoc updated to include the new permission target name. -Chris. > On 25 Jul 2016, at 19:55, Roger Riggs wrote: > > Hi Chris, > > Thanks for the review and

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Brian, On 7/25/2016 1:05 PM, Brian Goetz wrote: A few more comments: - Do you want to tag OIF as a functional interface? (I think yes, you intend to use this with lambdas.) ok - Need explanation of what happens when someone returns UNDECIDED -- and perhaps some motivating

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Chris, Thanks for the review and comments, Updates in place: 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)

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

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

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

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

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Peter, A filter callback based on blockdata records would more frequently inform the filter of progress in the stream and the amount of data being consumed is already available from streamBytes. That could improve detection of excessive data without complicating the interface and it would

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Roger, On 07/21/2016 08:19 PM, Roger Riggs wrote: - The call-back is invoked after the type of the object and possible array length is read from stream but before the object's state is read. Suppose that the object that is about to be read is either Externalizable object or an object with

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

On 07/22/2016 09:00 AM, Peter Levart wrote: If you think that such addition starts to become complex from combinatorial standpoint then what about passing an additional enum argument identifying a particular "event"? It would then be easy do document the rest of parameters for each event

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Peter, On 7/21/2016 3:42 AM, Peter Levart wrote: Hi Roger, On 07/20/2016 04:44 PM, Roger Riggs wrote: - What is the purpose of the UNDECIDED return? I suspect it is meant to be used in some filter implementation that delegates the validation to some "parent" filter and respects its

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Roger, On 07/20/2016 04:44 PM, Roger Riggs wrote: - What is the purpose of the UNDECIDED return? I suspect it is meant to be used in some filter implementation that delegates the validation to some "parent" filter and respects its decision unless it is UNDECIDED in which case it decides

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Max, The use of filtering needs to be very intentional and so an implementation should be required. I don't expect there to be additional methods and if so a default for checkInput could be added at that time. Roger On 7/19/2016 11:18 PM, Wang Weijun wrote: The ObjectInputFilter

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Roger, On first reading, I have the following thoughts: - The name "ObjectInputFilter" makes me think that it is a function that "filters" the input stream (like a Predicate in Stream::filter(Predicate)), but it is in fact a validator that terminates deserialization on 1st rejection. So

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

The ObjectInputFilter interface has only one method. Are we expecting more methods to be added later and maybe some people will only be interested in a new method? If yes, I suggest we provide a default implementation of the current method to return ALLOWED. --Max > On Jul 19, 2016, at 10:02

RFR 9: JEP 290: Filter Incoming Serialization Data

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