CI: Use a discrete deployment environment for releases

[woodruffw]

~~We should do the same thing pip-audit does. We might want to hold off on it until the repository is migrated, however.~~

Now that we have an automated release workflow, we should constraint it to a custom environment to take advantage of more robust secret management.

[woodruffw]

Blocked on #32.

[di]

And signing! Ideally this would sign itself during the release process.

[jku]

FYI: we've just added this to python-tuf as well and used Github deploy environment for a bit of extra safety: this way the PyPI secret is not available in the normal secrets storage that often has to be exposed to non-deploy workflows, it's only exposed when the deploy is actually approved (this is a manual approval only specific accounts can do). We're just about to test it in real life for the first time so I wouldn't copy it just yet :joy: but wanted to leave note.

https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/cd.yml

Signing is something we didn't include yet: we're waiting for better tools to arrive :wink:

[di]

Unblocked! I've invited @woodruffw as co-owner of https://pypi.org/project/sigstore/ (@tetsuo-cpp, I don't know your PyPI username but can add you as well)

(Ideally we'd be releasing this via the new OIDC publishing feature, but I don't think that's going to be ready in time.)

[jku]

https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/cd.yml

We have now tested that once and I can whole heartedly recommend this setup:

• the core idea of using a GitHub deploy environment for the PyPI token is something that should be standard in my opinion: Ordinary Github secrets are way too easy to leak to safely contain something as critical as a long lived PyPI token. Even if the actual secret is a short lived OIDC token, using a deploy environment would be smart as it allows defining "accounts allowed to upload to PYPI" separately from "accounts allowed to push to github"
• our implementation has additional complexity that might not be for everyone: we build the release first to allow maintainer to reproduce the build result locally (using verify_release script in our sources), before accepting the deploy to PyPI.

[woodruffw]

Yeah, the point about deploy environments is an excellent one. I forgot to close this issue when we added our initial release workflow (https://github.com/sigstore/sigstore-python/blob/main/.github/workflows/release.yml), but I'll leave it open so that we can tweak it to use a separate environment instead.

[woodruffw]

CC @jleightcap: I've assigned you on this, but we'll probably need to coordinate to make the final repo configuration changes. Ping me when you get to that point 🙂