Greg: > As long as it's possible to attempt to execute arbitrary strings > as bytecode, I'd say ceval should be robust against this. > > But it appears ... that ceval has been full of gaping holes > from the beginning. Guido: > 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). My turn for the time machine :) I wrote: > Perhaps some more rigorous assertions, returning ValueErrors? > If not in C, then in the 'new' module, since that seems to be > the vector of disaster for Xaver, above. Perhaps this would also > be an argument for keeping the 'new' module around longer, > as a 'safer' Pythonic wrapper over bare code/function construction. A good starting point would be some simple boundary and type checking on arguments to new.code(). In this way, we could keep ceval fast and still get the 'safety' benefit. If you like, I can produce some assertions gleaned from my failures the last time I went bytecode hacking. ;) Robert Brewer MIS Amor Ministries fumanchu at amor.org
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