The pypi class default python:pyyaml vendor prefix matches nothing,
so PyYAML CVEs are not evaluated at all. The databases use two
vendor spellings: pyyaml in the NVD CPEs, and "Red Hat" (with a
space, not expressible as a vendor:product pair) in CVE-2020-1747's
CNA record. Use the bare product name to cover both.
All four existing CVEs (CVE-2017-18342, CVE-2019-20477,
CVE-2020-1747, CVE-2020-14343) are fixed by 5.4, so they resolve as
not affected at 6.0.1.
Note: Original commit was for python3-pyyaml_6.0.3.bb. This is adjusted
for scarthgap where recipe version is python3-pyyaml_6.0.1.bb.
(From OE-Core rev: 666e25c1fe1347da307726afd87554ffc080ed12)
Signed-off-by: mark.yang <mark.yang@lge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 89a0ba3c2da2a7755bafb28afbf75dc7112e2549)
Signed-off-by: Himanshu Jadon <hjadon@cisco.com>
Signed-off-by: Fabien Thomas <fabien.thomas@smile.fr>
Signed-off-by: Paul Barker <paul@pbarker.dev>
python 2 is gone and we don't need the abstraction now, drop the remaining usage
of this variable.
The definition in python3-dir.bbclass is left for now for other layers.
(From OE-Core rev: b566b1e32c7993d1ab7795562f648e52ce186a70)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream is in the process of migrating testing to pytest, backport
test_dump_load.py (the legacy_tests were throwing Errors and Failures).
We don't really need to run upstream's test suite, but we do need to verify
that our runtime is functional.
a98fd6088e
(From OE-Core rev: b0fdf0688109ba6b87840a0837bebee3d9a27089)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some time now, we have probably been susceptible to host contamination
or at least non-deterministic behavior when libyaml was available in the
build environment.
The symptom is:
ERROR: python3-pyyaml-6.0-r0 do_package_qa: QA Issue:
/usr/lib/python3.11/site-packages/yaml/_yaml.cpython-311-aarch64-linux-gnu.so
contained in package python3-pyyaml requires libyaml-0.so.2()(64bit), but no
providers found in RDEPENDS:python3-pyyaml? [file-rdeps]
>From the documentation:
"""
By default, the setup.py script checks whether LibYAML is installed and
if so, builds and installs LibYAML bindings. To skip the check and force
installation of LibYAML bindings, use the option --with-libyaml:
python setup.py --with-libyaml install
To disable the check and skip building and installing LibYAML bindings,
use --without-libyaml:
python setup.py --without-libyaml install
"""
Instead of leaving this to chance, add PACKAGECONFIG and by default build
with the faster libyaml bindings.
(From OE-Core rev: dfde9526f9183907b2bc47fde4f59ab3a5848d90)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has been rejected by upstream in favour of requiring obsolete cython
until there's 'proper' 3.x support. Months later, there's still no progress
so let's just take the rejected fix, as it does work (as reported by others as well),
and allows moving forward with cython.
(From OE-Core rev: cf4e45176a37b6f53a6316ec6b1556d6aea39b57)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
