Steven Majewski wrote:
>
>...
> Paul is the one who (rightly) brought up the issue of security
> with respect to double evaluated strings. But in addition, he
> seemed to be saying that you can do more with a compile time
> test than you can with a runtime test. I disagree with that.
>...
> I think, for the same semantics, you get the same security
> issues.
Sure, for the same semantics. But EvalDict doesn't have the same
semantics. Even if we ignore double interpolation there is the issue of
code like this:
>>> def double():
... user_val = raw_input("Please enter a number:")
... print "%(2*user_val)" % EvalDict
>>> double()
Please enter a number: 3 + (os.system("rm -rm *"))
For EvalDict to have the same semantics as PEP 215 it would have to
disallow interpolations on strings that were not string literals. This
would make the EvalDict object somewhat different than any other object
in the Python library. Plus it would require compiler support which
would break compatibility with older Pythons.
Paul Prescod
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