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