Attestation verify uses token-gated GitHub API (--repo); fall back to OCI bundle to avoid source builds in CI

[kelp]

Summary

gale's dependency attestation check shells out to gh attestation verify <archive> --repo <repo> (internal/attestation/attestation.go:154).
The --repo flag makes gh fetch the attestation bundle from the
GitHub API, which requires authentication (GH_TOKEN) even for
public repos. When no token is present, the verify fails and gale
falls back to building the dependency from source.

In CI this is expensive and fragile: a Rust dependency (rust) falls
back to a full rustc source build, whose vendored tree fills the
runner disk and the job dies with no space left on device.

Observed in gale-recipes CI

Build of difftastic (a Rust recipe), build-chunk.yml:

warning: binary install for rust@1.96.0 failed: attestation:
  attestation verification failed: gh: To use GitHub CLI in a GitHub
  Actions workflow, set the GH_TOKEN environment variable.
Error: installing build deps: install dep "rust": build from source:
  ... extract rustc-1.96.0-src/.../bad-2-index-4.xz:
  no space left on device

Same signature has hit btop, difftastic, hyperfine, just across
the republish batches — every time a Rust dep cache-misses and the
attestation can't be verified.

Root cause

The token is needed only to fetch the attestation from the GitHub
API, not for the Sigstore cryptographic verification itself (that is
offline-capable). This is a recognized gh CLI limitation:

• gh attestation verify should be able to work without token / authentication cli/cli#11803 — gh attestation verify should work without token / auth
• Feature Request: gh attestation download: Remove authentication requirement to increase adoption cli/cli#12030 — remove auth requirement from gh attestation download

Proposed fix

gale already pushes each artifact's attestation to GHCR as an OCI
referrer, and gh attestation verify can read it from the registry
instead of the API — anonymously for public packages, no token:

• --bundle-from-oci — "When verifying an OCI image, fetch the
  attestation bundle from the OCI registry instead of from GitHub."
• --bundle <path> — verify against a bundle on disk.

Switch the dep-attestation call from the --repo (GitHub-API) path to
the OCI/bundle path. gale already has a VerifyOCI alongside the
VerifyFile/--repo path it currently uses for deps.

Payoff:

• No token required anywhere. Fixes both the privileged build-chunk.yml
  and the deliberately contents: read-only verify.yml (which must
  not be granted packages:).
• Preserves the full supply-chain guarantee — still verifies the
  Sigstore attestation, just fetches it from GHCR rather than the API.
• Eliminates the source-build fallback, so the disk never fills.

Implementation note

--bundle-from-oci is documented against an OCI image subject
(oci://…), whereas the current code verifies the extracted local
archive via VerifyFile. So the fix is either: verify the GHCR ref
directly (existing VerifyOCI), or fetch the bundle from GHCR and pass
--bundle for the local file. That choice decides which flag applies.

References

• gh attestation verify manual: https://cli.github.com/manual/gh_attestation_verify
• Verifying attestations offline: https://docs.github.com/actions/security-for-github-actions/using-artifact-attestations/verifying-attestations-offline
• gh attestation verify should be able to work without token / authentication cli/cli#11803, Feature Request: gh attestation download: Remove authentication requirement to increase adoption cli/cli#12030
• gale-recipes context: the republish batches (switch/install: explicit revision pins never activate (bare version written, resolves to highest on-disk rev) #65) repeatedly hit this on Rust recipes.

Related

• Make Sigstore attestation verification fail-closed for trust = "sigstore" #129 (fail-closed attestation) — adjacent attestation behavior, distinct issue.