[DRAFT] Rekor v1 and v2 support via signing-config

[ramonpetgrave64]

Client support for Rekor V2: sigstore-python #289

Summary

Adds Rekor V2 support, while being compatible with Rekor v1, swicthable with the signing-config, when signing and verify an artifact.

Lots of files in this PR:

• New python protos, generated from rekor-tiles, copied into sigstore-python. We may not need all these files. And thy maybe belong in trailofbits/rekor-types, or even sigstore/protobuf-specs.
  • Add client generation for python rekor-tiles#303
    • and pending Use 3.10 style for typing imports rekor-tiles#305
  • related: add codegen for rekorv2 trailofbits/sigstore-rekor-types#168
• trust configs
  • with rekor.sigstage.dev rekor v1: trust_config.json
  • with a local rekorv2: trust_config_v2.json
    • with a new release of rekor-tiles, v2 should be also deployed to rekor.sigstage.dev for testing
• changes from pedning PRs
  • improve KindVersion compatibility #1370
  • Verify artifact signing time against all timestamps #1381
  • Fix instantiation in _to_rekor() for optional inclusion promise #1382

Testing

Unit tests pass locally with python 3.12.9. CI tests fails on python 3.9. And linters are not yet expected to pass.

Signing and verifying both work.

Invoke with

sigstore --trust-config ./trust_config.json sign README.md --overwrite -v

sigstore --trust-config ./trust_config.json verify identity --bundle README.md.sigstore.json --cert-oidc-issuer https://accounts.google.com --cert-identity <your cert identity> README.md --verbose

sigstore --trust-config ./trust_config_v2.json sign README.md --overwrite -v

sigstore --trust-config ./trust_config_v2.json verify identity --bundle README.md.sigstore.json --cert-oidc-issuer https://accounts.google.com --cert-identity <your cert identity> README.md --verbose

TODO

Lots of items, so the last few items regarding testing will probably come in a separate PR.

• make it work in CI on all python versions
  • maybe need to edit the generator in rekor-tiles.
• signing and verifying with dsse
• find a home for the types
• tests for all the branches that switch between v1 and v2
  • example v2: bundles and v2 TLEs and v2 canonicalized bodies
  • client endpoint switching
  • parsing switching
• find a way to programmatically detect the key type, even though we do hardcode a specific type for signing and verifying
• use new changes in rfc3161 client from build(deps): bump rfc3161-client from 1.0.1 to 1.0.2 #1399
• are major versions 1 and 2 the only acceptable versions? Signing: Support multiple rekor logs while signing #1390, Handle public good SigningConfig once it's available #1388
  • refactor the rekor, fulcio, etc, clients to accept a v1.Service in their constructors, which has both url and major_api_version. trust: Provide a better way to select service versions #1396
  • integration tests against v2, at rekor.sigstage.dev, or with the new scaffodling/setup-sigstage-env Action
  • test verifying bundles from other clients, perhaps only v2 bundles, for now
  • Decide if the user may also switch to rekor V2 via another CLI option, other than trust-config.

Release Note

Documentation

[jku]

What do you think about this: RekorClient provides a build_proposed_entry() that takes artifatc_signature, b64_cert and hashed_input (and dsse/hashedrekord selection) as argument -- then this code (and the dsse code) could just call self._signing_context._rekor.build_proposed_entry()

This way we could keep the differences between the two rekor implementations more contained in the RekorClient(s).

[ramonpetgrave64]

That's a good idea, especially since this patch is building the request body.

[ramonpetgrave64]

Changed for just hashedrekord. dsse to come later.

[jku]

I mentioned this elsewhere but for clarity: I would prefer the Rekorv2 changes to not touch the v1 RekorClient code if possible and instead be a separate implementation.

• the rekorclient(s) could also take care of building the correct proposed entry (mentioned this in a code comment)
• currently it looks like the rekor v2 client supports all the methods in RekorClient... but I don't think it does and I don't think it needs to

[ramonpetgrave64]

@jku Yes, like we discussed offline, it perhaps would be nicer if the V2 changes would not edit the current RekorClient class. I'll have to see how viable the auto-generated v2 client RekorBase or RekorStub is.

• https://github.com/sigstore/sigstore-python/pull/1387/files#diff-d7b419ac40c89309564411de463dfcde20b004790450a98f3077da9e1f60c459R267

If not, I also mentioned that subclassing could make more sense. Abstract the common methods of V1 and V2 into another base class. If that, I don't think removing V1 support in the future after the estimated 18 months would be difficult.