Follow-up: make exact-candidate evidence tamper-evident

[the-sarge]

Context

PR #43 added committed transcript artifacts for the Go 1.26.3 refresh, but the review surfaced a broader evidence-process gap: maintainer-machine summaries are still largely self-attested unless future refreshes produce raw, immutable, or signed evidence by default.

This is not a current code vulnerability. It is a release-evidence hardening task for the next exact-candidate refresh.

Desired policy

For future exact-candidate evidence refreshes, prefer one or both of:

• immutable GitHub Actions/manual workflow artifacts tied to the exact commit;
• committed raw transcripts under docs/evidence/<date-or-candidate>/ with SHA-256 digests and, where practical, detached signatures.

At minimum, evidence artifacts should preserve:

• commit SHA and clean/dirty status;
• host, OS, architecture, Go version, and relevant tool versions;
• exact commands;
• start/end timestamps;
• raw command output rather than hand-written summaries;
• checksums for copied logs or transcripts.

Additional cryptographic-review check

Before the next exact-candidate packet, add an explicit vector-stability check when the Go toolchain changes:

• run RFC/draft vector tests under the old and new Go toolchains when both are available;
• record whether outputs are bit-identical;
• if old toolchains are unavailable, state that limitation explicitly rather than implying cross-toolchain bit identity from task check alone.

This is especially relevant because the Go 1.26.3 refresh touched crypto/fips140, and Capslock shows reachable call paths through Go's FIPS enforcement internals.

Acceptance criteria

• Evidence-refresh docs or checklist explain the artifact policy.
• The next exact-candidate evidence packet includes raw artifacts or immutable workflow links.
• Cross-toolchain vector bit-identity is either recorded or explicitly marked unavailable with rationale.

[the-sarge]

Execution plan

This issue should be closed in two steps: first land the reusable evidence-process documentation, then verify that the next exact-candidate evidence packet follows it.

Phase 1: document the policy now

• Add a canonical evidence-bundle policy under docs/evidence/README.md.
• Update docs/release-checklist.md so future release candidates explicitly choose an evidence mode:
  • immutable GitHub Actions/manual workflow artifacts tied to the exact commit;
  • committed raw transcripts under docs/evidence/<candidate-or-date>/ with SHA256SUMS;
  • both, when practical.
• Require evidence bundles to preserve:
  • exact commit SHA and clean/dirty status;
  • host, OS, architecture, Go version, and relevant tool versions;
  • exact commands;
  • start/end UTC timestamps for long-running commands;
  • raw command output, not only handwritten summaries;
  • checksums for copied logs/transcripts;
  • detached signatures where practical for maintainer-machine transcript bundles.
• Make the cross-toolchain vector-stability check a named release-checklist step.

Phase 2: define the vector-stability procedure

When a Go toolchain update triggers an evidence refresh, run a focused draft/RFC vector lane under the old and new Go toolchains when both are available. Suggested command:

go test -run 'Test(StringUtilitiesDraftVectors|EmbeddedDraft.*|RistrettoDraft21Vectors|ScalarMultVFYDraftInvalidVectors)$' -count=1 ./...

Record whether the vector lane is bit-identical across toolchains. If the old toolchain is unavailable, explicitly state that limitation in the evidence bundle and security/spec audit instead of implying cross-toolchain identity from current-toolchain tests alone.

Phase 3: enforce it on the next exact-candidate packet

For the next exact-candidate refresh:

• create docs/evidence/<candidate-or-date>/;
• capture raw logs or immutable workflow artifact links for local validation, dependency review, gosec, long fuzzing, security/spec review inputs, and any toolchain-change vector-stability check;
• generate and verify SHA256SUMS;
• add detached signatures where practical;
• update the evidence summary docs to point at the raw artifacts or immutable workflow runs;
• close this issue only after the next exact-candidate packet includes the hardened artifacts or explicitly records an unavailable check with rationale.

This is process hardening, not a current code vulnerability. The policy/docs PR can land before the next candidate, but the full acceptance criteria are only satisfied by the next exact-candidate packet.

[the-sarge]

Reopening after PR #48 merge. The PR completed the policy/docs phase, but #44 should remain open until the next exact-candidate evidence packet exercises the hardened artifact process and records the vector-stability result or unavailable-toolchain rationale.