fix(gen-sbom): unique serialNumber/documentNamespace per build config

[MarkAtwood]

serial and doc_ns_uuid were derived only from (name, version), so two
SBOMs for the same release but different build configuration (FIPS vs
non-FIPS, a different --srcs set, a different feature-flag/dependency set)
shared an identical CycloneDX serialNumber and SPDX documentNamespace
despite differing content: an SPDX 2.3 §6.5 uniqueness violation, and a
CycloneDX version: 1 with a shared serial over differing content is
self-contradictory.

Folds a config_identity digest into the serial/documentNamespace seed.
Different configs now get distinct identifiers; an identical config still
reproduces byte-for-byte. bom-refs and the UUID namespace are unchanged, and
both claims are now asserted.

What reaches the digest

The rule the generator holds to: every CLI input that can change the emitted
document body reaches the identity digest.

• artifact hash (lib_hash) and how it was obtained (hash_kind,
  hash_source)
• licence identifier and a digest of the licence text
• supplier, component type
• sorted build macros
• enabled deps and their resolved versions
• artefact/source filenames the document names
• the crypto-only subset claim and its basis

Tests

tests/test_sbom_identity.py, in three layers:

1. Unit on config_identity: each folded field is load-bearing, fields do
   not alias, ordering is stable, the positional five-argument call still
   works.
2. End-to-end table, one row per identity-relevant option, driving the real
   script under a fixed SOURCE_DATE_EPOCH and comparing real documents. Each
   row asserts the body changed first, then that the identity moved, so a row
   that stops exercising anything fails instead of passing vacuously.
3. Option-set canary: an ast walk over gen-sbom's own add_argument
   calls, checked against a declared identity-relevant/exempt split. A new
   option cannot land without being classified, and every exemption carries its
   reason.

Reverting the generator change and re-running the table fails on --supplier,
--component-type, --crypto-only, --lib (renamed, identical bytes), and
--license-text. --no-artifact-hash correctly does not fail: it moves
lib_hash to the sentinel, which was already folded.

Wired into selftest.yml. Full suite green: 23 identity tests, 210 generator
tests, self-test.

Identifier rotation

Identifiers rotate once. SBOMs published before this carry the old values.
They were previously wrong (colliding across configurations), and nothing
downstream pins a literal serialNumber. Documented in README.md under
Document identity.

Design call, stated explicitly

Folding lib_hash in means the identity follows the built binary on the
--lib path, so recompiling identical sources with a different toolchain moves
the serialNumber even though no configuration input changed. That is
deliberate: an SBOM generated from --lib describes one specific binary, and
two binaries with different hashes are two artefacts. The --srcs and
--no-artifact-hash paths do not have this property, because neither hashes a
compiler output.

Backport

This touches the shared gen-sbom engine. The wolfSSL copy
(wolfssl#10343) is not byte-identical any more: the two diverged by roughly
125 lines when four commits landed after the original rebase here, and
wolfssl#11120 is adding ~460 more. The backport still matters, because wolfBoot
vendors the wolfSSL copy and gets none of this until it happens. The
doc/SBOM.md rotation note belongs to that backport: doc/SBOM.md lives in
wolfssl, not in wolfGlass, so the note is in README.md here.

Addresses SBOM-gpex.6.

[Copilot]

Pull request overview

This PR updates the shared share/gen-sbom generator so CycloneDX serialNumber and SPDX documentNamespace become unique per build configuration, not just per (name, version), by folding a stable config_identity digest into the UUID seed. It also adds unit + end-to-end tests and wires them into CI.

Changes:

• Add config_identity() to hash build-distinguishing inputs (artifact hash, license ID, build macros, enabled deps + resolved versions).
• Include config_identity in the derived UUID seed for serialNumber and documentNamespace.
• Add tests/test_sbom_identity.py and run it in .github/workflows/selftest.yml.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
share/gen-sbom	Adds config_identity() and folds it into UUID seeding for serial/document namespace uniqueness per config.
tests/test_sbom_identity.py	New unit + end-to-end coverage for identity reproducibility and per-config uniqueness.
.github/workflows/selftest.yml	Adds syntax-check and execution of the new SBOM identity tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sameehj]

Reviewed and ran the suite on top of current master: rebases clean, all 210
generator tests plus the self-test and your 7 new ones pass, and no test or
tool pins a literal serial. The approach is right and the tag/NUL framing is
correct. Two things before merge.

1. The digest is incomplete. I generated pairs of SBOMs on the merged tree.
   These four change the document body but not the serialNumber, so the
   collision survives:

   • --supplier
   • --component-type
   • --crypto-only
   • --lib renamed with identical bytes (the basename reaches the doc via
     file_entries, never via lib_hash)

   --component-type and --crypto-only are the ones that matter for
   wolfBoot#830, which passes both (sbom.mk:179,188). Please also fold in
   hash_kind, hash_source, subset_basis, and a digest of
   license_text. Keyword-only params with defaults keeps your existing unit
   tests valid. Every value is already in scope at the call site.

   Worth doing in this PR rather than a follow-up: each change to
   config_identity rotates all identifiers, and we should pay that once.

2. Tests. The current tests assert the fix works for the cases you fixed. Two
   additions would catch the rest:

   • Table-driven: one row per content-affecting flag, asserting that a
     changed body implies a changed serial. Fails today on the four above.
   • A canary comparing the add_argument flag set (via ast) against a
     known identity-relevant/exempt split, so the next new option cannot land
     without a decision.

Smaller:

• SourceFileLoader.load_module() is deprecated; Python 3.11 already warns
  "slated for removal in 3.12" and CI floats on python-version: '3.x'.
  tests/test_gen_sbom.py already uses spec_from_loader/exec_module.
• Nothing asserts the "bom-refs unchanged" claim. One assertion would pin it.
• Please note the rotation in doc/SBOM.md.

One design call to make explicit: folding lib_hash in means the serial
follows the binary on the --lib path, so a toolchain change alone moves it.
Defensible, but let's state the intent rather than leave it implicit.

FYI the "byte-identical to wolfssl#10343" note is stale. The copies already
diverged by ~125 lines when the four commits landed after your rebase. The
backport still matters, because wolfBoot vendors the wolfSSL copy and gets
nothing until it happens.

[sameehj]

Approving the content. Rebase and I will merge.

The block is mechanical. This went dirty after you pushed, and master is now
b3bccce. The only conflicting file is .github/workflows/selftest.yml, because
later PRs edit the same test list. gen-sbom, README.md and the new test file
are untouched on master, so nothing conflicts semantically.

Verified independently of your table: --supplier, --component-type,
--crypto-only, the --lib rename and --no-artifact-hash all move the
serialNumber, and it stays stable across working directories. I also mutation-
tested the tests, adding an unclassified option and dropping supplier and
file_names from the digest. All three were caught, by both the unit test and
the matching row. Full suite green on your head. Good catch on --license-text,
and pinning the UUID namespace as a literal beats what I asked for.

Nit, not blocking: setUpClass raises on missing pcpp where the rest of the repo
skips. CI installs it, and a skip would hide the --user-settings rows, so your
call.

Two follow-ups, not for this PR. The "byte-identical to wolfssl#10343" note is
stale after #7, #5, #11 and #18. And merging will not reach wolfBoot#830 by
itself, because wolfBoot pins .wolfglass-rev at d34a906 and needs a re-vendor
and pin bump afterwards.