CLI compatibility tracker WRT rekor v2

[jku]

I wanted to track and document the "compatibility" of cosign CLI as rekor v2 and related changes start to happen. The main question being: "will existing workflows that are based on calling cosign CLI break because the CLI changes?"

Current state WRT CLI changes:

• cosign < 3.0:
  • existing workflows are unlikely to break when rekorv2 is enabled in signingconfig (as the client does not work with rekor v2 at all without some specific flags)
  • things will obviously start breaking for old cosign when the rekor v1 instance is made read-only but that's a future problem
• cosign 3.0 - 3.0.4:
  • existing bundle signing flows (at least with public good instance) should keep working when signingconfig contains rekor v2 and a TSA: cosign will start signing with rekor 2 and will use a TSA -- @Hayden-IO was there anything to note here?
  • existing bundle verify flows will break when rekor v2 bundles appear because an additional --use-signed-timestamps is needed (fixed in Automatically require signed timestamp with Rekor v2 entries #4666)

I'm not very familiar with cosign and especially with the non-bundle flows so am not sure how they are affected: would appreciate insights on this.

[Hayden-IO]

Nothing more to note for Rekor v2 + TSA - For the public instance, it should just work for signing without additional flags, but for private deployments. For the verification path, it will start to just work after v3.0.5 is cut.

[jku]

I'm planning a PR to add a Troubleshooting section to README with some failure cases for SEO:

• the main case that needs documentation is failed to verify timestamps: threshold not met for verified log entry integrated timestamps: 0 < 1 -- this is very likely an older client verifying a bundle with a rekor 2 entry.
  • Fix: upgrade to latest release OR
  • Fix: in older releases --use-signed-timestamps may help
• Error: no signatures found happens with cosign verify when cosign version < 3 and the image signature uses rekor v2
  • Fix: upgrade to latest release
• I'd also like it if the supported versions are clearly listed, like maybe "cosign project provides support for the latest release and security fixes for the latest 2.6.x release" -- but maybe a cosign maintainer should do that