Explicit Serialization API and Security

[Peter Firmstone]

My mistake, thank you.

Peter.

On 5/01/2015 9:57 PM, David Holmes wrote:
> Hi Peter,
>
> Did you send this to the list? I haven't seen it turn up yet.
>
> David
>
> On 5/01/2015 6:51 PM, Peter Firmstone wrote:
>> Thanks Dave,
>>
>> That's another way of checking invariants, you could expose A's check
>> method but you'd also need a couple of additional static methods to
>> obtain integers upper and lower from ReadSerial, so that B can ensure
>> its invariant.
>>
>> ReadSerial is caller sensitive so B can't obtain A's stream values via
>> ReadSerial and must do so via A's API.  This prevents the publication of
>> A's implementation, you don't wan't B depending on A's serial form.
>> Instead A can reorder and rename it's fields and change their values,
>> have multiple serial forms and be able to remain compatible with all
>> forms relatively easily.
>>
>> There are some benefits to using a temporary object instance of A; it
>> reduces the amount of code required, eg it would be a beneficial for RMI
>> to minimise code downloads, the JVM is free to inline access to these
>> fields and the temporary instance of A never leaves the cpu cache, so
>> it's not likely to become a performance issue.  Well it might on real
>> time java :)
>>
>> If circular relationships are mutable, or effectively mutable after
>> publication, then we could eventually deprecate the requirement to
>> support special treatment of final fields for Serializable.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 5/01/2015 10:38 AM, David Holmes wrote:
>>>
>>>>>       - I don't see how this invariant-checking mechanism can enforce
>>>>> invariants between superclass fields and subclass fields.   For
>>>>> example:
>>>>>
>>>>> class A {
>>>>>             int lower, upper;   // invariant: lower <= upper
>>>>> }
>>>>>
>>>>> class B extends A {
>>>>>             int cur;   // invariant: lower <= cur <= upper
>>>>> }
>>>>>
>>>>
>>>> The serialization framework should only construct an objects fields
>>>> and make these available from ReadSerial, each class then calls a
>>>> static method before calling a superclass constructor that's
>>>> responsible for an objects creation, to prevent construction of the
>>>> object, if necessary.
>>>>
>>>> Eg, some complexity, but bullet proof:
>>>>
>>>> public class A (
>>>>
>>>>      public final int lower, upper;
>>>>
>>>>       private static boolean check(ReadSerial rs){
>>>>          if (rs.getInt("lower") > rs.getInt("upper"))
>>>>               throw new IllegalArgumentException(
>>>>                  "lower bound must be less than or equal to upper");
>>>>         return true;
>>>>      }
>>>>
>>>>      public A(ReadSerial rs){
>>>>          this(check(rs), rs);
>>>>      }
>>>>
>>>>      private A(boolean checked, ReadSerial rs){
>>>>          super();
>>>>          lower = rs.getInt("lower");
>>>>          upper = rs.getInt("upper");
>>>>      }
>>>>
>>>> // other constructors omitted must also check invarients
>>>> }
>>>>
>>>> class B extends A {
>>>>
>>>>      public final int cur;
>>>>
>>>>      private static ReadSerial check(ReadSerial rs) {
>>>>          A a = new A(rs);
>>>
>>>
>>> It doesn't seem practical in general to have to create an instance of
>>> your supertype to validate the passed in serialized form. Why not
>>> expose the check method?
>>>
>>> David
>>> -----
>>>
>>>>          int cur = rs.getInt("cur");
>>>>          if ( a.lower > cur || cur > a.upper )
>>>>               throw new IllegalArgumentException(
>>>>                   "cur outside lower and upper bounds");
>>>>          return rs;
>>>>      }
>>>>
>>>>      public B(ReadSerial rs) {
>>>>          super(check(rs));
>>>>          cur = rs.getInt("cur");
>>>>      }
>>>> }
>>>>
>>>>
>>