Initially the git vars were assigned to the parent scope of the
_qt_internal_sbom_begin_project function, with the intent to set them
in the global scope. But the function was later wrapped in other
functions, so the variables stopped being accessible.
Instead of playing with recursive PARENT_SCOPEs, save the variables in
global properties like we do for other info, and use a new
_qt_internal_sbom_get_git_version_vars() function to query the vars in
the code that needs them.
This fixes generated purls to contain the git version and hashes.
Also add a new internal API wrapper macro called
qt_internal_sbom_get_git_version_vars to allow calling it
in other repos.
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Change-Id: I061b34f418c1ecc1c66c8c01ef758d2f40611ede
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add a new qt_internal_sbom_generate_tag_value_spdx_document function
that takes an input SPDX JSON file and generates a tag/value SPDX
file. This is needed by WebEngine to convert the Chromium JSON file to
a tag/value SPDX file so we can reference it as an external document.
To ensure the external document is found, we now always add the
current sbom build directories as install prefixes. This was
previously done only for top-level builds.
To ensure the converted external document is referenced only after it
is converted, it needs to be converted before any targets mention
packages from within it.
A sample usage might be:
qt_internal_sbom_generate_tag_value_spdx_document(
OPERATION_ID qt5compat
INPUT_JSON_FILE_PATH "${external_sbom_file_path}"
OUT_VAR_OUTPUT_FILE_NAME external_output_file_name
OUT_VAR_OUTPUT_ABSOLUTE_FILE_PATH external_output_file_path
)
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Task-number: QTBUG-129901
Task-number: QTBUG-131377
Change-Id: I5d5397f788c8c7960b6fc233c2868244e5816e0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add a new SBOM_RELATIONSHIPS option to qt_internal_extend_target and
friends that allows adding custom relationships to the current target.
Add a new function qt_internal_sbom_add_project_relationship that
allows adding custom relationships to the current project SBOM
document.
A sample usage might be:
qt_internal_sbom_get_project_spdx_id(project_spdx_id)
qt_internal_sbom_get_target_spdx_id(Svg svg_spdx_id)
qt_internal_extend_target(Svg
SBOM_RELATIONSHIPS
"${svg_spdx_id} DESCENDANT_OF ${project_spdx_id}"
)
qt_internal_sbom_add_project_relationship(
RELATIONSHIPS
"${svg_spdx_id} CONTAINS NOASSERTION"
"${svg_spdx_id} DESCRIBES NOASSERTION"
"${project_spdx_id} DESCRIBES NOASSERTION"
)
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Task-number: QTBUG-129901
Task-number: QTBUG-131377
Change-Id: Ie0119ca71b047c7515e1deaf84a5a67ea01b5274
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change modifies the existing implementation of the
external references API to have better named options and better
behavior.
It also adds comments and exposes an internal API wrapper around the
existing implementation.
It's meant to be used by qtwebengine to reference the
Chromium-generated SBOM.
As a drive-by, it removes the previously unused RENAME option.
A sample usage could be:
qt_internal_sbom_get_external_document_ref_spdx_id(
"qt5compat" document_ref_spdx_id)
qt_internal_sbom_add_external_reference(
EXTERNAL_DOCUMENT_FILE_PATH "/path/to/qt5compat-6.8.1.spdx.json"
EXTERNAL_DOCUMENT_SPDX_ID "${document_ref_spdx_id}"
)
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Task-number: QTBUG-129901
Task-number: QTBUG-131377
Change-Id: I13d0fe4d803449bec42f8b454c8131e4d727669a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Moss Heim <moss.heim@qt.io>
Allow including custom cmake files at predefined steps of the sbom
generation using the new internal
qt_internal_sbom_add_cmake_include_step API.
This covers pre-existing steps like BEGIN, END, POST_GENERATION, and
VERIFY, as well as two new steps, BEFORE_CHECKSUM and AFTER_CHECKSUM.
A sample usage of the new API could be:
set(step_path "${CMAKE_CURRENT_BINARY_DIR}/run_some_cmake.cmake")
file(WRITE "${step_path}"
"
# This is a CMake script to run some CMake code.
message(STATUS \"Running some CMake code...\")
message(STATUS \"Done running some CMake code.\")
"
)
foreach(step IN ITEMS BEGIN END BEFORE_CHECKSUM
AFTER_CHECKSUM POST_GENERATION VERIFY)
qt_internal_sbom_add_cmake_include_step(
STEP "${step}"
INCLUDE_PATH "${step_path}"
)
endforeach()
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Task-number: QTBUG-129901
Task-number: QTBUG-131377
Change-Id: I6f9512bf3a3bc3ebeb7d21426e5a3833280e42a5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change introduces a new SBOM API to add info about various kinds
of files to a target SBOM package. The new function name is called
qt_internal_sbom_add_files().
The motivating case is including SBOM information for qt translation
files, resources (e.g. webengine data files) and any other kind of
custom files.
A sample call might look like:
qt_internal_sbom_add_files(Translations
FILES "${qm_files}"
SOURCE_FILES_ONE_PER_INPUT_FILE "${ts_files}"
FILE_TYPE "QT_TRANSLATION"
INSTALL_PATH "${INSTALL_TRANSLATIONSDIR}"
)
While the motivating case is Qt-specific, the function implementation
is being somewhat future proofed for the not-yet created public SBOM
API.
The new API supports adding files to any target that is backed by an
SBOM package, so all targets created by qt_internal_add_module()
and friends, as well as ones created by qt_internal_add_sbom().
It can be called multiple times for the same target, with a different
set of files, to e.g. assign a different license, or file type per
file set. Note that the file set doesn't have anything to do with
CMake's concept of file sets.
The function is also multi-config aware, and allows specifying
different install paths per config, as well as generator expressions
in file names. But the multi-config support is a bit wonky, and might
need some rethinking in the future.
Note that the custom files must be installed and available in the
specified qt install path, because the file contents will be
checksummed at install time and embedded into the sbom document.
Calling the new API does not do installation itself.
Implementation wise, the function call flow is
- project calls qt_internal_sbom_add_files() one or more times
- at finalization time, the _qt_internal_sbom_add_target finalizer is
called for a target, which then calls
_qt_internal_sbom_handle_target_custom_files()
- the latter calls _qt_internal_sbom_handle_target_custom_file_set()
for each file set that was added to the target
- the latter calls _qt_internal_sbom_handle_multi_config_custom_file()
for each input file in the file set, which ultimately calls
_qt_internal_sbom_add_custom_file()
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Task-number: QTBUG-128320
Change-Id: Iafde26ebd68f4168b49e55fbc8ad1c251e98d4b0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Certain repositories like qtwebengine contain multiple projects from
the perspective of online installer packaging. In this case the
QtWebEngine and QtPdf projects are expected to have separate SBOM
documents.
Introduce a new QT_SKIP_SBOM_AUTO_PROJECT variable that can be set
before qt_build_repo to disable the auto-generation of an SBOM
document for the current repo project.
Introduce two new internal functions
qt_internal_sbom_begin/end_qt_repo_project to allow to manually start
and end the SBOM generation for a project within a repo.
Because the intermediate file names that assemble the SBOM use the
project name as a key, and the project name would be the same for
qtwebengine, allow differentiating between the current project name
and the real qt repo project name.
The current project name is used for the file names, whereas the
real qt repo project name is used to extract the dependencies on
other repos, to ensure correct dependency build rules.
As a drive-by, improve the document dir path search list when an SBOM
document can't be found.
Pick-to: 6.8
Task-number: QTBUG-128893
Task-number: QTBUG-122899
Change-Id: I61b68098242e7c49b98420265c29af78303c3233
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Alexandru Croitor