3 ms·

I don't know about the security vulnerabilities, but it works fine as a config file format (we use it at my company for a lot of in-house stuff). I had a simila

I don't know about the security vulnerabilities, but it works fine as a config file format (we use it at my company for a lot of in-house stuff). I had a similar reaction to the language. Even if not YAML, why not just use JSON? It's universal, dead simple to use and understand, has extensive libraries in just about any language, etc... That said it's not that big of a deal. At least it's not an in-house markup like Haskell's cabal...

steveklabnik 12y ago
> 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 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 12y ago
  > 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 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 12y ago
    Then you're not supporting YAML, you're supporting your own subset of YAML.
    - mercurial 12y ago
      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 12y ago
        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 12y ago
        I don't even think that's fair. What happens when everyone implements their own pet subset of a standard?
        mercurial 12y ago
        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.
bjz_ 12y ago
As a data exchange format, JSON (understandably) has no comments in its grammar. This is a big problem for config files. TOML is actually designed for this kind of thing.

steveklabnik 12y ago

> 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 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 12y ago
> 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 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 12y ago
  Then you're not supporting YAML, you're supporting your own subset of YAML.
  - mercurial 12y ago
    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 12y ago
      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 12y ago
        I don't even think that's fair. What happens when everyone implements their own pet subset of a standard?
        mercurial 12y ago
        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.

bjz_ 12y ago

As a data exchange format, JSON (understandably) has no comments in its grammar. This is a big problem for config files. TOML is actually designed for this kind of thing.