Module isolation

Kevin Curtis kevinc1846 at googlemail.com
Mon Jan 11 22:07:04 PST 2010


It looks like the reanimated eval has finally had a steak driven through
it's heart. RIP.

It's could be useful to learn from the experience that FF had with this
feature in determining how a new eval.hermetic should behave. The sandbox
use-case which i think prompted the second param is (i think) still valid.
That some dev's used it as reflection mechanism was unexpected - like much
of the webs evolution.

On Tue, Jan 12, 2010 at 4:11 AM, David-Sarah Hopwood <
david-sarah at jacaranda.org> wrote:

> Kevin Curtis wrote:
> > So, FF3.5 has resurrected the sandboxed eval with the second 'global'
> object
> > parameter - as the closure peeking issue has been fixed. (The second
> param
> > is a live object rather than a string). And thus if the second param
> object
> > is frozen (and the primordials and their prototypes etc frozen) FF3.5
> eval
> > could act as a restricted eval.
>
> FF3.5 eval is undocumented, but if I'm reverse-engineering the source code
> patch (http://hg.mozilla.org/releases/mozilla-1.9.1/rev/67944d1b207d)
> correctly, it still violates encapsulation.
>
> A restricted eval should be specified from scratch, not based on what a
> poorly thought-out vendor extension happens to do.
>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100112/c4a94e6a/attachment.html>


More information about the es-discuss mailing list