-
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
Incorrect information in https://www.python.org/download/sigstore/
#600
Comments
Thanks @ned-deily! I think this falls under the discussion in #567 -- it's currently pretty easy for signers to sign with the "wrong" identity/issuer combination from a policy perspective, since Apart from fixing the documentation on https://python.org, we probably need a way for the |
https://www.python.org/download/sigstore/
Thanks @ned-deily. We have a few options short term to get the docs up to date:
I think I would prefer the first option because it would make the verification steps simpler for consumers, but this would be at the cost of some one-time work for the release managers. Curious for your thoughts! |
Looping in @sethmlarson here, as he should probably be the primary owner of this page going forward. (Also, sigstore/sig-clients#7 is likely relevant here as well.) |
I went through all the Python releases and attempted Sigstore verification as is documented on the release page like so:
or
Here are the results:
Looking at the results I see a few things:
My questions for next steps are:
|
The other release managers (Thomas, Pablo, and Łukasz) should be part of this discussion since we have had some discussions about this at PyCon and on email. But I don't seem to be able to add them here. |
FWIW, I wasn't keen on adding yet another identity (the google.com one) to the release process since I was already using the GitHub identity elsewhere. And the 3.7.14 signing by Pablo was a one-time expediting action; the artifacts could be re-signed. |
Since Python 3.7 is EOL at this point too, there's an additional decision about whether we want to touch those releases at all anymore? If we decided to only rollout fixes for 3.8 and beyond the concrete steps per person would look like this (assuming we do want to use
Then I would take it as an action to add a verification step to While this is happening I can prepare the communications announcing this fix to release signatures. |
Note that now that #567 is resolved, we can enforce the IdP at signing time, but sounds like exclusively using the Google IdP is a non-starter for @ned-deily IIUC. Until sigstore/sig-clients#7 is resolved, and there is a way for clients to define a policy for what One alternative that was discussed was creating a new, shared identity between all the release managers (this could be on any of the identity providers) so verification is simplified, and this doesn't require individual release managers to sign. |
Happy to go this route too, for this case we'd have 3.7.14 resigned by @ned-deily and (3.10.0, 3.10.2-3.10.6, and 3.11.4) signed by @pablogsal with Google IdP (assuming you want to use Google going forward Pablo). Can capture these in the release-tool just as well. |
Yup. This is the one I have always used. I am a bit surprised there are mismatches here because I have always used the google one with [email protected] |
I've regenerated the sigstore files for 3.7.14 to use [email protected] and GitHub like subsequent 3.7.x releases and added a note to the 3.7.14 release page that the sigstore files were updated today while the release tarballs were unchanged. |
Thanks @ned-deily! @pablogsal if you can resign the releases I noted with the Google IdP I can update the table for the sigstore page with identity providers for each RM. |
I have re-signed Python 3.11.4 as requested. Can you check that everything looks good? |
@pablogsal I'm not seeing the updated |
I think we need to purge the CDN cache |
I think I successfully purged the cache, can you take another look? I am basically running:
|
Also noting here that I noticed that the 3.8.14 and 3.9.14 signature and certificate files weren't available for download due to permission errors, @ambv has fixed this issue and I've verified that those files are now available. @ned-deily I'm seeing a signature verification error for @pablogsal I'm seeing updated files for the Old:
New:
|
Hummmm, I think I have done it correctly now:
|
@sethmlarson, I believe that was due to a CDN caching issue: the old files weren't purged during the update and I didn't bother testing the old-style .crt and .sig files, just the newer .sigstore bundle. If you try again, it should be OK now. Sorry about that! |
@ned-deily That makes total sense, I've redownloaded the files again and indeed they're working now :) Thank you much! |
Okay, I've verified both @ned-deily and @pablogsal's signatures and they are all in order. I've published all the data to this GitHub repository and you can see the delta I observed for today at this commit. The last outstanding item is that @ambv's certificates are using the identity |
There is no such option and this is the major downside of using GitHub as the IdP. |
I've created a PR for
That's unfortunate, @ambv we can discuss options once you've returned from EuroPython. |
Yep -- ideally GitHub would use a "username" identity type here rather than returning the primary email associated with the account, but I suspect that they can't do that with their primary IdP without breaking a whole bunch of stuff... |
Glad to hear it! Closing. |
As requested on the web page, I am reporting issues with the page here, although long-term I think this page should be maintained by the Python release management team. One problem is that not all release managers use accounts.google.com as the cert-oidc-issuer so the directions given fail for 3.9, 3.8, and 3.7 releases at least. Also, the information about 3.7 releases is incorrect. Only the first sigstore signed 3.7 release was signed by [email protected]; all subsequent and future 3.7 release have been / will be signed by the 3.7 RM [email protected].
The text was updated successfully, but these errors were encountered: