On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote: > Daniel Holth <dholth <at> gmail.com> writes: > >> How does this compare to the markerlib approach? In markerlib you just >> make sure all the AST nodes are in a set of allowed nodes, currently >> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then >> use the normal eval(). Is one way more secure / fast / flexible than >> the other? > > I don't think performance is an issue, and the markerlib approach seems just > as reasonable as the one I've taken, except that it calls eval(), whereas my > approach doesn't. It boils down to what should be allowed in expressions, and > what shouldn't be. > > ISTM there is a space for a limited evaluator that's less limiting than > literal_eval(). I do realise that this type of sandboxing is not easy to achieve, > and I'm not aiming to advance the state of the art here - I just want to close > the issue in the best way I can. I bet the literal_eval approach simply predates compile(ast) which is a Python 2.6 feature. It is also probably slightly faster on CPython to avoid compile(ast) if you are only evaluating the code once.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4