qt/qtqa/scripts/sbom
Name Description Size Coverage
check_file_coverage.py check_file_coverage.py — Audit file-level SBOM coverage of an installed Qt tree, in both directions: forward Is every shipped binary recorded in one of the SBOM documents under <prefix>/sbom? Scoped to --dirs, which defaults to the six directories Qt's SPDX documents actually record into: bin, lib, libexec, plugins, qml, translations. Auditing the whole prefix instead adds no binaries at all (verified on a 6.12.0 macOS install: 523 either way) and drowns the report in headers, CMake files and QML sources that no SBOM lists. reverse Does every file recorded in those documents actually exist in the install tree? Never scoped by --dirs: a stale entry is a defect wherever it points, and the documents also cover plugins/, qml/ and translations/. documents Does every module ship the full set of SBOM formats? A module with no *.cdx.json has zero CycloneDX coverage no matter what its SPDX documents say. Why file coverage is computed from the SPDX documents, not the CycloneDX ones: Qt ships both *.cdx.json (CycloneDX 1.6) and *.spdx / *.spdx.json (SPDX 2.3) per module. Only the SPDX documents carry file-level data ('files' entries with fileName + SHA1). The CycloneDX documents describe packages only — as of 6.12.0 not one of them populates evidence.occurrences, so they contain no installed path anywhere and coverage simply cannot be checked against them. Since both formats are emitted from the same component set (CycloneDX bom-refs are the SPDX SPDXRef-Package ids), a file missing from the SPDX documents is missing from the CycloneDX ones too. The script reports the CycloneDX occurrence count so a regression there stays visible. The tag-value *.spdx documents are not read: they carry the same FileName set as their *.spdx.json counterparts. The *.source.spdx documents are not read either — they describe the module's source tree (tens of thousands of paths relative to the git repository, not to the install prefix), so they say nothing about installed files. Files are classified by magic bytes rather than by extension, because Qt's macOS framework binaries and its universal static libraries carry no recognizable suffix (a universal .a is a fat Mach-O, not '!<arch>'). On --verify-sha1 in an *installed* tree: Expect mismatches on every code-signed Mach-O. Installers re-sign and install_name_tool-relocate binaries after the SBOM checksums are written, so frameworks and executables legitimately differ from their recorded SHA1. Static .a files and data files such as .qm translations are not touched and should always match — those are the meaningful integrity signal here. Usage: python check_file_coverage.py ~/Qt/6.12.0/macos python check_file_coverage.py <prefix> --dirs bin,lib,libexec python check_file_coverage.py <prefix> --verify-sha1 python check_file_coverage.py <prefix> --reverse-only Exit code is 0 only if every binary and static library found is recorded in some SBOM, and every recorded file exists on disk as a regular non-empty file. Unrecorded scripts and data files, and incomplete SBOM document sets, are reported but do not affect the exit code. 15920 -
check_purl.py check_purl.py — Validate github/gitlab Package URLs (PURLs) and check whether the repo (and optional version/ref) actually exists. Why not aboutcode-org/purldb-toolkit for this? purldb-toolkit's `purlcli validate` command is a good general-purpose purl validator, but its existence check ("check_existence") only covers cargo, composer, deb, gem, golang, hex, maven, npm, nuget and pypi (per its own source: purldb_toolkit/purlcli.py, validate_purl()). `github` and `gitlab` are not in that list, so it falls back to "check_existence_not_supported" for exactly the two types we care about here. Syntax validation (via packageurl-python, which purldb- toolkit also uses under the hood) works fine for these types — it's only the existence check that's missing — so this script covers that gap by querying the GitHub/GitLab APIs directly. Requires: pip install packageurl-python requests Usage: python check_purl.py pkg:github/psf/requests@v2.31.0 python check_purl.py pkg:gitlab/gitlab-org/gitlab@master python check_purl.py --file purls.txt # one purl per line python check_purl.py --github-token YOUR_GH_TOKEN pkg:github/psf/requests Exit code is 0 only if every purl resolved to 'ok' or was skipped (non github/gitlab type). Any 'not found', 'error' (couldn't verify — e.g. rate limit or network issue), or 'invalid' (malformed syntax) result causes a non-zero exit and is broken out in the summary printed at the end. 11930 -