[12] RFR 8193859: Allow user provided ObjectInputFilter in SealedObject and SignedObject

Weijun Wang weijun.wang at oracle.com
Tue Aug 21 15:19:58 UTC 2018



> On Aug 21, 2018, at 8:57 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 8/20/18 11:06 PM, Weijun Wang wrote:
> 
> 
>> That said, I think "before it is returned" is useful. How about this?
>> * In this example, an {@link ObjectInputFilter} is used during
>> * deserialization of the original object before it is returned. If {@link #getObject()} is
>> * called, the {@link ObjectInputFilter.Config#getSerialFilter()
>> * system filter} is used instead.
> 
> Better, but I might be a bit more specific about the purpose of the filter. How about:
> 
> "In this example, an {@link ObjectInputFilter} is passed in to {@link #getObject(ObjectInputFilter)} and used during deserialization to validate the contents of the object before it is returned. If {@link #getObject()} is called, the {@link ObjectInputFilter.Config#getSerialFilter()
> system filter} is used instead.

OK. I would like to emphasis "the original object". This word is used in the class spec to differentiate with the "signed object".

> 
> Also, I think the specification of the getObject() method should be updated to say that the system filter is used to validate the deserialized object. I realize that this was a previous side-effect of adding the system filter and not part of this change, but this did change the behavior of this method, so I think it should be added to the specification while you are making changes. The CSR will also need to be updated with this change.

I can.

In fact, I have always wanted to add a new @throws if the filter rejects the stream. The problem is that even ObjectInputStream::readObject does not clearly list one.

*Roger*: According to ObjectInputStream::setObjectInputFilter it's InvalidClassException. Can I say "@throws InvalidClassException if the (system) filter returns REJECTED while deserializing the original object"?

Thanks
Max

> 
> --Sean




More information about the security-dev mailing list