[Python-Dev] new features for 2.3? (original) (raw)

Kevin Altis altis@semi-retired.com
Tue, 7 Jan 2003 08:01:03 -0800

-----Original Message----- From: Eric S. Raymond

Guido van Rossum <guido@python.org>: > I'd also like to get rid of safeforunpickling 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). I do care about this, and it's the reason I'm responding. The `safety' feature always struck me as grubby and non-orthogonal, an attempt to patch over a problem that fundamentally cannot be solved at that level, and one that could only backfire by creating a false sense of security in people who weren't really thinking about the underlying difficulty. If we're going to have a sandboxing[1] facility in Python, it should be decoupled from pickling and more general. +1. Scrap that feature, it was wrong to begin with.

I would appreciate a little more explanation regarding the use of pickles. Since I've brought up the issue off-list a few times about using pickles of built-ins such as strings, integers, lists, and dictionaries (and probably datetime), but no sub-classes of built-ins or custom classes. I understand that there are security concerns, but does this mean that exchanging a pickle via XML-RPC and/or SOAP or exchanging a pickle the way you might use a vCard (pickle as just data) is simply not doable? How does this impact ZODB (if at all) for the same types of applications? Binary pickles are extremely fast and easy to use, but it appears that using them in a situation where you need to exchange data is just not doable without additional support modules.

Or perhaps there just needs to be a standard safe unpickler that is part of 2.3 that only excepts built-ins of "safe" types? If the pickle contained something unsafe it would simply throw an exception but no harm would be done.

Thanks,

ka

Kevin Altis altis@semi-retired.com http://radio.weblogs.com/0102677/