[Python-ideas] Adding a safe alternative to pickle in the standard library

Stephen J. Turnbull stephen at xemacs.org
Sat Feb 23 14:11:25 CET 2013


Steve Dower writes:

 > > There are no bugs that allow a back door, right? 
 > 
 > Of course not. That's why we never see security patches or updates
 > for operating systems or platforms. This is a silly argument.

"Of course not."  The right answer is that "it's been audited and
we're as sure as we ever are."  The problem is that (as Devin
Jeanpierre wrote IIRC) pickle was not designed for security from the
ground up.  Removing execution of untrusted code from it may not be as
easy as just saying so.  Maybe it is.

 > > Is the API sufficiently well-designed that users will easily
 > > figure out how to do what they need, and *only* what they need,
 > > and therefore won't be tempted to simply turn on permission to do
 > > *everything*?
 > 
 > All we can ever do is provide instructions to keep the developer
 > safe and make it clear that ignoring those rules will reduce the
 > security of their program. It's up to the developer to make the
 > right decisions.

But that's not enough.  What others have said here is that json
doesn't get used when it would be perfectly suitable (and as secure as
serialization gets!) because the API doesn't provide convenient access
to the features they need.

 > Agreed. I don't think we need a new protocol though, just a less
 > permissive default implementation of Unpickler.find_class().

The proof of the pudding is in the auditing, I guess.




More information about the Python-ideas mailing list