[e-lang] Proposal: Remove parameters from __whenMoreResolved/__whenBroken reactors

[Kevin Reid]

On Jul 6, 2005, at 14:57, Mark Miller wrote:

> Kevin Reid wrote:
>> It seems to me that the parameters of __whenMoreResolved/__whenBroken 
>> reactors should not exist. They always duplicate information the 
>> caller has (and therefore violate POLA if they are used), and are not 
>> used, specifically because they are unreliable, by the most common 
>> usage of these messages: Ref#whenResolved/whenBroken.
>
> Hi Kevin, thank you so much for this message. You rescued our paper.
>
> When this message arrived, on the day the paper was due, I saw it, but 
> reasoned as follows:
>
> "Yes, this would be a minor improvement in the language, but it's not 
> a crucially big deal. The paper is due today, we're overloaded with 
> editing issues, and I'd really like to avoid thinking about a language 
> definition change *today* if I can. But publishing the paper with the 
> old protocol sort-of commits us to live with it. Can we? I don't see 
> why not."
>
> I was ignoring POLA to our peril. In the version we submitted on the 
> due date, on p23/section 9.1, there appeared the following bit of 
> code:
>
>     to addListener(newListener) {
>         myListeners.push(newListener)
>         newListener <- statusChanged(myStatus)
>         def handler}(ref) { remove(myListeners, ref) }
>         newListener <- __whenBroken(handler)
>     }
>
> For expository purposes, this code uses __whenBroken directly, rather 
> than the safer Ref.whenBroken. This morning, in thinking about the 
> issue you raise, I realized that this code has a serious security 
> flaw! A malicious listener that has (for whatever reason) access to 
> one of the other listeners could cause this other listener to become 
> unsubscribed, by overriding its own __whenBroken as follows:
>
>     to __whenBroken(handler) { handler <- run(otherListener) }

This *could* have been fixed without changing E:

   def handler(_) { remove(myListeners, newListener) }

I assume this would have interfered with the exposition.

> The fact that this security hole survived multiple rereadings by many 
> people shows that the issue you raise is hardly minor!
>
> I have just corresponded with the conference organizers, and they've 
> agreed to accept the revised version of the paper, which I've also 
> just posted to the standard place 
> (<http://www.erights.org/talks/promises/paper/index.html>). In it, the 
> code above now reads:
>
>     to addListener(newListener) {
>         myListeners.push(newListener)
>         newListener <- statusChanged(myStatus)
>         def handler}() { remove(myListeners, newListener) }
>         newListener <- __whenBroken(handler)
>     }

I hope the } in "handler}()" is a typo in this version of the code and 
did not appear in the paper.

> Now that the paper has been submitted with this change, we are 
> committed to this change before the proceedings is published.

Should I modify E-on-CL to remove the parameter now?

Should the parameter for Ref.when*'s reactors (which are safe) also be 
removed?

Should we implement an expensive transition approach, like this:

   when (asyncAnd(reactor <- __respondsTo("run", 1),
                  reactor <- __respondsTo("run", 0) <- not()))
       -> protocolChecked(stale) {
     if (stale) {
       trace.warn(`$reactor uses the old run/1 ref reactor protocol`)
       reactor <- (this)
     } else {
       reactor <- ()
     }
   }

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