[NEW-SPEC-4] Signed release conformance attestation, bundling the conformance manifest and vector hash #142

Activity

1. SoundMatt

   added

   sev:high

   spec-compliance

   on Jul 30, 2026
2. SoundMatt

   closed this as completedin #183on Aug 21, 2026
3. SoundMatt

   added a commit that references this issue on Aug 21, 2026

   feat: add release conformance attestation format (relay-conform-attes…

   ...

   This issue will close once commit 0fd692a is merged into the 'main' branch.

   0fd692a
4. SoundMatt commented on Aug 21, 2026

   

   SoundMatt

   on Aug 21, 2026

   OwnerAuthor

   More actions

   Implemented and merged in #183 (squash commit 0fd692a), as a spec-only scope of the original proposal — per explicit direction not to stand up real signing/publishing infrastructure this pass.

   Scope decision

   The issue proposed a signed SLSA/in-toto attestation published alongside a release's container image, with its digest surfaced in version --format json and relay probe/relay report treating unverifiable releases as non-conformant. This PR ships spec-only:

   • RELAY's own CI only does docker build as a smoke test — it doesn't push images to any registry. "Published alongside the release's container image" presupposes infrastructure that doesn't exist.
   • Real cryptographic signing needs real key management (e.g. Sigstore/cosign keyless signing). Fabricating an unreal "signature" would be worse than not signing at all.

   predicate.signed MUST be false on an unsigned attestation; §20.6 defines shape only, no signing mechanism or publication channel mandated.

   What was implemented

   • New §20.6 defines the relay-conform-attestation/1 predicate: an in-toto Statement whose subject digest is the SHA-256 of the attested binary file, whose predicate bundles the full §17.2 conformance manifest, the attestation-generating tool's own embedded vectors_version (§15.8 — explicitly not observed from the attested binary, since a black-box invocation cannot introspect it), and an optional implementation-defined safety_evidence_summary.
   • New embedded schema spec/schemas/relay-conform-attestation.json.
   • Reference implementation: relay conform --attestation <binary> in cmd/relay/conform.go.
   • New REQ-RELAY-098.
   • SpecVersion bumped 2.5 → 2.6 (MINOR).

   Real bug found and fixed along the way

   While wiring the attestation's conformance_manifest field, found buildManifest's Requirements slice was missing entry 16 (Vector manifest) — PR #181 added the §17 Requirement 16 spec text and verifier-table row but never added the corresponding code entry. Every relay-conform/1 manifest generated since v2.4 had silently omitted it, despite the spec's own text mandating "exactly one entry per §17 requirement (1–16, ...)". Fixed; the two manifest-shape tests that should have caught this (TestBuildManifestSelf, TestRunConformManifestFlag) were also stale at a hardcoded 15 and corrected alongside it.

   Verification (double-checked, before and after merge)

   • 6 new tests for the attestation feature, including independent cross-checks (subject digest vs. a separately-computed SHA-256, vectors_version vs. the tool's own parsed manifest, schema validation).
   • Real mutation test on the Requirement-16 fix: reverted it, confirmed both affected tests failed, restored, confirmed green.
   • Manually verified — both pre-merge and independently from a fresh post-merge clone of main at 0fd692a — that relay conform --attestation produces a digest matching an independently-computed hashlib.sha256, overall: PASS, signed: false, and all 16 requirement entries present.
   • go build/vet/test, gofmt, golangci-lint run (latest) — all clean, both pre- and post-merge.
   • gofusa check (pinned v0.48.0): 0 errors. gofusa trace -req-coverage 100: 100% (98/98).
   • All 8 CI checks green on PR feat: add release conformance attestation format (relay-conform-attestation/1), spec §20.6 #183, and the main CI run for merge commit 0fd692a independently confirmed success.

   Closing this PR's scope. Signing, publishing, and probe/report enforcement remain open for a future issue if wanted.