GitHub artifact attestations verification fails: TSA timestamp verification failed — no certificate matches issuer and serial number (github:anomalyco/opencode)

[yg-codes]

Summary

Installing github:anomalyco/opencode@1.17.12 fails during the GitHub artifact attestations verification step with a TSA (timestamp authority) certificate resolution error. Checksum verification succeeds; the failure is isolated to the Sigstore TSA timestamp check. The same install succeeds with MISE_GITHUB_ATTESTATIONS=false.

Error

INFO  github:anomalyco/opencode@1.17.12   [2/3] verify GitHub artifact attestations
Error:
   0: Failed to install github:anomalyco/opencode@1.17.12: GitHub artifact attestations verification error for github:anomalyco/opencode@1.17.12: Verification failed: Sigstore error: Verification error: TSA timestamp verification failed: Failed to verify timestamp signature: no certificate matches issuer and serial number

Location:
   src/toolset/toolset_install.rs:244

Environment

• mise: 2026.6.14 linux-x64 (2026-06-25)
• OS: Debian 12 (bookworm) on WSL2, x86_64
• Tool: github:anomalyco/opencode@1.17.12

Reproduce

mise uninstall github:anomalyco/opencode@1.17.12 2>/dev/null
mise install github:anomalyco/opencode@1.17.12
# → fails at [2/3] verify GitHub artifact attestations

What works

MISE_GITHUB_ATTESTATIONS=false mise install github:anomalyco/opencode@1.17.12   # ✓ installs

Note: a per-tool github_attestations = false key in config.toml [tools] is not honored by this version (mise settings ls has no attest entry) — only the env var works. Happy to file that separately if it is intended to be supported.

Analysis

The error string ("no certificate matches issuer and serial number") indicates the TSA (Time-Stamp Authority) certificate referenced by issuer+serial in opencode's Sigstore bundle does not match anything in mise's bundled TUF trust root. This points to a TUF-root coverage gap rather than a malformed attestation:

• The attestation bundle is structurally valid (it carries a TSA timestamp).
• Checksum verification passes.
• In the same mise upgrade run, other provenance-carrying tools verified fine (aqua:aws/aws-cli, github:earendil-works/pi), so the verifier works generally.

A web search for the literal strings "TSA timestamp verification failed" and "no certificate matches issuer and serial number" returns zero hits, suggesting this TUF-root mismatch is not yet tracked.

Questions / possible directions

1. Is mise's bundled Sigstore TUF root expected to cover this TSA cert? If so, this looks like a root-coverage bug.
2. Is there (or could there be) a supported per-tool way to disable attestation verification, so one tool's signing-chain gap does not require a global env var? (The github_attestations key in [tools] did not take effect for me.)
3. Should attestation failure be a hard install error, or a warning? Today one tool's verification gap blocks the whole mise upgrade run.

Happy to provide RUST_BACKTRACE=full output or the raw attestation bundle if useful.

[jdx]

Thanks for the detailed report. I was able to reproduce this and track it down.

This is caused by the GitHub TSA cert rotation not being present in the embedded GitHub trusted root bundled with the sigstore crates used by mise 2026.6.14. The opencode attestation timestamp is signed by GitHub TSA cert serial 1733DBD6E9FE0EFA1FA853F3017881E6C9473352 (valid from 2026-06-12), but the embedded GitHub trusted root in sigstore-trust-root 0.8.0 does not include that cert.

sigstore-verify / sigstore-trust-root 0.10.0 does include the new TSA cert. I tested current main after #10677 with an isolated install of github:anomalyco/opencode@1.17.12, and the attestation step now succeeds:

INFO github:anomalyco/opencode@1.17.12 [2/3] verify GitHub artifact attestations
INFO github:anomalyco/opencode@1.17.12 [2/3] ✓ GitHub artifact attestations verified
INFO github:anomalyco/opencode@1.17.12 ✓ installed

So this should be fixed in the next mise release that includes #10677. Until then, the workaround is to disable GitHub artifact attestations, either globally with MISE_GITHUB_ATTESTATIONS=false or for the GitHub backend with MISE_GITHUB_GITHUB_ATTESTATIONS=false.

Longer term, we may want to load GitHub's trusted root via GitHub TUF rather than only from the embedded snapshot, so future TSA rotations do not require a dependency bump before verification works again.

This comment was generated by an AI coding assistant.

[yg-codes]

Thanks for the fast and thorough diagnosis — and for confirming the root cause with the exact missing cert (1733DBD6E9FE0EFA1FA853F3017881E6C9473352, valid from 2026-06-12). That matches what I was seeing: verifier works for everything else in the same run (aqua:aws/aws-cli, github:earendil-works/pi), only the post-rotation TSA timestamp fails.

Two quick follow-ups, no action expected — just to close the loop:

1. Workaround confirmed on my end. I am scoping MISE_GITHUB_ATTESTATIONS=false to just my upgrade wrapper until the next release lands, so checksum verification stays in force and the global setting does not leak into my normal shell. Will revert once a release includes fix(deps): update sigstore-verify to 0.10.0 #10677.

2. The longer-term TUF-load idea is the right one. Refreshing the embedded snapshot is a band-aid — each TSA rotation will recreate this window until the next dependency bump ships. Pulling GitHub's live TUF root would close that gap permanently and stop the "no certificate matches issuer and serial number" class of failures from recurring on a timer.

Appreciate the tool. Nothing else needed from me here — marking this resolved on my side.