On Wed, Jul 15, 2020, at 07:54, Edwin Zimmerman wrote: > The idea that the pickle module can be made "safe" is magical thinking. > Pickle's attack surface is just too large and too powerful.
I don't think that makes something *inherently* unsafe, it just makes it difficult to make it safe. The problem I have is with the idea that it is *conceptually inevitable* [in the same way as, say, eval] for it to be unsafe, and therefore that it's not worth fixing bugs or adding whitelist features or doing anything other than saying "oh well it's their fault for using pickle" if/when an exploit is found. [that said, it might also be a worthwhile project to make an alternate "advanced de/serializer" that primarily works by creating empty objects [i.e. with object.__new__(cls)] and populating their slots/dictionaries by assignment rather than by executing any constructor code, though it would need special support for extension types with C structures] > As I said in a previous message, a stupid pickle fuzzer I wrote several > years ago took about 60 seconds to start finding bugs (on an > old slow-as-molasses single-core Intel Atom processor). A more > intelligent fuzzer, on a much more powerful machine would probably > do just as well today. It would help slightly to throw out the _pickle > module and default to the pure Python version, but even then > I wouldn't consider it anywhere close to secure. > > That said, I agree with the idea of giving users an easier way to > control what pickle does. I think that any such modifications > should continue to make clear that pickle has not magically become > "safe". _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YR3WET2G5S42MUBXPN7BAFGAE7XYSJEH/ Code of Conduct: http://python.org/psf/codeofconduct/
