[Python-Dev] new features for 2.3? - resend

[Kevin Altis]

> -----Original Message-----
> From: Eric S. Raymond
>
> Guido van Rossum <guido@python.org>:
> > 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).
>
> 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/