[e-lang] How to implement or test this CapTP detail neatly?

[Kevin Reid]

On Sep 18, 2007, at 21:20, Kevin Reid wrote:

> .. it is possible to amplify a CapTP proxy ... to retrieve the  
> IncomingPos for that proxy. This is used for serializing a proxy  
> when it occurs in a message going over its own connection (as  
> IncomingDesc). The problem ... is that a malicious local ref can  
> replay a proxy's __optSealedDispatch response after the proxy has  
> been GCed, thus causing it to possibly be unserialized on the other  
> side as some unrelated object. So, the sealed box needs to be less  
> powerful. ...
>
> 1. Retain the proxy as part of the contents of the sealed box so  
> that the position cannot be reused while the box lives.
>
> I like this one, but I see no way to *test* it, short of running  
> the tested CapTP system in a vat which is guaranteed to have a  
> precise garbage collector.
>
> 2. The sealed box unseals to something which can provide the  
> position and is revoked when the position is GCed.

After MarkM and I discussed the problem, we decided to go with option  
#2.

Having just started implementing it, I noticed that this gives any  
object holding a proxy the ability to make a weak reference to it:

Extract the sealed box and discard the proxy. To dereference the weak  
reference, send a replayer over the connection to something which  
will pass it back. If the original proxy has been GCed, then the  
response will be a broken ref (from the failed serialization); if  
not, it will be the original reference.

Therefore, I'm going to proceed with #3, which is complex but  
testable, since comparing to the proxy is not possible without  
retaining it in the box:

> 3. The sealed box unseals to [proxy, position] and the amplifier  
> rejects it if the contained proxy is not the same as the amplified  
> reference.

I'm still interested in these questions:

> Are there any other interesting methods?
>
> What's the best way to handle the problem?
>
> Is there a general method for avoiding producing bugs like this?
>
> Are there additional benefits to the check in #3, which prohibits  
> an arbitrary ref from serializing like a proxy belonging to this  
> connection?

(I expand this to benefits or costs.)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>