pyyaml 6
pyyaml (aka python3-yaml) is an rdepend for >300 packages. We currently
have 5.4.1, but version 6 was released late last year, which does quite
a lot of cleanup (eg, dropping python 2 support) and disables unsafe
loading (arbitrary python code execution) unless explicitly opted into.
Unfortunately this is a breaking change for any code which uses the
simple `yaml.load(fileobj)` idiom - it now needs to be
`yaml.safe_load(fileobj)` or `yaml.load(fileobj, Loader=yaml.SafeLoader)`.
I uploaded 6.0 to experimental late last year, but time constraints
meant it never got pushed forward. I've recently refreshed the version
in experimental (experimental doesn't get binnmus so it was still only
built for 3.9), and there are relatively few autopkgtest regressions:
https://qa.debian.org/excuses.php?experimental=1&package=pyyaml
However, using codesearch suggests there are quite a few places which
are likely to break:
http://codesearch.debian.net/search?q=yaml%5B.%5Dload%5B%28%5D%5B%5E%2C%5D%2B%5B%29%5D+filetype%3Apython&literal=0&perpkg=1
Some of these are false positives, such as invocations of ruamel.yaml,
that string appearing in documentation, or things regex can't catch -
but that still looks like it leaves a significant number of packages
being potentially broken - and presumably lacking autopkgtest coverage).
So, I'd seek some input on how to move forward.
* Upload to unstable and see what breaks?
* Request an archive rebuild with this version and see what breaks?
* File bugs against all likely affected packages with a fixed date for
an upload?
* Wait until after the freeze?
The only bug requesting it actually be upgraded is
https://bugs.debian.org/1008262 (for openstack). I don't know if that
has proved a hard blocker - I _think_ anything designed to work with 6.x
should also work with 5.4.
Gordon
Reply to: