A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-October/122273.html below:

[Python-Dev] Improved evaluator added to ast module

[Python-Dev] Improved evaluator added to ast moduleGeorg Brandl g.brandl at gmx.net
Sat Oct 20 18:00:51 CEST 2012
On 10/20/2012 10:24 AM, Andrea Griffini wrote:
> On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>>> 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.
> 
> I'm not sure if this is pertinent to the safe eval discussion, but
> currently it's possible to make python crash with a segfault even by
> just *parsing* an expression.
> 
> See http://bugs.python.org/issue5765

There's a big difference between being able to pass anything to an eval()
invocation, and having to exploit a segfault due to a stack overflow.

Even if your eval() argument overflows the stack, it's still much safer
than if you pass '__import__("os").unlink(...)' :)

Georg

More information about the Python-Dev mailing list

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