New candidate JEP: 415: Context-Specific Deserialization Filters
roger.riggs at oracle.com
Fri May 7 21:30:30 UTC 2021
Point noted, but does not address existing production apps dependent on
We've been encouraging developers to use other serialization mechanisms
As of JDK 9, JEP 290 can specify a filter on the command line to reject
... "-Djdk.serialFilter=!*" ...
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