JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON lacks comments.
The vulnerabilities in YAML (which is a superset of JSON, by the way) point at why YAML and JSON both aren't appropriate for configuration: they are _serialization_ formats. Configuration isn't what they're built for.
And you're right, it's really just not a huge deal in any way. Especially once we have `cargo project` to autogenerate the basics.
Live by eval, die by eval. But more seriously, nobody is forcing a Rust YAML library to support arbitrary structure deserialization (or maybe as an optional switch). I don't think you'd want such a switch on in a build system configuration file.
That's one way to look at it. On the other hand, when a format presents useful, but potentially dangerous characteristics (eg, XML entities expansion), it is entirely sensible to offer a way to not take them into account.
Quite fair. Depends on what kind of tradeoff you're looking for: this personally makes me search for a new format. It's reasonable to make a different choice.
Comments
About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html
JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON lacks comments.
The vulnerabilities in YAML (which is a superset of JSON, by the way) point at why YAML and JSON both aren't appropriate for configuration: they are _serialization_ formats. Configuration isn't what they're built for.
And you're right, it's really just not a huge deal in any way. Especially once we have `cargo project` to autogenerate the basics.
Live by eval, die by eval. But more seriously, nobody is forcing a Rust YAML library to support arbitrary structure deserialization (or maybe as an optional switch). I don't think you'd want such a switch on in a build system configuration file.
Then you're not supporting YAML, you're supporting your own subset of YAML.
That's one way to look at it. On the other hand, when a format presents useful, but potentially dangerous characteristics (eg, XML entities expansion), it is entirely sensible to offer a way to not take them into account.
Quite fair. Depends on what kind of tradeoff you're looking for: this personally makes me search for a new format. It's reasonable to make a different choice.
I don't even think that's fair. What happens when everyone implements their own pet subset of a standard?
It's not an hypothetical future, you can often disable dangerous features in XML parsers. It seems sensible to me to do the same with YAML parsers.