>>>>> "TW" == Thomas Wouters <thomas@xs4all.net> writes: [Moshe:] >> > The problem with letting Python code cause fatal errors is that >> > it makes restricted execution much more difficult. Well, >> > something to think about for 2.1... [Guido:] >> Huh? In restricted execution you shouldn't be allowed to mess >> with bytecode! TW> Well, I can see what Moshe means. You get a code object passed TW> in, say, an untrusted pickle or some such. You want to execute TW> it, but you don't want it to ruin your life. Causing the entire TW> program to quit could be considered 'ruining'. On the other TW> hand, if you can hand-tweak bytecode streams in that degree, you TW> can f** up a lot more. Damn straight! If you're using restricted execution mode and accepting bytecode objects that weren't produced by a trusted Python compiler, you're nuts. I am not aware of any effort made to protect the Python VM from attack via malicious bytecode. TW> Now I just need an OK from Jeremy, as the maitre d', and I'll TW> check it in. Your table is ready. A checkin message will be accepted as gratuity. Jeremy
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