> > Do you mean the rexec.py module, or all the restricted features? > > Both. Unless we spend several orders of more effort on reviewing and > testing these "security" features, we're running the serious risk that > someone naively believes that they are secure, uses them to protect > real data, and their site gets broken into. Then who is responsible? 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. > Even if no real data is lost, the more we advertise this as secure, > the more egg we have on our face when someone finds a hole. The > history of Java's security features shows that even in systems that > have had infinitely more scrutiny, security holes still show up -- > a language implementation is simply too complex to be bug-free. Agreed. > > I would like to see the whole scheme working someday. I'm not sure > > how safe it will ever be, but the problems I've seen so far are due > > to some language change introduced. I belive that once the language > > features are mature, these problems will be reduced. > > I wish you well, but I recommend that you start a separate project > "secure Python". I don't think that the core will ever slow down its > evolution to a pace where security issues can be fixed faster than > they are generated by new code. 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. 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. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
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