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

[Chris Hegarty]

On Sat, 22 May 2021 20:16:37 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:
> 
>   Editorial javadoc updated based on review comments.
>   Clarified behavior of rejectUndecidedClass method.
>   Example test added to check status returned from file.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 829:

> 827:          * Returns a filter that returns {@code Status.ALLOWED} if the check is for limits
> 828:          * and not checking a class; otherwise {@code Status.UNDECIDED}.
> 829:          * If the {@link FilterInfo#serialClass()} is {@code null}, the filter returns

"Returns a filter that returns {@code Status.ALLOWED} ... ". Maybe "Returns a filter that allows all limits ..".

Up-levelling a bit, it seems that filter operations fall into two broad categories: 1) class-checking, and 2)limits-checking. At least, in the way that some of these factories and adapters are laid out.  If we had such a notional at the class-level, then maybe that could influence the naming of these factories - and tie them to a higher-level concept.

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

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