←back to thread

171 points irke882 | 7 comments | | HN request time: 0.001s | source | bottom
Show context
sugarpimpdorsey ◴[] No.44507048[source]
If we're being honest, YAML is one of the dumbest ideas of the last 20 years to have proliferated. How we got from XML to here I cannot comprehend.

This is not the first RCE involving YAML and it won't be the last.

replies(8): >>44507063 #>>44507118 #>>44507128 #>>44507156 #>>44507406 #>>44507812 #>>44507872 #>>44509145 #
ChocolateGod ◴[] No.44507063[source]
Why we settled on a file format that relies on invisible characters I'll never know.
replies(3): >>44507183 #>>44507280 #>>44515549 #
imiric ◴[] No.44507183[source]
You use invisible characters whenever you press Enter or Space. If you're referring to Tab, many of the most popular programming languages like Go and Python use them as part of their syntax.

The reason YAML was popularized is because it was a response to XML which isn't user friendly to write. It's unfortunate that the spec got so convoluted, and uses a lot of implicit behavior, but I'd rather write YAML than XML, JSON or TOML for things like configuration files. Nowadays there might be better alternatives, but YAML is the de facto standard.

It's also unfortunate that YAML got abused by people who wanted to turn it into a DSL, so we ended up with thousands of lines of Ansible playbooks, CI workflows, and Helm charts, but here we are.

replies(3): >>44507315 #>>44507341 #>>44508467 #
mrheosuper ◴[] No.44507341{3}[source]
i always enjoy writting json more. I feel it's easier to translate/integrate json into the code.
replies(2): >>44508370 #>>44508415 #
1. cluckindan ◴[] No.44508415{4}[source]
YAML is a superset of JSON, so go right ahead and write your .yml files in JSON.
replies(2): >>44508967 #>>44510583 #
2. galangalalgol ◴[] No.44508967[source]
Sometimes what makes something great is what it lacks. An automatic transmission, operator overloading, schema extensions, batteries etc.
3. baobun ◴[] No.44510583[source]
YAML is actually not a superset of JSON.

https://john-millikin.com/json-is-not-a-yaml-subset

https://news.ycombinator.com/item?id=30052633

replies(1): >>44513268 #
4. cluckindan ◴[] No.44513268[source]
The NO case is not valid JSON.

So that leaves scientific notation.

replies(1): >>44515196 #
5. baobun ◴[] No.44515196{3}[source]
The point is that "going right ahead and write your .yml files in JSON" is not valid. You'd have to restrict yourself to a subset of JSON to not get different semantics.
replies(1): >>44515809 #
6. joombaga ◴[] No.44515809{4}[source]
If you configure the parser to treat it as YAML 1.2 then you don't need to restrict yourself to a subset.
replies(1): >>44516079 #
7. deathanatos ◴[] No.44516079{5}[source]
This is a valid JSON value:

  "\ud83d\udca9"
Python's "PyYAML" package will not decode this to the same result as a JSON decoding.

Rust's `serde_yaml` will fail on this.

I don't know about other parsers, but I'd be curious to.

The standard itself isn't well written here, IMO.

> The content of a scalar node is an opaque datum that can be presented as a series of zero or more Unicode characters.

The example here is a "quoted scalar", which can contain the escapes you see. Those escapes represent "Unicode characters", specifically,

> Escaped 16-bit Unicode character.

But "Unicode characters" is never defined by YAML.

Most implementation seem to treat them as Unicode code points, and so thus the resulting string type in almost all cases in something like [UnicodeCodePoint]; in Rust, that means no unpaired surrogates, or we can't convert it to a Rust `String`, which is roughly speaking `[USV]`. In Python, that's workable, since that's Python's `str` datatype, but that means no surrogate decoding occurs.

The grammar also further implies that it's [UnicodeCodePoint] and not [USV], and the prose never restricts unpaired surrogates. (The JSON standard strongly implies the UTF-16 decoding should happen on escaped values, though it too waffles around unpaired surrogates. Whether unpaired surrogates are accepted is variable in JSON.)

But compare with a JSON string: a JSON string decodes to a something like a [USV], so surrogate pairs are decoded to their corresponding USV.