On Mon, 14 Jan 2002, Jason Orendorff wrote: > Would someone please explain to me what is seen as a "possible > security issue" in PEP 215? Can anyone propose some real-life > situation where PEP 215 causes a vulnerability, and the > corresponding % syntax doesn't? Do you mean the current '%' or my expanded example ? Any expanded version -- mine or PEP 215 introduces possible security holes. ( And I'm not even sure that the current "%" doesn't have a hole if it's used "the wrong way" ) But, as Paul said, it depends on the implementation. I said in an earlied post that I confused PEP 215 with the discussion of PEP 215, where some expanded capabilities were suggested. However, on looking at it again closer, I would say that the examples in PEP 215 contradict the Security Considerations paragraph. It has expressions in it that can't be evaluated at compile time, and any list index or member reference can, in Python, invoke a hidden function call. Any implementation is going to require some run time checks. But just in case I'm seeing it all wrong: could you explain to me how PEP 215 *doesn't* have the potential of introducing a security hole ? If the current proof-of-concept implementation does use eval (as Paul stated), then there is (I believe) a security problem with that implementation. Paul has proposed some other implementation tricks, but I'm, not convinced that you can get the same semantics suggested in PEP 215's examples without requiring runtime checks. Since eval is a know security hole, I think the burden of proof is on the proponents. ( And I'm not even demanding proof -- just a convincing argument without too much hand waving and we-have-ways-of-dealing-with-that! ) -- Steve Majewski
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