Some vendored 3rd party sources or libraries may not have a CPE
because the upstream disappeared, we don't know where the files
originally originated from, or no CPE was ever issued.
Given that the 3rd party files are shipped with Qt, they can
be considered as part of the "Qt" CPE for vulnerability tracking
reasons.
In such cases, we should add the Qt-specific CPE to the SBOM to ensure
that the SBOM is as complete as possible when tooling analyzes the
third party packages.
Task-number: QTBUG-122899
Change-Id: I32a70e24742a860198f3a6b12bdb4a06057f1ab3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 3cadd4b1f62479cce88c99cd8c95729ac10a6126)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Qt attribution json files might want to specify more than one PURL or
CPE for a given entry. Change the build system code to detect whether
a JSON PURL or CPE key contains an array of values, and if so, convert
it to a cmake list and use that for further SBOM handling.
As a result, the PURL_QT_VALUE, PURL_3RDPARTY_UPSTREAM_VALUE, and
PURL_MIRROR_VALUE getting an 'S' at the end, aka they are renamed to
PURL_QT_VALUES, PURL_3RDPARTY_UPSTREAM_VALUES, and PURL_MIRROR_VALUES.
Also the attribution key is now called just PURL instead of
UpstreamPURL.
The CPE json attribution key and option name stay the same.
Amends 47fd38be4bce0958fcfce8080d1580c4e3c2a15b
Amends 95b7fe49900904d19fca21876c84f97c2a6ae03d
Amends f7e1123620b623be0c321b54eaba7a1d618a7ce1
Task-number: QTBUG-122899
Change-Id: Ieec919901c3b44df80bc196536f68632a9761d92
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 797ce76ee946245898f9d11fa7e3ffb889e117d7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Instead, the package name should be determined by the sub-attribution
target name. Otherwise the build system will try to generate multiple
files with the same name, but different content.
Amends 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13
Task-number: QTBUG-122899
Change-Id: I10b4ec2fe8f38d70d13918dc980d1bd1d9145cb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit d624592ca40e05033432de72e0c4d9f6570b5544)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A project's root qt_attribution.json file might be picked up by the
build system when recording system libraries for SBOM processing.
One such case is qtgrpc.
This caused generation errors in qtgrpc with the following message:
CMake Error: Files to be generated by multiple different commands:
qt_sbom/SPDXRef-Package-qtgrpc-qt-3rdparty-sources-WrapProtobuf.cmake
This started happening since the SBOM options are now implicitly
propagated to auto-created attribution targets, and each attribution
target attempted to generate to the same partial sbom file.
Any qt attribution file in the project root is not intended to be
used for system libraries, so explicitly disable using the
root attribution file for all system libraries.
As a more long-term fix, we should consider making the partial sbom
files be more unique.
Amends 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13
Task-number: QTBUG-122899
Change-Id: I67544c299e630597f26602d270cd1dfd54cccfb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 55b399fdcd12bdfc645d4ec7d25b3c881d11a09a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Also split up the CPE handling to allow for more values to be set,
rather than preferring the first one that is encountered.
Task-number: QTBUG-122899
Change-Id: I3209cb5d66f5483c7294b40816431d9df75e00e5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 47fd38be4bce0958fcfce8080d1580c4e3c2a15b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Using a single PURL for a target is not enough to represent all the
information that an SBOM processing tool might want to know about.
For example for the bundled harfbuzz package, we want to inform at
least about two versions: the upstream version that was originally
imported into Qt sources, and the Qt version or sha1 of the sources
that were used, because the 3rdparty code might have been modified and
there might be new Qt-specific vulnerabilities.
To handle this, we need to generate multiple PURLs for a single
target.
Introduce six new options to be understood by qt_internal_add_module
and other SBOM functions:
- PURL_QT_ARGS
- PURL_MIRROR_ARGS
- PURL_3RDPARTY_UPSTREAM_ARGS
- PURL_QT_VALUE
- PURL_3RDPARTY_UPSTREAM_VALUE
- PURL_MIRROR_VALUE
The first three options take multiple arguments, and will generate a
PURL for each used variant, based on the purl parsing options that
were previously handled. For example passing:
PURL_3RDPARTY_UPSTREAM_ARGS
PURL_TYPE "github"
PURL_NAMESPACE "harfbuzz"
PURL_NAME "harfbuzz"
PURL_VERSION "v8.5.0" # tag
will generate a PURL pointing to the upstream harfbuzz repo hosted
on github.
The next three options allow specifying a purl value directly as a
single string, rather than as separate parts. This might be useful
when the PURL is pre-constructed and read from a qt_attribution file.
Example:
PURL_3RDPARTY_UPSTREAM_VALUE "pkg:github/harfbuzz/harfbuzz@v8.5.0"
When no arguments are specified, targets like Qt modules or Qt
3rd party libraries will have automatically generated QT and MIRROR
variant PURLs that point to code.qt.io and github.com, along with
important info like the version and subdir source path for a given
target.
Third party libraries are expected to be manually annotated with a
3RDPARTY_UPSTREAM variant PURL that points to the original upstream.
In a future change, these will be read from a qt_attribution.json
file.
The final set of generated PURLs for the harfbuzz package might look
like:
pkg:github/harfbuzz/harfbuzz@v8.5.0
pkg:github/qt/qtbase@5018b71e99f?library_name=BundledHarfbuzz#src/3rdparty/harfbuzz-ng
pkg:generic/TheQtCompany/qtbase-BundledHarfbuzz@5018b71e99f?vcs_url=https://code.qt.io/qt/qtbase.git@5018b71e99f&library_name=BundledHarfbuzz#src/3rdparty/harfbuzz-ng
Additionally a few more purl parsing options are added.
Add a PURL_USE_PACKAGE_VERSION option that will use the
qt_attribution.json or custom PACKAGE_VERSION value as the PURL
version, so it doesn't have to be manually specified.
This is an opt-in, and not the default, because some attribution
files contain plain text, white-space separated, strings as the
version value (like the 'sha3' 3rd party lib) which ends up generating
a broken PURL and a failing JSON conversion of the SBOM.
So we have to manually annotate targets that should use the
attribution json package version, until a better way to handle this
can be found.
Add a PURL_VCS_URL option that will generate a PURL qualifier (a HTTP
query parameter) with the given value, to indicate to SBOM-processing
tools what is the upstream repo URL for the package.
They can use this information to display known vulnerabilities for the
package hosted at that URL.
This is mostly useful for the generic QT purl variant, and is
automatically generated for Qt entity types.
Task-number: QTBUG-122899
Change-Id: Ie000b01b478bef4bff6f4803dd39e37b7a8055d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit f7e1123620b623be0c321b54eaba7a1d618a7ce1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They should inherit the version of the 3rd party library they are part
of, and not be treated as Qt modules.
Task-number: QTBUG-122899
Change-Id: Ibf99f4481fbc1acca488fc96cca048298b080d35
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit b17dfbbb992b1d38d7a1aeb2b0109bab9cb1e4e3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously if an option like CPE was passed to a 3rd party target that
would create nested attribution targets, one per entry in the
attribution file, the CPE option would only apply to the first /
parent target, but not to the nested targets.
This change will now propagate all SBOM options to the nested targets,
but only if the parent target is not a Qt entity type like a module,
plugin, etc, which means it will only apply to 3rd party attribution
targets. The restriction is there because because mostly only 3rd
party attribution targets should inherit the same set of CPEs and
similar SBOM values.
If the restriction proves to be too strict, it will be re-assessed in
a future change.
Task-number: QTBUG-122899
Change-Id: I96cfa046ad611c10877b7a06504b35615b539bbe
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 5daabb5a74c4e7c5d087da7f9207d79d2ee05b13)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add code to generate and install a source SBOM SPDX file for every
repo. It relies on the python 'reuse' tool being installed and
available in PATH.
Also add code to allow running 'reuse lint', which checks compliance
with the reuse specification.
The features are only enabled when configuring with
-DQT_GENERATE_SBOM=ON
-DQT_GENERATE_SOURCE_SBOM=ON
-DQT_LINT_SOURCE_SBOM=ON
which will be the case for our CI in a follow up patch.
Because most of our repos are not yet reuse compliant, the actual
generation of the source SBOM and the linting is skipped if the
project root directory does not contain a REUSE.toml file.
This allows incremental handling of each repository, while also
enforcing the compliance at installation time when the REUSE.toml file
is actually there.
The source SBOM generation and linting will run at installation time,
but they can also be manually triggered at build time using the
ninja 'sbom' and 'reuse_lint' custom targets.
Various opt outs are provided as a fail safe:
- QT_FORCE_SOURCE_SBOM_GENERATION to force source sbom generation
even if a REUSE.toml file is not present in the root source dir
- QT_FORCE_REUSE_LINT_ERROR to force linting to error out, even if
a REUSE.toml file is not present
- QT_FORCE_SKIP_REUSE_LINT_ON_INSTALL to skip linting at installation
time, but allow running it at build time
These can be set either locally or conditionally passed to CMake
inside repo-specific Coin instructions.
Task-number: QTBUG-122899
Task-number: QTBUG-125211
Change-Id: I664e69830936c4427688143ee86b98782c1733ab
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 6d9b4291746907e30ea49ac0adf8608ad8a1129b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Tools that consume SBOMs expect that each SBOM package will contain a
unique purl: https://github.com/package-url/purl-spec
Each Qt target maps to an SBOM package, so generate a target-specific
PURL for each Qt target, by using the combination of the repo name
and target name as the purl name.
The purl external reference will then look something like:
ExternalRef: PACKAGE-MANAGER purl pkg:/TheQtCompany/qtbase-Gui@6.8.0
Also allow customizing the purl for each target by specifying one of
the following options to functions like qt_internal_add_module or
qt_internal_extend_sbom:
- PURL_TYPE
- PURL_NAMESPACE
- PURL_NAME
- PURL_VERSION
- PURL_SUBPATH
- PURL_QUALIFIERS
- NO_PURL
- NO_DEFAULT_QT_PURL
Task-number: QTBUG-122899
Change-Id: I6926dd773a0ef6fc688664bcac7b23483ecbabe6
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit f6fdc1fe5fde253d7e70a2d2bbef42e9c411956e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
For some targets, it might not be possible to specify all 3rd party
dependencies information for SBOM generation.
qtwebengine is one of these cases, where the 3rd party targets are
only known to GN, and not CMake.
Add a new SBOM_INCOMPLETE_3RD_PARTY_DEPENDENCIES option which can be
passed to qt_internal_add_module and friends.
This will include an informational message into the SBOM package
comment field that the dependency information might be incomplete.
Also add an SBOM_PACKAGE_COMMENT option, which can be used to provide
further information if necessary.
Task-number: QTBUG-122899
Change-Id: I5e893e1e205aae4a5591a457be88d5db54fa8fc3
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
(cherry picked from commit 04ade5acc923ae04142004551ce8c7560517d192)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Usually apps created by qt_internal_add_app() are not meant for
installation on Android, and are excluded from installation using
qt_exclude_tool_directories_from_default_target().
Some repos might be missing the exclusion call, which means the app
would be built and installed on Android.
qt_internal_add_app creates MODULE_LIBRARYs instead of EXECUTABLEs
when targeting Android. While the SBOM machinery only expects
EXECUTABLEs for apps.
If the app target is not excluded (in which case the SBOM would be
skipped), this would cause the SBOM code to error out saying the
target type is unsupported.
To prevent further errors like this, add MODULE_LIBRARY as a valid
target type for qt apps.
Task-number: QTBUG-122899
Change-Id: I3ec80add22f0584638990171c59b78c24725c052
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit d24936dbdc85d5fe875b5d3df702630df4d4ba9d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need to pass all dirs where sboms will be generated, for external
document referencing.
We also need to set up dependencies between the repo sbom custom
targets, so that qtsvg sbom is only run after qtbase sbom.
We use the dependencies.yaml info to set up the dependencies.
Task-number: QTBUG-122899
Change-Id: Id3331e11742bc2c86e7ed52ce26b3ff21eace359
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 31126b2b775ae52a0d74aadf1aff8f6d79d0c6be)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a target has the _qt_internal_excluded_from_default_target property
set, don't try to add file SBOM information for the target, because
the file will not be built nor installed by default.
We check for a new custom _qt_internal_excluded_from_default_target
property instead of EXCLUDE_FROM_ALL, because EXCLUDE_FROM_ALL might
be set to a genex that excludes all configs except the main one, but
we are interested whether the target is entirely excluded.
Task-number: QTBUG-122899
Change-Id: I79d6a4b0c65356da14f7ff50ee3639705f5fabbd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 34b5dc041b0d34a76c081719fafa8f48265e34ae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need it to disable generation for certain repos like qtqa, even
if the platform config says that SBOMs should be enabled.
We can't just set QT_GENERATE_SBOM to OFF, because the general SBOM
CI instructions are added later that module specific ones, and thus
would override the value back to ON.
Providing a separate internal variable allows us to disable it with a
higher priority.
Task-number: QTBUG-122899
Change-Id: If7803ae4aac0886d605a542e3f05ad9533bb8108
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 0ea3164969bbc7eda71bcf77e716e2a8ec23c8c4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Un-alias system target names before processing them for the SBOM,
otherwise we'll get errors about trying to set properties on alias
targets.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: Ifef2108be123549505ed67f0b9c258a10431c84e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 089111aee0d4a98900aa35fa24d1a9cbbb03b905)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In certain cases the qt_find_package(PROVIDED_TARGETS) might not
exist, so we shouldn't record the targets for SBOM spdx id
registration in that case.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: Iada6b5a20a3e7526f18ae4385db8a29fee68ab36
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 0f5699ee3ddb2ec426f1b9c51484ec96241db8bf)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add a NO_ATTRIBUTION_LICENSE_ID option to allow to skip including
license references from qt_attribution.json files.
Add a QT_LICENSE_ID option that can take an "id" value and return one
of the common license expressions we use throughout Qt repositories:
- GPL3 with exception for tools / apps
- GFDL for documentation
- GPL3 only modules
etc.
Add a QT_SBOM_DEFAULT_QT_LICENSE_ID_LIBRARIES variable that can be set
at directory scope (or root repo scope) to use a specific license id
for all qt modules / plugins created within that repo, e.g. the
Commercial + GPL3 variant. These can be opted out, to fallback to the
"default" license by passing NO_DEFAULT_QT_LICENSE_ID_LIBRARIES.
Add a similar variable QT_SBOM_DEFAULT_QT_LICENSE_ID_EXECUTABLES
for tools / apps, including a NO_DEFAULT_QT_LICENSE_ID_EXECUTABLES
option.
Modify the logic for setting licenses for qt targets:
- use whatever is set in QT_SBOM_DEFAULT_QT_LICENSE_EXECUTABLES
for tools and apps
- or use the 'GPL3 with exception' variant for tools and apps
- use whatever is set in QT_SBOM_DEFAULT_QT_LICENSE_LIBARRIES for
modules ands plugins
- or use the default Commercial + LGPL3 + GPL variant for
modules and plugins
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: I3a8abac62b9f4b342f91ef139064884f02aa935e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit fe90ba704168d47cf88d0c6512380b525f38f5d3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Previously, only a very short subset of options related to attribution
files could be specified to qt_internal_add_module /
qt_internal_extend_target.
It is more convenient to allow specifying most (safe) options, instead
of calling another function.
Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE
which is too generic, and some other ones like LIBRARIES which would
be duplicated, and causes warnings in cmake_parse_arguments if
duplicated.
Change the code to allow specifying most SBOM options and forwarding
them to _qt_internal_extend_sbom.
Task-number: QTBUG-122899
Change-Id: I6eb723e165edf59973d83c66eace43acdce237de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 81162cc8b6931c8659dc722be97eb788e344812a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The value should be taken from the QT_SBOM_LICENSE_EXPRESSION
variable. The '_qt_internal_sbom_get_default_qt_license_id' was a copy
paste error.
Amends 37a5e001277db9e1392a242171ab2b88cb6c3049
Task-number: QTBUG-122899
Change-Id: I4bcfaaf06af8903af7081130ba3c8285a53d8f4f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 8f04225c5af2a5cb31d2452342b4ec35a10bf77b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 37a5e001277db9e1392a242171ab2b88cb6c3049)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
