New candidate JEP: 415: Context-Specific Deserialization Filters
peter.firmstone at zeus.net.au
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
More information about the jdk-dev