Explicit Serialization API and Security

David M. Lloyd david.lloyd at redhat.com
Thu Jan 8 22:03:19 UTC 2015

On 01/08/2015 02:10 PM, Brian Goetz wrote:
>> 1) Validate invariants
>>      A clear and easy to understand mechanism that can validate the
>> deserialized
>>      fields. Does not prevent the use of final fields, as the
>> serialization framework
>>      will be responsible for setting them. Something along the lines
>> of what David
>>      suggested:
>>        private static void validate(GetField fields) {
>>            if (fields.getInt("lo") > fields.getInt("hi")) { ... }
>>       }
>>      This could be a “special” method, or annotation driven. TBD.
>>      Note: the validate method is static, so the object instance is
>> not required to
>>      be created before running the validation.
> Sort of...
> This is true if the fields participating in the invariant are
> primitives.  But if they're refs, what do you do?  What if you want to
> validate something like
>    count == list.size()   // fields are int count, List list
> ?  Then wouldn't GetField.getObject have to deserialize the object
> referred to by that field?

In fact you cannot validate invariants across multiple objects at all 
using this method *or* readObject() (existing or enhanced) unless the 
object in question is an enum, Class, or String (and a few other special 
cases) because you can't rely on initialization order during 
deserialization.  That's the very reason why OIS#registerValidation() 
even exists - inter-object validation is not possible until after the 
root-most readObject has completed, which is the time when validations 
are executed.  Robust validation of a given object class may require two 
stages - "near" validation and "spanning" validation - to fully 
validate.  However the readObject() approach and its proposed variations 
(including the static validate() version) can still be useful for 
fail-fast and non-complex validations; you just have to understand that 
(just as today) any Object you examine might not be fully initialized yet.


More information about the core-libs-dev mailing list