pyyaml

PyYAML knew about the breakage since january 2022[0], and nothing really happened. After a year and a half with lots of alphas and betas, I don't think there is much cython could do, short of fixing PyYAML themselves. [0]: https://github.com/yaml/pyyaml/issues/601

That's what PyYAML does as well. It uses PEP 518 [1] to specify the dependencies for the build which PyYAML has included Cython [2]. It's just that for previous releases there was no upper bound here so pip and other tools just selected the latest version which was incompatible. In the past PyYAML included the cythonised .c files in the sdist but as of 5.4.0 they went the PEP 518 route and ensures the client will cythonise them if installing from the sdist. [1] - https://peps.python.org/pep-0518/ [2] - https://github.com/yaml/pyyaml/blob/release/6.0/pyproject.to...

Mostly because of PyYAML: https://github.com/yaml/pyyaml/issues/724 I was pretty annoyed to discover that it had a separate build-time dependency on cython that you can't control from your requirements.txt.

> omitted the single character options of 'y' and 'Y' but it still has 'n' and 'N' 'n'/'N' were removed already in 2006: https://github.com/yaml/pyyaml/commit/8f9b8bed40a53c28

> In Python, you can avoid this pitfall by using yaml.safe_load instead of yaml.load. It's harder to make this mistake in Python these days. yaml.load(input) has been depreacted since PyYAML 5.1 (https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-...) and finally stopped working in 6.0.

That part of the YAML 1.2 spec is in conflict with reality, though. The base of YAML 1.1 documents is large enough that a backwards-incompatible change to default behavior is for practical purposes impossible. YAML 1.1 was released in 2005, and 1.2 in 2009 -- only four years later. But here we are, in 2022, and YAML 1.1 is still the default (in many cases, only) version supported. That's why the "Norway problem" persists -- it's not possible for the parser to know whether the author of an un-versioned YAML document containing "a: no" intended it to parse the same as {"a": false} or {"a": "no"}. Python (PyYAML) doesn't support 1.2 yet: https://github.com/yaml/pyyaml/issues/116 Ruby (Psych) ditto -- I can't even find a tracking issue to enable it. Go (go-yaml) is a mixture of YAML 1.1 and 1.2, depending on the author's preferences. Also, as

Many parsers either default to YAML pre-1.2 or do not even expose a YAML 1.2 option. PyYAML has no 1.2 option, for example. So unless Ansible is using something other than PyYAML... Relevant (open) PR: https://github.com/yaml/pyyaml/pull/555

That author's blog post sent me down a rabbit hole of insanity with YAML and the PyYAML parser idiosyncrasies. First, he mentions "YAML 2.0" but there's no such reference about "2.0" from yaml.org or Google/Bing searches. Yaml.org and wikipedia says yaml is at 1.2. Apparently the other commenters in this thread clarified that the older "YAML 1.1" is what the author is referring to. Ok, if we look at the official YAML 1.1 spec[1], it has this excerpt for implicit bool conversions: y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF But the pyyaml code excerpts[2][3] from resolver.py has this: u'tag:yaml.org,2002:bool', re.compile(ur'''^(?:yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF)$''', re.X), The programmer omitted the single

FYI, PyYAML 5.1 partially fixes the security issues: https://github.com/yaml/pyyaml/issues/265

The first example (i.e. `yaml.load()` in Python) doesn't work with the current version of PyYAML. Function application was disabled some time ago, and `yaml.load()` logs a noisy deprecation warning telling users to use `yaml.safe_load()` instead [1]. [1]: https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-...

> And they warn quite clearly about that. Do they? https://github.com/yaml/pyyaml doesn't even mention safe_load(). And this is the docstring for yaml.load(): Parse the first YAML document in a stream and produce the corresponding Python object. This doesn't sound very scary, and certainly doesn't imply possible code execution.