New candidate JEP: 415: Context-Specific Deserialization Filters

Peter Firmstone peter.firmstone at zeus.net.au
Fri May 7 00:44:01 UTC 2021


While I'm not against such a thing, it indicates increasing complexity 
in the game of de-serialization whack-a-mole.

It also suggests people are using Java Serialization to process 
un-trusted data.

I think that Serialization Filter's are a design mistake, we should just 
enable the existing Java Serialization to be turned off completely.  The 
time spent writing these things should be spent implementing new 
Serialization API's.

A property or command line argument that cannot be changed at runtime to 
switch off Java Serialization would be appreciated.

A new public API for Serialization which includes Object level input 
validation and failure atomicity needs to be designed that is suitable 
for use with many Serialization protocols.

Serialization is a public interface, we should start declaring it as such.

-- 
Regards,
  
Peter.

On 7/05/2021 8:37 am, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/415
>
>    Summary: Allow applications to configure context-specific and
>    dynamically-selected deserialization filters via a JVM-wide filter
>    factory that is invoked to select a filter for each individual
>    deserialization operation.
>
> - Mark



More information about the jdk-dev mailing list