serializing continuations, security issues

[John Rose]

On Aug 12, 2008, at 1:24 AM, Lukas Stadler wrote:

> I was looking at your method handle changeset and I was wondering  
> if in the long run method handles will be serializable?
> Thinking about (serializable) continuations it would be very  
> convenient if method handles would behave like java.lang.Class  
> (which are serializable).

Interesting point.  Here's the catch:  A method handle is a  
capability to call the method, even if it is not public.  If it were  
simply serializable, it would be easy to forge capabilities to  
private members.  A reflective method with the accessible bit set is  
also such a capability, so there's a similar argument there.

> Currently if you want to store a continuation you have to work  
> around the fact that reflect.Method isn't serializable...

Right.  As you know, this is one of the challenges working with  
continuations:  You get the interior state of a computation, some of  
which may be private to a class, and you don't want to open up a  
security hole by allowing untrusted parties to inspect the contents  
of that state via a serialization, or (much worse) to forge similar  
states by editing serialized continuations.

What we need is a way for trusted parties to serialize the method  
(and other continuation parts) with the understanding that the  
serializations will be kept private, or at least sanitized when  
exiting trust boundaries, and verified when entering them.

For method handles, this means we need at least a partial reflection  
API for them.  Currently, for direct method handles only, you can get  
their type (which is public anyway) and the method name as a string.   
I'm not concentrating on such an API, since it is not necessary to  
making invokedynamic a success, but it will have to be thrashed out  
at some point.

Thanks for thinking about this!

-- John