Onboard maintainers to the release process

[FFY00]

Our release process requires that maintainers have their PGP key listed in https://pypa-build.readthedocs.io/en/stable/installation.html, and preferably have their key signed by one of the other maintainers.

@pypa/build-committers if you wish to get onboarded, please reply to the issue with your PGP key and preferred email (that is listed in the key).

I will send you an email with a simple file for you to sign, to verify you hold the key and have access to the key email. After that I will sign your key and push it to the keyserver. Afterwards, either me or you can open a PR adding the key to the install documentation page, I will add you as a PyPI maintainer when the PR lands.

[henryiii]

I can make a PR, or just put it here: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x2fdec9863e5e14c7bc429f27b9d0e45146a241e8 - any GH email should be fine there too (see https://keyserver.ubuntu.com/pks/lookup?search=0x2fdec9863e5e14c7bc429f27b9d0e45146a241e8&fingerprint=on&op=index for the emails)

[webknjaz]

Looks like this would help solve things like #615...

[henryiii]

We got stuck trying to get my PGP key signed during PyCON. I think I need to export it then reimport it to pick up the new signatures. I'll try to do that soonish.

[webknjaz]

I think I need to export it then reimport it to pick up the new signatures.

If you're talking about GitHub or GitLab, then yes — this is my experience in the past..

I'm wondering why people still don't go for sigstore these days...

[henryiii]

PGP support has been removed from PyPI:

https://blog.pypi.org/posts/2023-05-23-removing-pgp/

Personally, I'd be fine to move to trusted publisher releases.

[webknjaz]

Personally, I'd be fine to move to trusted publisher releases.

I talked to Filipe during PyCon and he had strong feelings about signing stuff locally IIRC 🤷‍♂️

By the way, it's a one-liner, to add sigstore signing to GHA..

[henryiii]

Yes, but it's simply no longer supported to sign stuff locally with PGP. It will be deleted on upload to PyPI.

[layday]

I don’t know if we’ve been uploading signatures to PyPI. As far as I’m aware Filipe signs git tags and that is it. Sent with [Proton Mail](https://proton.me/) secure email.

…

------- Original Message -------

On Wednesday, May 24th, 2023 at 08:31, Henry Schreiner ***@***.***> wrote: Yes, but it's simply no longer supported to sign stuff locally with PGP. It will be deleted on upload to PyPI. — Reply to this email directly, [view it on GitHub](#561 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AHNRFWCPZRV5ONRM3BQLRP3XHWMKTANCNFSM6AAAAAATYPB6R4). You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[henryiii]

The binaries were signed, I believe. How about this:

• Require signed git tags (with a list of allowed signatures) to build in CI.
• On a signed git tag, sigstore sign the binary on GHA.
• Publish with trusted publisher deployment.

Assuming you can check that a tag is signed & verify that the signature against a set of public keys, this should be secure enough? We just need to be as secure as Flit, Pip, and Installer. :)

[webknjaz]

The binaries were signed, I believe.

I verified that no release of build has signatures attached on PyPI, meaning they were never uploaded.

[webknjaz]

Publish with trusted publisher deployment.

Also, the job generating the dists (or better — a separate one) should run the sigstore action.

[webknjaz]

FWIW Filipe's reasoning was that since the GHA infra is a public platform with shared runners, it cannot be trusted at all because we can't rely on it isolating different jobs well enough.
So the attack vector he was thinking about is the runner compromise.

[henryiii]

Wouldn't requiring several maintainers to sign-off on the deployment environment help with that? Then GitHub itself would have to be compromised, I think, as the runner waits for GitHub?

[webknjaz]

GH environments don't have minimum number of approvals IIRC + the attack vector was the compromise of the runner, that's after the approval, once the secrets are made available to the runner. So it's not about breaking into the entire platform, just a neighboring VM on the same runner, for example.