⚠️ Definition of Done: this issue must be completed in full, in a single PR.
Problem
DEFAULT_REKOR_SHARD_BASE_URL in src/review/ledger-anchor-rekor.ts is
https://log2026-1.rekor.sigstore.dev. That host does not exist. Verified from a live self-host
deployment:
log2026-1.rekor.sigstore.dev -> DNS: NXDOMAIN
log2025-1.rekor.sigstore.dev -> DNS: 34.160.235.130 POST /api/v2/log/entries: 400 (endpoint live)
Sigstore shards Rekor v2 annually as log<year>-<rev>.rekor.sigstore.dev, and the 2026 shard has not been
deployed — 2025-1 is still the live one. The constant's own comment says it is "the current shard as of when
this was written", but it was written ahead of a shard that never shipped.
So every operator who enables anchoring without overriding the env var gets a failed anchor, forever,
with no successful anchor ever published.
Second, compounding problem
The recorded failure is unhelpful. This was a real, published anchor row from that deployment:
{"seq":1626,"keyId":"6b6490126ad44b51","backend":"rekor","status":"failed","error":"fetch failed"}
"fetch failed" is Node's generic message. It does not name the URL, so an operator cannot distinguish
"the shard hostname does not resolve" from "my egress is blocked" from "the shard is down" — the three have
completely different fixes. Diagnosing it required probing DNS from inside the container by hand.
That matters more here than in an ordinary code path: #9271 made anchoring failures publicly visible
precisely so "anchoring has been failing for a week" is checkable by anyone. A published failure that does
not say what failed only half-delivers that.
Requirements
- Default to the shard that is actually live, with a comment recording that the year-shard pattern means this
WILL need updating and that the env var is the intended override.
- The recorded
error must name the shard URL that was attempted, for the thrown-error path (the !response.ok
path already includes the status and body, so it is already actionable).
- Do not change the request shape, the timeout, or the
recordLedgerAnchorAttempt contract — the raw caught
value is deliberately passed through so the persistence layer stays the single place that normalizes an
unknown error (see the existing comment).
Deliverables
Test Coverage Requirements
99%+ Codecov patch coverage, branch-counted. Both arms of every changed conditional.
Expected Outcome
A deployment that enables anchoring without setting LOOPOVER_LEDGER_ANCHOR_REKOR_SHARD_URL reaches a real
log, and any future shard rotation produces a published failure that names the endpoint it could not reach.
Links & Resources
src/review/ledger-anchor-rekor.ts. Rekor v2 shard naming: https://blog.sigstore.dev/rekor-v2-ga/
Problem
DEFAULT_REKOR_SHARD_BASE_URLinsrc/review/ledger-anchor-rekor.tsishttps://log2026-1.rekor.sigstore.dev. That host does not exist. Verified from a live self-hostdeployment:
Sigstore shards Rekor v2 annually as
log<year>-<rev>.rekor.sigstore.dev, and the 2026 shard has not beendeployed — 2025-1 is still the live one. The constant's own comment says it is "the current shard as of when
this was written", but it was written ahead of a shard that never shipped.
So every operator who enables anchoring without overriding the env var gets a failed anchor, forever,
with no successful anchor ever published.
Second, compounding problem
The recorded failure is unhelpful. This was a real, published anchor row from that deployment:
{"seq":1626,"keyId":"6b6490126ad44b51","backend":"rekor","status":"failed","error":"fetch failed"}"fetch failed"is Node's generic message. It does not name the URL, so an operator cannot distinguish"the shard hostname does not resolve" from "my egress is blocked" from "the shard is down" — the three have
completely different fixes. Diagnosing it required probing DNS from inside the container by hand.
That matters more here than in an ordinary code path: #9271 made anchoring failures publicly visible
precisely so "anchoring has been failing for a week" is checkable by anyone. A published failure that does
not say what failed only half-delivers that.
Requirements
WILL need updating and that the env var is the intended override.
errormust name the shard URL that was attempted, for the thrown-error path (the!response.okpath already includes the status and body, so it is already actionable).
recordLedgerAnchorAttemptcontract — the raw caughtvalue is deliberately passed through so the persistence layer stays the single place that normalizes an
unknown error (see the existing comment).
Deliverables
DEFAULT_REKOR_SHARD_BASE_URLpoints at the live shard.!response.okand bad-shape paths are unchanged.Test Coverage Requirements
99%+ Codecov patch coverage, branch-counted. Both arms of every changed conditional.
Expected Outcome
A deployment that enables anchoring without setting
LOOPOVER_LEDGER_ANCHOR_REKOR_SHARD_URLreaches a reallog, and any future shard rotation produces a published failure that names the endpoint it could not reach.
Links & Resources
src/review/ledger-anchor-rekor.ts. Rekor v2 shard naming: https://blog.sigstore.dev/rekor-v2-ga/