Parsing JSON Is a Minefield (2016)

Re:Parsing JSON Is a Minefield (2016) by rjh29 on Monday October 11, 2021 @10:34AM (#28828766)

I've had a number of negative experiences with yaml, enough to put me off using it. For example the implicit parsing of 'yes' and 'no' into bools rather than strings (including the NO country code for Norway) <https://hitchdev.com/strictyaml/why/implicit-typing-removed/>, the no-quote rules allowing accidental creation of inline hashes/arrays <https://hitchdev.com/strictyaml/why/flow-style-removed/>, multiline string syntax so complex that it needs a helper tool <http://yaml-multiline.info/>, and powerful extensions that invite your program to be exploited <https://www.sitepoint.com/anatomy-of-an-exploit-an-in-depth-...>

It manages to be both a poor data interchange language compared to JSON, and also a bad human-friendly langage due to the above ambiguities.

Unfortunately it's still the best human-friendly configuration language in wide use, so I use strictyaml (https://hitchdev.com/strictyaml/) instead.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by kortex on Monday October 11, 2021 @11:13AM (#28829253)

NO is not even the worst of it. `on`, like in github actions, is interpreted as True by PyYaml by default. You have to either quote it, "on", or set certain configs I haven't bothered with just yet.

I fully agree YAML is just...not good as a transport/interchange serde.

Personally, I actually really like HCL as a human-friendly config language, but it's got challenges in writing it, and thus support in most languages, if even present, is read-only.

Will look into strictyaml!

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by 0xbadcafebee on Tuesday October 12, 2021 @11:19AM (#28840801)

Sorry, I should have been more explicit: YAML should never, ever, be edited by a human. Neither should JSON. But they can be read by a human, and copy+pasted, which makes them easier to troubleshoot.

All of the problems you list of YAML are due to humans making assumptions, rather than having a program do all of the serialization/deserialization. YAML has a ton of useful data structures and they do not cause problems when you use a real parser to populate or interpret them. It's also a superset of JSON, so it's clearly not poor in comparison to JSON.

It's also not a configuration language. It's a data serialization format.

[ Parent | on HN ]

Re:Parsing JSON Is a Minefield (2016) by rjh29 on Friday October 15, 2021 @04:50AM (#28875722)

That might be what the authors want (the 1.0 spec mentioned configuration, the 1.2 spec mostly mentions data serialization) but in terms of actual use, it's pretty widely used as a configuration language. There would be no need for optional quote rules, inline hashes/lists or multiple flow styles (all of which YAML supports) if it was purely a serialization language.

If you make something human-readable, humans will edit it. The only reliable way to prevent that is to make the serialisation format binary, IMO.

YAML also supports a number of really powerful features like you point out (tags, anchors etc.) but I don't see them widely used due to security risks with untrusted input, and interlanguage compatibilty problems. So personally I don't think it's a super good data serialisation language either, despite its power, at least compared to something like Protobuf.

[ Parent | on HN ]