Release 4.0 with rekorv2 changes

[jku]

Opening a tracking issue for things may still want to do before a release:

• rekorv2: parallelize entry requests #1446 -- currently the rekorv2 experience is not great if signing multiple artifacts at once
• refactor: begin to remove sigstore_protobuf_specs #1470
• conformance test disagrees with our timestamp counting #1442
• accidentally verifying with wrong sigstore instance looks confusing #1487
• decide if a CLI flag is needed to control the choice between rekor v1 and v2 if both are available -- cli: Add --rekor-version to sign arguments #1471
• feat: expose ClientTrustConfig as a public class #1496
• rekor: Fix checkpoint signature lookup #1514
• Update embedded TUF root #1515 (not required but useful)

issues that were considered but that I don't think should block release:

• Support more signing cert signing algorithms in verification #1439

[jku]

decide if a CLI flag is needed to control the choice between rekor v1 and v2 if both are available

Some notes on this:

• public good instance (prod and staging) provide a signingconfig via TUF that gives clients advice on which rekor instance to use: currently it includes only the v1 instance
• at some point in near future, signingconfig will include both v1 and v2 instances: clients should choose the highest version they have support for...
• However, sigstore-python could decide to not default to signing with rekor v2 even if it supports doing so. Reasons for doing so
  • cross-client verification support is considered important, and many clients may not support verifiying bundles with v2 entries at launch
  • older sigstore-python versions will not be able to verify bundles with v2 entries -- maybe we want to ensure that a version capable of verifying bundles with v2 entries has been out there for a little longer before we default to signing with v2
• The severity of those reasons depends largely on when the signingconfig change happens (in relation to client verification support being released)

So options for sigstore-python include at least

• Just follow the advice from SigningConfig (start signing with rekor v2 as soon as it's available). This is what the code currently does
• Default to signing with v1 for now, and in a later release (after ecosystem has sufficient v2 verification capability) switch to signing with v2 by default. Provide some way for users to use v2 during this period (like --experimental)

[woodruffw]

• Just follow the advice from SigningConfig (start signing with rekor v2 as soon as it's available). This is what the code currently does

I think I'm in favor of this -- I'd expect the SigningConfig switchover to only happen after a few clients pick up Rekor v2 support, so we should synchronize on that as the signal versus trying to set a custom timeline just for Python 🙂

[jku]

• maybe Support more signing cert signing algorithms in verification #1439

I had a look at this and it is a little more work than I thought: IMO this is not a blocker

[di]

Provide some way for users to use v2 during this period (like --experimental)

I think we should also provide the users with an escape hatch to revert back to V1 once the default changes (and the default should only change with a major version bump, IMO).

[jku]

• maybe resolve conformance test disagrees with our timestamp counting #1442

I believe this is just an issue in rfc3161-client -- fixing should not change API so sigstore-python needs no changes

[jku]

I think we should also provide the users with an escape hatch to revert back to V1 once the default changes (and the default should only change with a major version bump, IMO).

I think I agree, just two additional points:

• "default" is based on the signingconfig (but obviously client cannot use rekor v2 before it has support for it... and that should happen in a major version). So even after we release sigstore-python 4.0, the default remains whatever signingconfig suggests -- and currently that is a rekor v1 instance
• I think this configuration option should be short lived (I don't think it will be useful two years from now)

I will have a look at how to handle this