This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nobody
Recipients
Date 2001-11-12.06:33:02
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: NO 

I like marshal and think it's much cleaner than pickle.
I'd like to see its format cleaned up and documented
so it can be a portable transport format.  Even the
recursion issue isn't so compelling--there's only a danger
on marshalling, not unmarshalling, and the application
has control over what it marshals.  So I think the idea
of documenting marshal (bug #467384) should be kept alive.
However, it shouldn't be changed in 2.2.  

If the Cookie class is still really aliased by default to
SmartCookie, that's a bad bug and should definitely be
fixed ASAP.  The Cookie docs clearly say not to use
SmartCookie or SerialCookie.  In fact I think SmartCookie
and SerialCookie should be disabled altogether.  Any
applications using them on the open internet have a security
but and should be fixed immediately.

Here's a possible temporary approach to fixing SmartCookie
and SerialCookie: append a cryptographic message
authentication code (MAC) to each pickled cookie.  That
means the application has some secret string K as a
configuration parameter (it should be 10 or more random
8-bit characters, or 20 or more random hex digits, etc). 
Then a smart cookie would be a pickle p, followed by
SHA(p+K).  The Cookie module would validate the MAC before
calling unpickle, and raise an exception if the MAC wasn't
valid.

The security of this scheme rests on K being kept secret
from attackers, which is generally not an easy thing to
manage, but it's something to think about.

Paul
History
Date User Action Args
2007-08-23 13:56:49adminlinkissue471893 messages
2007-08-23 13:56:49admincreate