Greg: > > > As long as it's possible to attempt to execute arbitrary strings > > > as bytecode, I'd say ceval should be robust against this. > > Guido: > > This ought to be a long-term project then: write a bytecode verifier. > > It's not a trivial task! Greg: > When I wrote that, I was assuming that ceval was already mostly robust > in this respect, and that what was being reported was a new hole > recently opened up. > > But it appears I was gravely mistaken, and that ceval has been full of > gaping holes from the beginning. > > I'm disappointed to learn this, because I had always regarded it as an > axiom that no Python-level code should be capable of crashing the > interpreter, and if it can, this represents a bug. However, it seems > this axiom has not been adhered to in the design of ceval. No, the holes aren't in ceval. The hole is the ability to create new code objects from arbitrary arguments, which wasn't planned at all when ceval was designed. I was always reluctant to add this capability, but finally allowed it, consiciously opening up the hole, under pressure from various people who wanted to do bytecode level hacking. The responsibility to validate bytecode should really be in new.code() (and probably in new.function, which requires the code to behave in certain ways). Note that while I like the general principle that Python code shouldn't be able to cause segfaults, I don't think we should see that property as a safety *guarantee*. It's more a code-of-honor of the Python implementation. There are many violations of the principle, mostly in platform-specific extensions (it is easy to crash Python with certain win32 primitives, for example, and it seems unreasonable to expect otherwise). --Guido van Rossum (home page: http://www.python.org/~guido/)
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