Repeated calls to `resolve` can experience performance degredation, if
`add_implicit_resolver` has been called with `first=None` (to add an
implicit resolver with an unspecified first character).
For example, every time `foo` is encountered, the "wildcard implicit
resolvers" (with `first=None`) will be appended to the list of implicit
resolvers for strings starting with `f`, which will normally be the
resolver for booleans. The list `yaml_implicit_resolvers['f']` will keep
getting longer. The same behavior applies for any first-letter matches
with existing implicit resolvers.
This change avoids unintentionally mutating the lists in the class-level
dict `yaml_implicit_resolvers` by looping through a temporary copy.
Fixes: #439
* 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>
* Prevents arbitrary code execution during python/object/new constructor
In FullLoader python/object/new constructor, implemented by
construct_python_object_apply, has support for setting the state of a
deserialized instance through the set_python_instance_state method.
After setting the state, some operations are performed on the instance
to complete its initialization, however it is possible for an attacker
to set the instance' state in such a way that arbitrary code is executed
by the FullLoader.
This patch tries to block such attacks in FullLoader by preventing
set_python_instance_state from setting arbitrary properties. It
implements a blacklist that includes `extend` method (called by
construct_python_object_apply) and all special methods (e.g. __set__,
__setitem__, etc.).
Users who need special attributes being set in the state of a
deserialized object can still do it through the UnsafeLoader, which
however should not be used on untrusted input. Additionally, they can
subclass FullLoader and redefine `get_state_keys_blacklist()` to
extend/replace the list of blacklisted keys, passing the subclassed
loader to yaml.load.
* Make sure python/object/new constructor does not set some properties
* Add test to show how to subclass FullLoader with new blacklist
* On load, now use aware datetimes if possible
On loading data, if timestamps have an ISO "+HH:MM" UTC offset then the resultant datetime is converted to UTC. This change adds that timezone information to the datetime objects.
Importantly, this addresses a Django warning (and potential error) that appears when using both YAML fixtures in a timezone-aware project. It was raised as a Django issue (https://code.djangoproject.com/ticket/18867), but subsequently closed because the Django devs felt that this is a PyYAML problem.
* Create timezone-aware datetime in timezone from data
* Create timezone-aware datetime in timezone from data for python2
* Define better timezone implementation for python2
* Handle timezone "Z" for python 3
* Handle timezone "Z" for python 2
* Fix code structure for Python 3
Call datetime.datetime constructor once at return.
* Fix code structure for Python 2
Call datetime.datetime constructor once at return.
* 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
When someone writes a subclass of the YAMLObject class, the constructors
will now be added to all 3 (non-safe) loaders.
Furthermore, we support the class variable `yaml_loader` being a list,
offering more control of which loaders are affected.
To support safe_load in your custom class you could add this:
yaml_loader = yaml.SafeLoader
yaml_loader = yaml.YAMLObject.yaml_loader
yaml_loader.append(yaml.SafeLoader)
In Python 3.7, importing ABCs directly from the 'collections' module shows a
warning (and in Python 3.8 it will stop working) - see
c66f9f8d39
Since this is only done in lib3/ which is Python 3 only, we can unconditionally
import it from collections.abc instead.
This fixes the following DeprecationWarning:
.../site-packages/yaml/__init__.py:75: in load
return loader.get_single_data()
.../site-packages/yaml/constructor.py:37: in get_single_data
return self.construct_document(node)
.../site-packages/yaml/constructor.py:46: in construct_document
for dummy in generator:
.../site-packages/yaml/constructor.py:398: in construct_yaml_map
value = self.construct_mapping(node)
.../site-packages/yaml/constructor.py:204: in construct_mapping
return super().construct_mapping(node, deep=deep)
.../site-packages/yaml/constructor.py:126: in construct_mapping
if not isinstance(key, collections.Hashable):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
name = 'Hashable'
def __getattr__(name):
# For backwards compatibility, continue to make the collections ABCs
# through Python 3.6 available through the collections module.
# Note, no new collections ABCs were added in Python 3.7
if name in _collections_abc.__all__:
obj = getattr(_collections_abc, name)
import warnings
warnings.warn("Using or importing the ABCs from 'collections' instead "
"of from 'collections.abc' is deprecated, "
"and in 3.8 it will stop working",
> DeprecationWarning, stacklevel=2)
E DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
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.
From the Psyco website:
> 12 March 2012
>
> Psyco is unmaintained and dead. Please look at PyPy for the
> state-of-the-art in JIT compilers for Python.
http://psyco.sourceforge.net/
