Eval, literal eval, safe eval

[Mark Miller]

On Sun, Nov 23, 2014 at 8:22 AM, Mark S. Miller <erights at google.com> wrote:

>
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/
> http://research.google.com/pubs/pub40673.html
> https://code.google.com/p/google-caja/wiki/SES
> www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf
>
> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency desperately
> needs updating in light of modern promises, but see discussion of Vats and
> "there".
>

See also the two talks announced at
http://www.eros-os.org/pipermail/cap-talk/2011-November/015079.html




>
>
> On Sun, Nov 23, 2014 at 3:27 AM, Michał Wadas <michalwadas at gmail.com>
> wrote:
>
>> Introdution:
>> - eval executes piece of code
>> - eval can not be safely used with external input
>> - Python's ast.literal_eval would be almost useless in modern
>> JavaScript (almost all data types can be easily send as JSON)
>>
>> literal_eval description:
>> >The string or node provided may only consist of the following Python
>> literal structures: strings, numbers, tuples, lists, dicts, booleans, and
>> None.
>>
>>
>>
>> My proposition is "safe eval".
>> Safe eval ( eval.safe(string: code, callback) ) should perform theses
>> steps:
>> - Create isolated realm without capabilities to perform almost any IO
>> (implementation dependant - no XHR, no importScript, no require)
>>
>
> y
>
>
>> - evaluate code in context of created realm
>>
>
> y
>
>
>> - post result of last evaluated expression back to creator realm using
>> structured-clone algorithm
>>
>
> n. Structured clone sucks.
>
>
>> - call callback with returned data
>>
>
> Prefer promises to callbacks
>
>
>>
>> Pros:
>> + sandbox offered by language
>>
>
> y. Plan is to refine Realm API for ES7 by trying to redo SES in terms of
> Vats.
>
>
>> + easy to run in other thread
>>
>
> y
>
>
>> + quite easy to polyfill
>>
>
> Well, it wasn't as easy as I first expected, but we do have a SES
> polyfill. Not yet for Vats or Dr. SES
>
>
>> + servers can send computations to users
>>
>
> y
>
>
>> +
>> Cons:
>> - Realm creation can be costly (but implementations can solve this
>> problem in many ways)
>>
>
> y
>
>
>> - proposal does not include support for asynchronous operations
>>
>
> Dr. SES does.
>
>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141123/17b7a09d/attachment-0001.html>