Skip to content

Enable sigstore-go and offline Rekor mode by default - #849

Draft
wlynch wants to merge 2 commits into
sigstore:mainfrom
wlynch:claude/sigstore-go-opt-in-0e2fc5
Draft

Enable sigstore-go and offline Rekor mode by default#849
wlynch wants to merge 2 commits into
sigstore:mainfrom
wlynch:claude/sigstore-go-opt-in-0e2fc5

Conversation

@wlynch

@wlynch wlynch commented Jul 29, 2026

Copy link
Copy Markdown
Member

What

Opt all users into the sigstore-go code paths and offline Rekor mode by default.

  • gitsign.enableSigstoreGo now defaults to true (was false).
  • gitsign.rekorMode now defaults to offline (was online), resolving the long-standing TODO.

Both remain overridable via git config / env var (GITSIGN_ENABLE_SIGSTORE_GO, GITSIGN_REKOR_MODE).

Why

The sigstore-go path (via the CMS↔bundle compatibility layer) is ready to be the default. The on-disk CMS signature format is unchanged either way, so this is a behind-the-scenes implementation switch for most users, plus a move to offline-verifiable signatures by default.

Notable details

  • Removed the hard enableSigstoreGo requires rekorMode=offline startup error. With sigstore-go now on by default, that check would have broken any user who explicitly sets rekorMode=online on upgrade. The code already degrades gracefully:
    • Verification uses sigstore-go in all Rekor modes; legacy online signatures with no embedded Rekor entry fall back to the legacy verifier.
    • Signing uses the sigstore-go bundle path only in offline mode (skipped when opts.Rekor == nil); online/legacy signing stays on the existing CMS path.
  • The "sigstore-go signing enabled" notice is now scoped to offline mode, so it isn't printed misleadingly on every online-mode commit.
  • Existing online-mode users are unaffected and can still opt back in with rekorMode=online.

Docs / tests

  • Updated README.md (config + env-var tables, verification-flow section) and docs/bundle-cms.md to describe the new defaults and per-mode behavior.
  • Updated TestGet for the new defaults and replaced TestEnableSigstoreGoRequiresOffline with TestEnableSigstoreGo, which asserts the default-on behavior and that it can be disabled via git config and env var.

🤖 Generated with Claude Code

wlynch and others added 2 commits July 29, 2026 12:12
Flip gitsign.enableSigstoreGo to default true so users get the
sigstore-go code paths (via the CMS<->bundle compat layer) without
opting in.

The previous hard error requiring rekorMode=offline whenever
enableSigstoreGo was set would have broken every default (online-mode)
user, so it's removed. That constraint only ever mattered for the
*signing* path, and the code already degrades gracefully:

- Verification uses sigstore-go in all Rekor modes; legacy online
  signatures with no embedded Rekor entry fall back to the legacy
  verifier.
- Signing uses sigstore-go only in offline mode (the bundle path is
  skipped when opts.Rekor is nil); online/legacy signing stays on the
  existing CMS path.

The on-disk CMS signature format is unchanged either way.

Also scope the "sigstore-go signing enabled" notice to offline mode, so
it isn't printed misleadingly on every online-mode commit, and update
the README and docs/bundle-cms.md to describe the new default and the
per-mode behavior.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Flip the default Rekor storage mode from online to offline (resolving
the long-standing TODO). New signatures now embed the Rekor entry for
offline verification, and combined with sigstore-go defaulting on, the
bundle signing path is exercised by default.

Existing online-mode users are unaffected: verification still handles
legacy online signatures (falling back to the legacy verifier when no
Rekor entry is embedded), and users can still opt back in with
gitsign.rekorMode=online / GITSIGN_REKOR_MODE=online.

Update the README env-var default and verification-flow docs to match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@wlynch
wlynch marked this pull request as draft July 29, 2026 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant