Skip to content

Add Rekor v2 client #1422

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 35 commits into
base: main
Choose a base branch
from
Open

Add Rekor v2 client #1422

wants to merge 35 commits into from

Conversation

jku
Copy link
Member

@jku jku commented Jun 4, 2025

This is a continuation of Ramons #1400 , I'm moving it here in hopes of getting staging tests running.

The PR adds a new RekorV2Client for adding entries to a rekor-tiles log.

  • The plan is that a followup PR starts using this client in the CLI when signingconfig contains a rekor v2 instance
  • The existing RekorClient is slightly modified so that there is a common abstraction that the signing code can use
    • the abstraction contains create_entry() and methods for constructing the requests for dsse/hashedrekord
    • name of the ABC is currently RekorLogSubmitter -- we could name it RekorClient but obviously would then need to rename the original V1 client...
  • Note that the client does not include functionality to lookup entries from the log (since a sigstore client does not strictly speaking need to do that). The feature could still be added
  • testing is very light but it does show that the client can add entries to a rekor-tiles log (the staging instance)

TODO:

  • Sort out the protobuf situation: currently the PR uses protobuf-specs from git

ramonpetgrave64 and others added 23 commits May 20, 2025 16:18
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
Signed-off-by: Ramon Petgrave <[email protected]>
* Make sure the exposed signatures actually are abstract:
  the request payload can be just a dict so both clients actually
  implement the same API
* There is still a "EntryRequest" NewType being used instead of dict
  just to make the intent clear

Signed-off-by: Jussi Kukkonen <[email protected]>
* Don't pretend these are unit tests: just have something simple
  that proves the client roughly does what it should
* We should have real unit tests (that don't require the whole
  staging infra as current tests do) and integration tests but this
  is what I have now

Signed-off-by: Jussi Kukkonen <[email protected]>
@jku jku mentioned this pull request Jun 4, 2025
6 tasks
jku added 3 commits June 4, 2025 16:48
* The timeout was a little misleading (since requests timeout is not the
  total maximum time of the request) and we don't have specific timeouts
  elsewhere either.
* Also remove some unused variables

Signed-off-by: Jussi Kukkonen <[email protected]>
As of right now this is not in a released protobuf-specs: just preparing
for when it is

Signed-off-by: Jussi Kukkonen <[email protected]>
@jku
Copy link
Member Author

jku commented Jun 6, 2025

Sort out the protobuf situation

I've been testing with sigstore/protobuf-specs#661 -- looks fine so far

This was dropped from generated protobuf code

Signed-off-by: Jussi Kukkonen <[email protected]>
jku added 3 commits June 6, 2025 14:29
We only generate secp256r1 so can skip checking all of the other types
for now.

Signed-off-by: Jussi Kukkonen <[email protected]>
Signed-off-by: Jussi Kukkonen <[email protected]>
@jku
Copy link
Member Author

jku commented Jun 6, 2025

I'm marking this ready for review: it depends on a protobuf-specs PR so is not ready to merge but should be otherwise reasonable

@jku jku marked this pull request as ready for review June 6, 2025 12:05
@jku jku force-pushed the rekov2-client branch from 8de5278 to 393275b Compare June 7, 2025 09:09
jku added 3 commits June 7, 2025 12:12
This reverts commit 3d9a1b8.

protobuf-specs now contains CreateEntryRequest: no need to workaround

Signed-off-by: Jussi Kukkonen <[email protected]>
Signed-off-by: Jussi Kukkonen <[email protected]>
@jku jku force-pushed the rekov2-client branch from 393275b to b6b2ad5 Compare June 7, 2025 09:12
jku added 2 commits June 7, 2025 12:21
This is a backwards compatible change (RekorClient is a
RekorLogSumbitter), but also allows using a RekorV2Client.

Signed-off-by: Jussi Kukkonen <[email protected]>
Comment on lines +23 to +24
* Added a `RekorV2Client` for posting new entries to a Rekor V2 instance.
[#1400](https://github.com/sigstore/sigstore-python/pull/1400)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW we technically don't need an entry here, since the Rekor client APIs are private. But we could also save the CL cleanup until release time 🙂

@@ -38,7 +38,7 @@ dependencies = [
"rfc8785 ~= 0.1.2",
"rfc3161-client >= 1.0.2,< 1.1.0",
# NOTE(ww): Both under active development, so strictly pinned.
"sigstore-protobuf-specs == 0.4.2",
"sigstore-protobuf-specs @ git+https://github.com/sigstore/protobuf-specs.git@main#subdirectory=gen/pb-python",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we switch back to a release here? PyPI won't let us publish with a git dependency, so we'll need to at some point anyways.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, absolutely -- this is the caveat I had for this PR: has to wait for protobuf-specs to release

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh whoops, missed that in the PR desc. Sorry 🤦

Comment on lines +93 to +95
"""Determine PublicKeyDetails from a certificate

We know that sign.Signer only uses secp256r1 so do not support anything else"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency with the other docstrings:

Suggested change
"""Determine PublicKeyDetails from a certificate
We know that sign.Signer only uses secp256r1 so do not support anything else"""
"""
Determine PublicKeyDetails from a certificate
We know that sign.Signer only uses secp256r1 so do not support anything else
"""

Comment on lines +216 to +217
proposed_entry = self._signing_ctx._rekor._build_dsse_request(
envelope=content, certificate=cert
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot cleaner, thanks!


__all__ = [
"_hashedrekord_from_parts",
]

EntryRequest = NewType("EntryRequest", dict[str, Any])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
EntryRequest = NewType("EntryRequest", dict[str, Any])
EntryRequestBody = NewType("EntryRequestBody", dict[str, Any])

).build()

with sign_ctx.signer(identity) as signer:
bundle = signer.sign_dsse(stmt)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I wanted to ensure that the certificate, not only the public key, was used in the request. It's no problem to not include that here, though.

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.

3 participants