[steveklabnik]

> I don't know about the security vulnerabilities,

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

> why not just use JSON?

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.

[mercurial]

> 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

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.

[steveklabnik]

Then you're not supporting YAML, you're supporting your own subset of YAML.

[mercurial]

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.

[steveklabnik]

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.

[bronson]

I don't even think that's fair. What happens when everyone implements their own pet subset of a standard?

[mercurial]

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.