On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> JEP 415: Context-specific Deserialization Filters extends the >> deserialization filtering mechanisms with more flexible and customizable >> protections against malicious deserialization. See JEP 415: >> https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are >> extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and >> `ObjectInputStream`: >> >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Simplify factory interface to BinaryOperator<ObjectInputFilter> and cleanup > the example src/java.base/share/classes/java/io/ObjectInputFilter.java line 197: > 195: * } > 196: * }</pre> > 197: * <h2>Using the Filter Factory</h2> Should this be rather a subsection of the example above? Otherwise it gives the impression that the `doWithSerialFilter` method is provided or invoked by the JDK. src/java.base/share/classes/java/io/ObjectInputFilter.java line 263: > 261: /** > 262: * Returns a filter, that when applied to this filter that is > checking a class, maps > 263: * {@code Status.UNDECIDED} to {@code Status.REJECTED}, otherwise > returns the status of the other filter. Which `other filter` is that? Shouldn't that be `..., otherwise returns the status of this filter.` src/java.base/share/classes/java/io/ObjectInputFilter.java line 265: > 263: * {@code Status.UNDECIDED} to {@code Status.REJECTED}, otherwise > returns the status of the other filter. > 264: * Object serialization accepts a class if the filter returns {@code > UNDECIDED}. > 265: * Appending a filter to reject undecided results for classes that > have not been Could this be rephrased? I am not sure what "Appending" means in this context: more specifically appending to what? Maybe there's a way to describe that in terms of "Mapping" rather than "Appending"? src/java.base/share/classes/java/io/ObjectInputFilter.java line 364: > 362: /** > 363: * A utility class to set and get the JVM-wide deserialization > filter factory, > 364: * the static JVM-wide filter, or to create a filter from a pattern > string. FWIW: In other APIs we talk of `system-wide` rather than `JVM-wide`. src/java.base/share/classes/java/io/ObjectInputFilter.java line 371: > 369: * When each {@link ObjectInputStream#ObjectInputStream() > ObjectInputStream} > 370: * is created the {@linkplain Config#getSerialFilterFactory() filter > factory} > 371: * is invoked to determine the initial filter for the stream. A > stream-specific filter can be set with Maybe the concept of system-wide filter should be introduced first, then you could say that the factory is invoked with `null` as first parameter and the system-wide filter as second parameter when the `ObjectInputStream` is created. Then the next paragraph could expand on what happens when `setObjectInputFilter` is called. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996
