* Move most CI to GitHub Actions
* Build sdist
* Build manylinux1 wheels with libyaml ext (also tested with 2010 and 2014)
* Build MacOS x86_64 wheels with libyaml ext
* Windows wheel builds remain on AppVeyor until we drop 2.7 support in 6.0
* Smoke tests of all post-build artifacts
* Add PEP517/518 build declaration (pyproject.toml with setuptools backend)
* Fully move build to setuptools
* Drop Python 3.5 support
* Declare Python 3.9 support
* Update PyPI metadata now that setuptools lets it flow through
Co-authored-by: Matt Davis <mrd@redhat.com>
* remove some unused imports
as suggested by lgtm
https://lgtm.com/projects/g/yaml/pyyaml/
* add back import * from nodes
* remove also sys import
* remove mkpath import
* builds Windows wheels against a specified libyaml repo/refspec for many Python versions
* since we don't have multiple Appveyor workers, it's faster/more convenient to run them serially
* not all paths sufficient for general CI usage yet; still needs manual inspection/testing of output
* various hacks to quiet warning noise during build on old Pythons
The `load` and `load_all` methods will issue a warning when they are
called without the 'Loader=' parameter. The warning will point to a URL
that is always up to date with the latest information on the usage of
`load`.
There are several ways to stop the warning:
* Use `full_load(input)` - sugar for `yaml.load(input, FullLoader)`
* FullLoader is the new safe but complete loader class
* Use `safe_load(input)` - sugar for `yaml.load(input, SafeLoader)`
* Make sure your input YAML consists of the 'safe' subset
* Use `unsafe_load(input)` - sugar for `yaml.load(input, UnsafeLoader)`
* Make sure your input YAML consists of the 'safe' subset
* Use `yaml.load(input, Loader=yaml.<loader>)`
* Or shorter `yaml.load(input, yaml.<loader>)`
* Where '<loader>' can be:
* FullLoader - safe, complete Python YAML loading
* SafeLoader - safe, partial Python YAML loading
* UnsafeLoader - more explicit name for the old, unsafe 'Loader' class
* yaml.warnings({'YAMLLoadWarning': False})
* Use this when you use third party modules that use `yaml.load(input)`
* Only do this if input is trusted
The above `load()` expressions all have `load_all()` counterparts.
You can get the original unsafe behavior with:
* `yaml.unsafe_load(input)`
* `yaml.load(input, Loader=yaml.UnsafeLoader)`
In a future release, `yaml.load(input)` will raise an exception.
The new loader called FullLoader is almost entirely complete as
Loader/UnsafeLoader but it does it avoids all known code execution
paths. It is the preferred YAML loader, and the current default for
`yaml.load(input)` when you get the warning.
Here are some of the exploits that can be triggered with UnsafeLoader
but not with FullLoader:
```
python -c 'import os, yaml; yaml.full_load("!!python/object/new:os.system [echo EXPLOIT!]")'`
python -c 'import yaml; print yaml.full_load("!!python/object/new:abs [-5]")'
python -c 'import yaml; yaml.full_load("!!python/object/new:eval [exit(5)]")' ; echo $?
python -c 'import yaml; yaml.full_load("!!python/object/new:exit [5]")' ; echo $?
This is the first release under new maintainership. A bunch of things
involving resource URLs and copyright details needed updating; in
addition to the normal version and changelog updates.
Originally this code attempted to determine if compiling the C ext
would succeed, and if it thought it should, it would then require that
the C extension succeed in order to install. This fails in cases where
the detection code passes, but compiling ultimately fails (one instance
this might happen is if the Python headers are not installed).
Instead of "asking permission", this code will now just attempt to
compile the module, and will fall back to pure Python if that fails,
unless the person has explicitly asked for the C module, in which case
it will still just fail.
