Issues w/ Sigstore signing

[di]

Hey @pablogsal, sorry for the troubles. Just want to make sure I understand all the issues you hit. To summarize python/pythondotorg#2113 and #19, what we'll need is:

• file permissions are wrong, this needs updated in add_to_python_dot_org.py to do it directly on the host.
• Automation is broken because interactive signing happens in add-to-pydotorg.py, but this is run non-interactively
• NameError (resolved already by Fix name error in has_sigstore_signature #19)
• revert Comment the sigstore process until is ready #20

Is that right?

Regarding the blocking for signing, this is expected, but should happen in an interactive environment, so looks like add_to_python_dot_org.py is the wrong place for this. Is there any point in the release process where the files are available in an interactive environment?

[pablogsal]

Hi @di. Thanks for helping with this!

file permissions are wrong, this needs updated in run_release.py to update permissions of signing material after signing, or on add_to_python_dot_org.py to do it directly on the host.

The permissions are only needed on the download server so the perms in run_release.py are not relevant. In any case I think we can leave only the add_to_python_dot_org.py as this generates certs files for everything so technically is not needed in run_release.py.

For context: add_to_python_dot_org.py is executed on the download server directly so it has access to the files that will be served. These files are the ones that need permissions that allow them to be downloaded.

Automation is broken because interactive signing happens in add-to-pydotorg.py, but this is run non-interactively

This needs changes so the output of the command is shown to stdout so the operator can copy the URL and paste it in the browser and then it needs to take the code from stdin and move it to the stdin of the ssh command so is pasted in the process running remotely.

revert #20

👍

One note, I ran manually the current (fixed version for the NameError) script in add_to_python_dot_org.py and apart for the perms it works quite nicely.

[pablogsal]

Regarding the blocking for signing, this is expected, but should happen in an interactive environment, so looks like add_to_python_dot_org.py is the wrong place for this. Is there any point in the release process where the files are available in an interactive environment?

The automation script is running interactively (it needs input from other commands). What is missing here is that it displays the output and allows the operator to paste the code so the ssh command gets it remotely. Currently, the command is just executed and the output is checked under the assumption that there is no input needed.

[di]

@pablogsal I'm happy to make the changes here, but is there any way for us to test this before the 3.11.0 final release in October? I really don't want to hold up that release as well.

[pablogsal]

I can do some manual test of the end-to-end before the final release. Unfortunately this repo never developed automatic testing so there isn't any better way than that that I can think off :(

[pablogsal]

Thanks a lot for the help, btw

[pablogsal]

@di Another thing I realized while signing the 3.11.0rc2 release. The URLs for pre-releases are wrongly calculated. The current script generates the following for the rc2 release:

https://www.python.org/ftp/python/3.11.0rc2/Python-3.11.0rc2.tgz.sig

but it should be

https://www.python.org/ftp/python/3.11.0/Python-3.11.0rc2.tgz.sig

I fixed these manually this time.

[di]

Another thing we need to do here is upgrade the version of Python on the release server to be a version supported by the most modern cryptography releases (currently it seems to be 3.6, we need at least 3.7), so we don't need to build cryptography from source.