feat(evidence)!: retain acceptance evidence in signed git, not S3 Object Lock

[abrichr]

Replaces S3 Object Lock with a signed git commit as the retained-evidence store. Decided before the first write, which was the last moment it was free: a COMPLIANCE lock cannot be shortened by anyone, including the account root, so the first retained object would have committed storage for its full term.

Why S3 was weaker than it looked

I argued for Object Lock earlier in this thread and was wrong. Naming the attack rather than the feature list gives a different answer:

Attack	What actually stops it
Run acceptance, it fails, never mention it	Nothing in S3. The certificate sits unread in a private bucket. Publishing the digest at creation time is what helps, and Rekor already does that
Alter a published result	The signature and the Rekor entry. Object Lock adds nothing
Destroy the payload after publishing	Object Lock keeps bytes in your bucket, which only helps a third party who has access

The confidentiality argument also fails on inspection. encryptPrivateEnvelope in the Cloud writer already encrypts with an AES-256-GCM data key wrapped by KMS, so the store holds ciphertext. GitHub cannot read it. Confidentiality never depended on the medium.

And git is content-addressed: a commit hash covers the whole tree, so it binds the relationships between certificate, admission and campaign. A per-object lock binds each blob alone.

What Object Lock genuinely bought, and why we are giving it up

If a third party is granted direct read access to the store, they can trust nothing was pruned before they looked. That is real. No buyer has asked for it. The document records the trade so the next reader does not reconstruct it, and says to revisit before the next write if a buyer ever does.

The schema change

Removed	Added
retention_mode	retention_commit (exact 40-hex)
retention_until	transparency_log_entry_sha256
object_version_sha256	push_verified
object_lock_verified	commit_verified
upload_verified, head_verified	transparency_logged

The contract destination becomes repository, ref, path_prefix, keeping account_id, region and kms_key_arn because the data key is still KMS-wrapped. storage_identity_sha256 now digests the repository instead of the bucket.

One thing deliberately not enforced

retention_commitment_days is recorded and not policed. A git commit has no expiry. Enforcing a number nothing can hold would be theatre, so verify_retention_against_contract does not check it and both the code comment and the document say so outright.

Verification

• 359 tests pass.
• New tests cover the exact commit format, retention dated before acceptance, retention dated in the future, and the three new verification booleans.
• The template still refuses unfilled.
• ruff check . passes.
• The hashed policy digest moves with the medium: bc013d65… → 77130f49…, updated deliberately in the pinned assertion.

This does not ship alone

The Cloud writer still writes to S3. Neither side can run until both agree, and the Cloud repository is a different lane with its own frozen gate. This PR changes the verifier only; the gate is still closed, so nothing live depends on it. The Cloud change needs its owner's review before either merges in anger.

🤖 Generated with Claude Code

[abrichr]

Closing this at 70ace5a because it removes the COMPLIANCE storage required by the qualification contract and replaces it with a mutable private Git ref. The importer accepts a commit SHA and self-asserted booleans, but it does not fetch and verify the commit, signature, ref ancestry, Rekor entry, or readback. It derives destination_approval_sha256 without enforcing the approved ref or path. This also overlaps #303 and conflicts with the signed source-manifest and storage-seal work now in progress.

The branch remains preserved. Keep the legacy importer until the replacement has enforceable retention, exact destination approval, verified commit and transparency identities, and terminal readback proof.