-
Notifications
You must be signed in to change notification settings - Fork 49
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
Client libraries should verify after signing #761
Comments
I don't believe we currently do either of these 🙂. I'm open to changing my mind here, but I'm currently a little bit murky on the value of mandatory verification after signing. The main things I'm skeptical about: 1: Asking users to pass verification state in during signingUnder recommendation (2), clients like
2: Checking error states rather than preventing themRelated to the above: I think the underlying problem here (users signing with the wrong or "unexpected" identity) is a very serious one, and needs to be addressed. At the same time: I think mandating verification (particularly of claim states) after signature generation results in a situation where Sigstore clients are performing "guess and check" error handling rather than eliminating these kinds of user-initiated error states from the very beginning. They're arguably harder to do, but I think three workable "eliminate the error state" solutions are:
3: Mandating a less secure verification modeThis is a more abstract concern: if my interpretation is correct, a client following these recommendations is effectively required to implement a "no-op" verification mode, one where a signature is said to be valid without cross-checking any of its embedded claims. This is not risky in the context of a signing flow, but I think it's worth highlighting that this effectively requires clients to implement a codepath where users may think that they're doing something resembling a normal Sigstore verification flow but are really just checking that any signature is valid for some input. I think this is especially concerning in the context of clients that provide an API; it's hard to provide a misuse-resistant version of an API that explicitly allows all relevant pieces of verifiable claim state to be omitted! If I had to rank these concerns, I'd say that (2) is the most important, followed by (1) and then (3). |
In the Sigstore clients special interest group meeting today, we discussed an issue with the release signatures on CPython.
We have two recommendations for client libraries:
I'm going to be a bit lazy (sorry) and rather than inspecting every client library by hand, just ask whether you're doing the these and, if not, whether you all agree with these recommendations.
The text was updated successfully, but these errors were encountered: