[Python-Dev] PEP_215_ (string interpolation) alternative EvalDict

[Paul Prescod]

Steven Majewski wrote:
> 
>....
> 
>  But if you're going to allow interpolation of the results of arbitrary
> function into a string, it's going to be a security problem whether
> or not you use 'eval' to do it. My code hides the eval in the object's
> python code. u" strings would hide the eval in the C code. How is one
> more or less secure than the other.

I think you mean $" strings, not u" strings. Given:

a = $"foo.bar: $foo.bar(abc, 5)"

I can translate that *at compile time* to:

a = $"foo.bar: %s" % foo.bar(abc, 5)

No runtime evaluation is necessary. So I see no security issues here. On
the other hand, evaldict really does have the same semantics as an eval,
right? Probably it is no more or less dangerous if you only do a single
level of EvalDict-ing. But once you get into multiple levels you could
get into a situation where user-provided code is being evaluated. The
first level of EvalDict incorporates the user-provided code into the
string and the second level evaluates it.

Ping's current runtime implementation does use "eval" but you could
imagine an alternate implementation that actually parses the relevant
parts of the string according to the Python grammar, and merely applies
the appropriate semantics. It would use "." to trigger getattr, "()" to
trigger apply, "[]" to trigger getitem and so forth. Then there would be
no eval and thus way to eval user-provided code.

 Paul Prescod