mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 00:20:08 +00:00
Code Issues Projects Releases Wiki Activity

SPDX and CVE documentation updates

Browse Source 
Backporting from master the ones that are applicable to kirkstone.

(From yocto-docs rev: c10d65ef3bbdf4fe3abc03e3aef3d4ca8c2ad87f)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2022-12-02 15:50:48 +01:00
committed by Richard Purdie
parent be95d5f93a
commit c883909950
5 changed files with 442 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/ref-manual/classes.rst
+93 -3
View File
@@ -361,6 +361,32 @@ authors used.
Both build methods inherit the ``cpan-base`` class for basic Perl
support.
.. _ref-classes-create-spdx:
``create-spdx.bbclass``
=======================
The :ref:`create-spdx <ref-classes-create-spdx>` class provides support for
automatically creating :term:`SPDX` :term:`SBOM` documents based upon image
and SDK contents.
This class is meant to be inherited globally from a configuration file::
INHERIT += "create-spdx"
The toplevel :term:`SPDX` output file is generated in JSON format as a
``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
:term:`Build Directory`. There are other related files in the same directory,
as well as in ``tmp/deploy/spdx``.
The exact behaviour of this class, and the amount of output can be controlled
by the :term:`SPDX_ARCHIVE_PACKAGED`, :term:`SPDX_ARCHIVE_SOURCES` and
:term:`SPDX_INCLUDE_SOURCES` variables.
See the description of these variables and the
":ref:`dev-manual/common-tasks:creating a software bill of materials`"
section in the Yocto Project Development Manual for more details.
.. _ref-classes-cross:
``cross.bbclass``
@@ -396,14 +422,62 @@ discussion on these cross-compilation tools.
``cve-check.bbclass``
=====================
The ``cve-check`` class looks for known CVEs (Common Vulnerabilities
and Exposures) while building an image. This class is meant to be
The :ref:`cve-check <ref-classes-cve-check>` class looks for known CVEs (Common Vulnerabilities
and Exposures) while building with BitBake. This class is meant to be
inherited globally from a configuration file::
INHERIT += "cve-check"
To filter out obsolete CVE database entries which are known not to impact software from Poky and OE-Core,
add following line to the build configuration file::
include cve-extra-exclusions.inc
You can also look for vulnerabilities in specific packages by passing
``-c cve_check`` to BitBake. You will find details in the
``-c cve_check`` to BitBake.
After building the software with Bitbake, CVE check output reports are available in ``tmp/deploy/cve``
and image specific summaries in ``tmp/deploy/images/*.cve`` or ``tmp/deploy/images/*.json`` files.
When building, the CVE checker will emit build time warnings for any detected
issues which are in the state ``Unpatched``, meaning that CVE issue seems to affect the software component
and version being compiled and no patches to address the issue are applied. Other states
for detected CVE issues are: ``Patched`` meaning that a patch to address the issue is already
applied, and ``Ignored`` meaning that the issue can be ignored.
The ``Patched`` state of a CVE issue is detected from patch files with the format
``CVE-ID.patch``, e.g. ``CVE-2019-20633.patch``, in the :term:`SRC_URI` and using
CVE metadata of format ``CVE: CVE-ID`` in the commit message of the patch file.
If the recipe lists the ``CVE-ID`` in :term:`CVE_CHECK_IGNORE` variable, then the CVE state is reported
as ``Ignored``. Multiple CVEs can be listed separated by spaces. Example::
CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511"
If CVE check reports that a recipe contains false positives or false negatives, these may be
fixed in recipes by adjusting the CVE product name using :term:`CVE_PRODUCT` and :term:`CVE_VERSION` variables.
:term:`CVE_PRODUCT` defaults to the plain recipe name :term:`BPN` which can be adjusted to one or more CVE
database vendor and product pairs using the syntax::
CVE_PRODUCT = "flex_project:flex"
where ``flex_project`` is the CVE database vendor name and ``flex`` is the product name. Similarly
if the default recipe version :term:`PV` does not match the version numbers of the software component
in upstream releases or the CVE database, then the :term:`CVE_VERSION` variable can be used to set the
CVE database compatible version number, for example::
CVE_VERSION = "2.39"
Any bugs or missing or incomplete information in the CVE database entries should be fixed in the CVE database
via the `NVD feedback form <https://nvd.nist.gov/info/contact-form>`__.
Users should note that security is a process, not a product, and thus also CVE checking, analyzing results,
patching and updating the software should be done as a regular process. The data and assumptions
required for CVE checker to reliably detect issues are frequently broken in various ways.
These can only be detected by reviewing the details of the issues and iterating over the generated reports,
and following what happens in other Linux distributions and in the greater open source community.
You will find some more details in the
":ref:`dev-manual/common-tasks:checking for vulnerabilities`"
section in the Development Tasks Manual.
@@ -1975,6 +2049,22 @@ When inherited by a recipe, the ``perlnative`` class supports using the
native version of Perl built by the build system rather than using the
version provided by the build host.
.. _ref-classes-pypi:
``pypi.bbclass``
================
The :ref:`pypi <ref-classes-pypi>` class sets variables appropriately for recipes that build
Python modules from `PyPI <https://pypi.org/>`__, the Python Package Index.
By default it determines the PyPI package name based upon :term:`BPN`
(stripping the "python-" or "python3-" prefix off if present), however in
some cases you may need to set it manually in the recipe by setting
:term:`PYPI_PACKAGE`.
Variables set by the :ref:`pypi <ref-classes-pypi>` class include :term:`SRC_URI`, :term:`SECTION`,
:term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX`
and :term:`CVE_PRODUCT`.
.. _ref-classes-python_flit_core:
``python_flit_core.bbclass``