New candidate JEP: 415: Context-Specific Deserialization Filters

Peter Firmstone peter.firmstone at
Fri May 7 22:24:13 UTC 2021


Can we make properties specified from the command line immutable?

So code can't switch it back on again.  It's not much good if code can 
change a property, there will be no SecurityManager to prevent it from 
doing so in future.

Not trying to sandbox, just want to keep the security holes closed.



On 8/05/2021 7:30 am, Roger Riggs wrote:
> Hi Peter,
> Point noted, but does not address existing production apps dependent 
> on serialization.
> We've been encouraging developers to use other serialization 
> mechanisms for years.
> As of JDK 9, JEP 290 can specify a filter on the command line to 
> reject all classes.
>  ...  "-Djdk.serialFilter=!*" ...
> Regards, Roger
> On 5/6/21 8:44 PM, Peter Firmstone wrote:
>> 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.

More information about the jdk-dev mailing list