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 56: > 54: * </strong></p> > 55: * > 56: * <p>To protect the JVM against deserialization vulnerabilities, > application developers I would personally drop "the JVM", leaving "To protect against deserialization ..", since the protection is applicable to more than the JVM ( applications, libraries, etc). src/java.base/share/classes/java/io/ObjectInputFilter.java line 58: > 56: * <p>To protect the JVM against deserialization vulnerabilities, > application developers > 57: * need a clear description of the objects that can be serialized or > deserialized > 58: * by each component or library. For each context and use case, > developers should drop "serialized or" - filtering is not relevant to serializing. src/java.base/share/classes/java/io/ObjectInputFilter.java line 75: > 73: * protect individual contexts by providing a custom filter for each. > When the stream > 74: * is constructed, the filter factory can identify the execution context > based upon > 75: * the current thread-local state, hierarchy of callers, library, module, > and class loader. This list looks like it is enumerating what the filter factory does, but it is just an example of what could be done. Maybe that needs to be made more explicit. ".. the filter factory can identify execution context based upon, say, ... whatever it likes .. system nanoTime, ... " Or just add "e.g." src/java.base/share/classes/java/io/ObjectInputFilter.java line 107: > 105: * Note that the filter may be used directly or combined with other > filters by the > 106: * {@linkplain Config#setSerialFilterFactory(BinaryOperator) > JVM-wide filter factory}. > 107: * </ul> This list is a little confusing to me, but could be that I don't fully grok it yet. getSerialFilterFactory returns THE JVM-wide factory, whether that be the built-in factory implementation or not is somewhat irrelevant. No need to treat them differently - one either sets a factory (in which case that is the JVM-wide factory), or one does not set the factory (in which case the built-in factory is the JVM-wide factory). ------------- PR: https://git.openjdk.java.net/jdk/pull/3996
