Message53283
Logged In: YES
user_id=31435
Ack -- Paul, you add a new hitherto secret <wink>
requirement with each reply.
marshal isn't secure at all: because its *purpose* is to
load .pyc files, marshal creates Python code objects out of
any bytes you happen to feed it following a "code object"
tag. That's a hole big enough to swallow the solar
system. In 2.2, marshal refuses to unpack code objects in
restricted execution mode, but not before 2.2, and it never
refuses in unrestricted mode.
In contrast, pickle doesn't know anything about code
objects, so doesn't have this hole. The pickle docs are
clear about this, too, spelling out that marshal's code-
object abilities create "the possibility of smuggling
Trojan horses into a program".
When wondering about security, you should be looking at
(and using) cPickle.c instead of pickle.py; cPickle doesn't
use marshal at all, nor does it do eval()s etc. Yes, it
can reconstruct pickled instances of classes that already
exist, but it cannot create new classes. I haven't heard
that characterized as an insecurity before, but to each his
own level of discomfort.
I want to go back to the start: if the question is whether
Python is interested in documenting another data
transmission format, my answer is no. There are many
already (don't forget the ones from the CORBA and ILU
worlds either) available from Python, and there's no reason
to believe encoders/decoders for a Python-specific format
would get implemented in any other language.
pickle is Python's generic answer to the Python-specific
serialization question. I'd be happy to see patches to
improve it (whether for efficient longs, or some stricter
notion of security, or even just docs). But I expect any
additional Python-specific serialization scheme has an
audience of one (if you disagree, fine, write a PEP and get
some community consensus). |
|
Date |
User |
Action |
Args |
2007-08-23 16:01:36 | admin | link | issue467384 messages |
2007-08-23 16:01:36 | admin | create | |
|