Capability leak by fulfilling with a non-fresh handled presence

[erights]

Our way of fulfilling a handled promise with a fulfillment handler has a capability leak: Say Alice and Bob are within the same frozen root realms and supposedly isolated from each other. Alice creates a handled promise and then does Resolve(Object, fulfilledHandler), which fulfills it with Object. Bob then does Promise.resolve(Object) and retrieves Alice's handled promise.

Our presences are only safe when they are fresh. To enforce freshness, the presence should be created by the eventual-send package in the act of fulfilling a handled promise with a fulfilled handler. I don't see any way to do this while preserving the elegance of the current HandledPromise constructor.

API details aside, the most general way I can think of to ask the TCB to create a new fresh object, while still providing flexibility for what the object is, is to provide the parameters of Object.create and leave the creation up to the TCB.

Fortunately, there should be no motivated use case for simultaneously fulfilling a handled promise with a pre-existing object while also providing a fulfilled handler for that case. Fulfilled handlers should only be needed for fresh presences, so there shouldn't be any loss of needed functionality.

[michaelfig]

Can we do:

resolve(myObj, fulfilledhandler)
Innerresolve(Object.create(myObj))

The resolution would just be a fresh object whose prototype is myObj.

[erights]

That would work and has some nice properties. But given the semantics of omitting the fulfilledHandler, it is surprising. Perhaps too surprising.

[michaelfig]

Maybe the third argument to the executor should be resolvePresence, to distinguish it from standard resolve?

I misspoke once that this was already the case. Perhaps it should be that way.

[erights]

I like that.

[erights]

resolvePresence could return the new fresh presence that it made.

[erights]

Should be called fulfillWithPresence. I propose the following parameters:

fulfillWithPresence(fulfilledHandler, 
                    optParent = Object.prototype, 
                    optDescriptors = undefined) -> presence

since only the fulfilledHandler should be mandatory. If the others are omitted, the returned presence is a fresh {}.

[erights]

Should the fulfilledHandler be called the presenceHandler ?

[michaelfig]

I like presenceHandler. Can I suggest that we just have:

fulfillWithPresence(presenceHandler) -> Object.create(null)

and so they can only mutate the presence, set the prototype or property descriptors if they have access to the Reflect API parts that can do that? That way we can include this constructor in Jessie without a privilege leak.

[erights]

Nice! I hadn't thought about the Jessie implications. Yes.

[michaelfig]

This is implemented.