[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Jason Orendorff jason.orendorff at gmail.com
Wed Oct 31 16:12:12 PDT 2007

On Oct 31, 2007 12:21 PM, Brendan Eich <brendan at mozilla.org> wrote:
> > One thing could make this a little smoother would be a constructor
> > for a global object, with it's own set of global values, Object,
> > Array, etc. for the sandboxed code to mutilate. Nice, but I don't
> > think necessary.
> This is exactly the path we went down. Obviously my a + b * c == 42
> example is a useless toy. Real uses of eval like this will want to
> evaluate complex object graphs, possibly even containing functions.
> It's a sandbox, right? Should be safe. Not so fast:

I just want to underscore that last line.

Python has an eval() function that accepts an optional "globals"
argument.  For years Python had with a restricted-execution module
(rexec) built around this feature.  It was in the Python standard
library.  For years they plugged holes as they were discovered.  At
last they gave up.  rexec was removed from the language.  I know of no
other Python feature of that size and importance that has *ever* been
flat-out removed.  It was simply impossible to maintain.  The feeling
was that there were always more holes remaining to be discovered and
exploited, and that the system was fundamentally too fragile to afford
dependable protection.  Nobody volunteered for the hard and endless
work of maintaining it.  There are Python solutions for sandboxing
today, but this particular approach failed.

I think static analysis is a more promising approach.  I also think
ES4 has important stuff to contribute other than sandboxing.


More information about the Es4-discuss mailing list