Skip to content

TSA request message digest defaults to sha256 #1372

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

Closed
ramonpetgrave64 opened this issue May 8, 2025 · 1 comment · Fixed by #1373
Closed

TSA request message digest defaults to sha256 #1372

ramonpetgrave64 opened this issue May 8, 2025 · 1 comment · Fixed by #1373
Labels
bug Something isn't working

Comments

@ramonpetgrave64
Copy link
Contributor

ramonpetgrave64 commented May 8, 2025

Client support for Rekor V2: sigstore-python

Description

The request to the Timestamp Authority defaults to sha512,

but then when verifying, assumes sha256.

We should either explicitly request sha256, or implement the example logic to determine the what the correct message digest was. Or, wait for a fix in rfc3163-client's verify() that accepts a message, instead of a digest.

Version

sigstore-python v3.6.2

Using TSA timestamp.sigstage.dev

@ramonpetgrave64 ramonpetgrave64 added the bug Something isn't working label May 8, 2025
@jku
Copy link
Member

jku commented May 9, 2025

Well that seems like an obvious bug -- do we not have a test where we verify a timestamp produced/requested by sigstore-python?

We should either explicitly request sha256, or implement the example logic to determine the what the correct message digest was

I assume sigstore specs specify (or should specify ) what the correct choice is when timestamps are added in a bundle? We want the bundles produced by sigstore-python to be verifiable by other clients (and vice versa): making sigstore-python work with sigstore-python is only a partial win...

In any case

  • We should get rfc3163 sorted: verify must at least try to use the hash that was used when creating the timestamp
  • If you need the quick fix to unblock some other work I suppose we can change the hard coded value now but that seems like it will just break later (when we verify bundles produced by another client)
  • I guess a third alternative is to access timestamp_response.tst_info.message_imprint.hash_algorithm() in our verifier to create the correct hash but this really feels like something rfc3163 should handle

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants