Skip to content

security: bind release verification to one complete, coherent asset set #348

Description

@codeforester

Related roadmap: #214

Problem

scripts/release-artifact verify does not require every mandatory asset to be covered by SHA256SUMS, and it does not bind the provenance fields back to the archive and embedded release metadata. A provenance file can therefore be omitted from the checksum manifest, altered, and still receive a successful verification result.

This weakens the release trust boundary documented in docs/release-process.md and docs/support-policy.md.

Evidence

Reviewed on main at 63753047312cd5c189600ed71597faceae0f5d8e.

The verifier discovers the first matching archive, SBOM, provenance, and checksum files, verifies only the entries that happen to be present in the checksum file, then checks the provenance and SBOM with single marker greps.

A focused reproduction:

  1. Build a valid 2.0.0 asset set.
  2. Delete the provenance entry from base-bash-libs-v2.0.0.SHA256SUMS.
  3. Replace the provenance sourceCommit with forty zeroes while retaining "reproducible": true.
  4. Run scripts/release-artifact verify <directory>.

Actual result: Canonical release artifact set verified.

Acceptance criteria

  • Require exactly one unambiguous archive, SBOM, provenance statement, and checksum manifest for the same version.
  • Require the checksum manifest to cover every mandatory asset exactly once with strict SHA-256 and safe-basename validation.
  • Verify that the provenance subject name and digest bind to the selected archive.
  • Verify that version and source-commit identity agree across filenames, provenance, SBOM, and embedded release metadata.
  • Reject missing, duplicate, extra-ambiguous, traversal-bearing, or internally inconsistent asset records.
  • Add adversarial tests for an omitted checksum entry, altered provenance commit, mismatched version, and ambiguous duplicate asset.
  • Keep verification offline and Bash 4.2 compatible.

Metadata

Metadata

Assignees

Labels

securitySecurity hardening or vulnerability work

Type

No type

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions