RFR: 8264859: Implement Context-Specific Deserialization Filters [v3]

Chris Hegarty chegar at openjdk.java.net
Fri May 21 15:58:00 UTC 2021


On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs <rriggs at 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 365:

> 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.
> 365:      * If a JVM-wide filter factory or static JVM-wide filter is set, it will determine the filter

This concerns me, "A JVM-wide filter factory". I was going to suggest that it should be "The ..", but then realised that there can only ever be one present at a time, but in the lifetime of a JVM there can be two (since getSerialFilterFactory if invoked before setSerialFilterFactory will subsequently return a different JVM-wide factory).   Is this intentional? It would great if this could be "The ..", so that setXXX can only be invoked successfully if getXXX has not been.   This may seen somewhat insignificant, but the fact that the JVM-wide factory can change make the model harder understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996


More information about the core-libs-dev mailing list