rekor v2 considerations

[jku]

• sigstore public good instance already runs a rekor v2 service
• in the near future this will be recommended to be used when signing
• at some significantly later point the rekor v1 instance will become read-only

rekorv2 entries cannot be verified by clients that are not yet rekorv2 compatible. As gitsign seems to use an old cosign version, this does not really affect gitsign right now, but once the upgrade is made (see #537) you may want to force rekor v1 for a while (to give users time to upgrade their verifier clients before rekor v2 entries start appearing)

[xingao267]

Does gitsign support Rekor v2 now? @jku @wlynch

cc @Hayden-IO

[JeromeJu]

Based on a recent investigation, there are currently two structural implementation blockers keeping gitsign from fully supporting Rekor v2:

• Hardcoded Entry Extraction: pkg/rekor/rekor.go:L205-L257 exclusively switch-cases and handles v0.0.1 Rekor schemas.
• Hardcoded OID Extension Reconstruction: In internal/rekor/oid/oid.go, functions like ToLogEntry hardcode the local reconstruction and API version to v0.0.1, causing offline Signed Entry Timestamp (SET) verification to fail when encountering a v0.0.2 entry.

I am curious about the team's thoughts on addressing this:

• Workload & Effort: What does the immediate scope of work look like to safely decouple these and support hashedrekord v0.0.2? Are there edge cases or backward-compatibility considerations we need to watch out for?
• Roadmap & Priority: Is updating these internal parsers a priority on the current roadmap, or is this effort being deferred in favor of a larger structural change—such as the long-term migration to sigstore-go (Using sigstore-go's API instead of Cosign #537)?

cc @jku @wlynch 🙏