> Perhaps the main features could be left in the core, without any real > application being offered as part of the "batteries". This way, a secure > environment could evolve in parallel, without forking the Python > development itself. Of course that assumes that the main features in the core are secure. Samuele's observation that restricted code can modify a new-style class passed in belies that. > I was talking about major changes like type/class unification. I belive > that major changes like this won't happen often, and that's the kind of > change that affected the restricted execution so far. As far as you know. Every change is a potential security hole. > One idea I was wondering is to provide a "hack me" machine somewhere on > the web, including a hall-of-fame for those who break the system > somehow. Hummm.. I must find some infrastructure to do that. Anyway, > that could help us find some obvious problems quickly, but I understand > it shouldn't affect the general decision of how to support restricted > execution in Python. Better put it in a serious chroot jail. I think this has been tried and broken into before. --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