Eric S. Raymond wrote:
> 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.
I wholeheartedly agree. Maybe a (hyptothetic) pyeval.py as a python version
of ceval.c could provide the ground for a simple sandboxing facility?
Taking control at the bytecode interpretation level is quite general.
Of course you might want to use PSYCO with it. If i understand
Armin Rigo correctly this would also help with his efforts.
See http://psyco.sourceforge.net/plans.html
regards,
holger
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