Skip to content

fix: validate release SBOM semantics - #519

Merged
codeforester merged 3 commits into
mainfrom
bug/456-20260917-bug-emit-standards-valid-spdx-file-identifiers-and-validate
Sep 18, 2026
Merged

codeforester merged 3 commits into
mainfrom
bug/456-20260917-bug-emit-standards-valid-spdx-file-identifiers-and-validate

Conversation

@codeforester

Copy link
Copy Markdown
Collaborator

Summary

Add the SPDX-required SHA1 checksum to every generated file record while retaining SHA256. Independently parse and semantically validate candidate SBOMs with the pinned spdx-tools 0.8.5, including a negative semantic fixture.

Issue

Fixes #456

Validation

  • bats tests/release-artifact.bats — passed (11 tests).
  • Built a 2.2.0 artifact and validated it with spdx-tools 0.8.5 — passed.
  • The parseable missing-SHA1 fixture was rejected specifically for its semantic checksum error — passed.
  • bash -n scripts/release-artifact, ShellCheck, and git diff --check — passed.

Docs Impact

Documents SBOM validation and immutable published assets in docs/release-process.md.

CI Impact

Adds pinned independent SBOM validation on Linux.

@codeforester

Copy link
Copy Markdown
Collaborator Author

Multi-angle review of this PR (SPDX-required SHA1 + independent spdx-tools validation, closes #456). Three findings, ranked by severity:

1. write_sbom()'s format change has no version/format gate, and the same function is used to reconstruct the expected SBOM for verify/verify-remote's byte-exact comparison. Since the change is unconditional, running scripts/release-artifact verify-remote against any already-published pre-2.2.0 release (e.g. the real published v2.1.0 GA, whose SBOM has no SHA1) will now regenerate an SBOM with SHA1 and fail the cmp -s check against the real asset. Every previously published release becomes unverifiable after this merges. This directly contradicts the new "SBOM Interoperability" doc section in docs/release-process.md (~line 39-46), which states "this validation does not rewrite or replace any already-published release asset" — true for the asset itself, but false for verify-remote's ability to confirm it. Consider format-versioning the SBOM by release version (or embedding a schema marker) so write_sbom() can reconstruct the historically correct shape for old versions.

2. The new independent SPDX semantic-validation CI job (.github/workflows/tests.yml ~46-62) is gated if: runner.os == 'Linux' only. hash_file_sha1() has two branches (sha1sum on Linux, shasum -a 1 on macOS); only the Linux branch is ever exercised by real spdx-tools semantic validation. A defect confined to the macOS shasum -a 1 branch would ship undetected, since the macOS matrix leg only runs the weaker bats/grep checks below.

3. Minor test-strength gaps. tests/release-artifact.bats:107-108's grep -F '"algorithm": "SHA1"' only asserts the string occurs somewhere in the SBOM, not that every files[] record carries both checksums — a regression that stamps SHA1 onto only the first/last entry would still pass. Separately, tests/validate-spdx.py's --expect-missing-sha1 branch checks only that a SHA1-related message is present among the validator's output (any(...)), not that it's the sole defect — slightly weaker than the PR/docs' "rejected specifically for missing SHA1" framing.

For context: I independently built a real SBOM from this branch and ran it through actual spdx-tools==0.8.5 — the positive case validates clean and the negative fixture is rejected with exactly the expected SHA1 message, so the core mechanism works as intended. These are gaps in the safety net around it, not in the fix itself.

@codeforester

Copy link
Copy Markdown
Collaborator Author

Addressed in commit 36a87ea: v2.1.0 and earlier retain the published SHA256-only SPDX shape, while v2.2.0+ emits SHA1 and SHA256 for every file. The negative validator now requires the sole validation error to be missing SHA1, and independent validation runs on macOS and Linux. The 12-test release-artifact suite and local macOS positive/negative SPDX checks pass.

@codeforester

Copy link
Copy Markdown
Collaborator Author

Confirmed fixed, including the most severe finding. write_sbom() now gates format on version — built and verified a real v2.1.0-style archive and confirmed it stays SHA256-only (matching the real published GA asset) while a v2.2.0 build gets SHA1+SHA256, and verify against the legacy-format archive still passes. The macOS CI gate is lifted (confirmed by actually forcing the shasum -a 1 fallback path on this machine and validating it against real spdx-tools), and the test assertions are now per-record rather than file-wide substring checks. 12/12 tests pass.

@codeforester
codeforester merged commit 06fc090 into main Sep 18, 2026
10 of 11 checks passed
@codeforester
codeforester deleted the bug/456-20260917-bug-emit-standards-valid-spdx-file-identifiers-and-validate branch September 18, 2026 18:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: emit standards-valid SPDX file identifiers and validate SBOM interoperability

1 participant