pf_moore at yahoo.co.uk
Mon Sep 20 23:02:49 CEST 2004
"Chris S." <chrisks at NOSPAM.udel.edu> writes:
[large snip of points already covered far better than I could by
> Fair enough. I didn't mean to imply that the current YAML
> implementations were drop-in replacements for Pickle, only that the
> concept of YAML deserves more attention.
I'd say that the "concept" of YAML (in isolation) isn't particularly
clear. I certainly can't discern from the documentation on the
website what it is.
> Well, if the concept of serialization is indeed inherently insecure,
> what could they possibly do?
I dunno. First, is serialisation inherently insecure? If YAML is all
about serialisation, then one of the key points in its documentation
should be either (a) "YAML focuses on providing a secure
serialisation format" or (b) "serialisation is inherently insecure,
for the following reasons - X, Y, Z - and so YAML cannot provide
secure serialisation. These are issues you have to consider when
> In order for YAML to directly address security, it would have to
> concern itself with the "meaning" of the data being serialized,
> which seems outside the scope of YAML's purpose.
How do you work that out? I can't find a concrete enough statement of
YAML's purpose to allow me to make a categorical statement like that.
> Serialization security seems generally assigned as a responsibility
> of the user, who is usually in the best position to gage their
> data's effects. The best a serialization format can do is ensure
> data reconstruction within the bounds described by the user.
As I say, most of this should be in the YAML documentation. I'll be
charitable and assume that it's just something that hasn't been
written up yet, but that section in the spec that I quoted looks
pretty explicit in its vagueness :-)
It was a machine, and as such only understood one thing. Being clobbered
with big hammers was something it could relate to. -- Tom Holt
More information about the Python-list