> > I'd also like to get rid of __safe_for_unpickling__ and all other > > pseudo security features. Attempting to unpickle pickles from an > > untrusted source is insane, and nothing can help us there; I'd rather > > make the marshal protocol bulletproof (all it needs is a few more > > checks for inconsistent data and a little better error handling). > > 2 questions: > > 1) Are you going to retain the current ability to create a > cPickle.Unpickler, set its find_global attribute to a function that only > allows certain trusted classes to be unpickled (or perhaps none at all), and > use that unpickler object to "safely" unpickle strings? I have no intention to remove existing APIs, so yes. > I'm asking because Webware for Python contains a PickleRPC protocol which > uses cPickle in this way, and it would be nice to be able to continue using > it with 2.3. > > 2) Do you think this is indeed safe, or should we scrap it and switch to a > new MarshalRPC instead (as indicated by your "attempting to unpickle pickles > from an > untrusted source is insane" remark)? We originally used pickles because > then we can allow certain types and classes (such as mxDateTime objects) and > from my understanding, that wouldn't be possible with marshal. I have not done a security audit of pickling, and until I have, I don't think it's safe. I didn't write pickling with safety in mind, and although Jim Fulton was thinking about safety when he wrote cPickle, I don't think that anyone has ever really seriously looked for security holes in unpickling. There may be accidental holes (code not doing as good a job as it could of checking for bad data), but there may also be conceptual holes (things that cannot be made safe without redesigning the pickling architecture). Who knows. --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