test(release): authenticate qualification evidence

[ahrav]

Summary

Installed-release qualification now binds proof bytes, target reports, the checkout commit, workflow run, signer workflow, and the top-level evidence record into one attested chain. Target reports must name the expected target and carry an exact passing schema; injected verification failures remain hermetic and never fall through to ambient GitHub state.

Verification

• bun test scripts/verify-mc-host-release-evidence.test.ts: 23 passed
• bun run typecheck
• bun run lint

Remaining Qualification

The protected qualification workflow and real registry/platform evidence remain external. npm publication is intentionally skipped.

Stack

Layer 6 of 7 above #46. Parent: #62. Next: #65.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review

Reviewed scripts/verify-mc-host-release-evidence.ts and its test file. This is a solid security-hardening change with two real, well-targeted fixes:

1. Attestation fallback bypass (the main bug fix) — previously options.verifyAttestation?.(...) ?? (fallback)() meant an injected verifier that legitimately returns null (a rejection) would fall through to the ambient gh attestation verify call instead of being treated as a rejection, since ?? doesn't distinguish "not provided" from "returned null." resolveAttestationVerification fixes this by keying off whether the injected function itself is undefined, not its return value. The new test (an injected attestation rejection never invokes the ambient fallback) directly pins this behavior. Good catch — this is exactly the kind of bug that could let a compromised/misbehaving verifier silently escalate to a passing ambient check in test/mocked contexts.

2. Target proof content wasn't actually checked (validateTargetTestReport) — previously the target proof's expectedObservations.test_report_path/test_report_sha256 were computed by echoing back whatever the actual observations claimed (once format/hash-consistency checks passed), so the drift check was tautological — it never verified the referenced report actually asserted passed: true for the right target/schema. validateTargetTestReport now parses the report and enforces schema, target, and passed === true explicitly. The new parametrized test (failed / wrong-schema / wrong-target) exercises exactly the gap this closes. This looks like the more important of the two fixes from a security-gating standpoint — without it, GA qualification could previously be gated on a test report that never actually passed, as long as the hash chain was internally consistent.

Both fixes are well covered by tests, and I traced the existing test fixtures (installProofArtifacts) to confirm they already produce schema-conformant, passed: true reports, so no other tests are silently broken by the stricter check.

Minor observations (non-blocking)

• The options.verifyAttestation === undefined ? undefined : () => options.verifyAttestation?.(...) pattern is repeated twice with an arguably-redundant ?. inside the closure (once the outer ternary already established the property is defined). This is likely there because TS narrowing of options.<prop> doesn't reliably persist across the closure boundary — worth a one-line comment if the redundancy is intentional, otherwise harmless.
• verifyAttestationWithGitHub nicely deduplicates what were two near-identical inline spawnSync IIFEs — good simplification alongside the behavioral fix.

No security or correctness issues found beyond what's already fixed by this PR; no additional bugs identified.