Switch to trusted publishing for releases?

[woodruffw]

build is at the center of a large (and growing) number of dependency graphs, so I'm plugging trusted publishing as a good idea: with trusted publishing, build would use GitHub Actions for PyPI releases, and would be able to do so automatically and securely without having to pre-configure an API token.

If there's interest, then I'm more than happy to send a PR adding a trusted publishing workflow + offer guidance on how to use it!

[henryiii]

You'd need to get @FFY00's approval, I think the rest of us would be okay with it if @FFY00 approved, but that might not happen. The worry is over security, is that we'd be allowing public CI to release, and the attack vector would be someone taking over GHA and releasing a malicious version of build.

If our dependencies (like pip, flit, packaging) used GHA to release, it would be an easier sell. But I don't think they do.

[henryiii]

A simi-dependency, virtualenv, uses Trusted Publisher releases: https://github.com/pypa/virtualenv/blob/main/.github/workflows/release.yml

[woodruffw]

As another datapoint: wheel also switched to trusted publishing: pypa/wheel@e3c46aa

[FFY00]

The worry is over security, is that we'd be allowing public CI to release, and the attack vector would be someone taking over GHA and releasing a malicious version of build.

Yup, and since we ship pure wheels and don't need to build for wide set of platforms/environments, I struggle to see the benefit of building in the CI. Trusted publishing solves an issue for users who want to build release artifacts in the CI, however, I don't think this is an issue we have. Does that make sense?

That said, I realize I may have been too harsh on sticking to my position, so while my thoughts on the issue haven't changed, if the other maintainers feel strongly about this, I am happy for the project to adopt a different release workflow. Especially considering I have taken a long break from active maintenance of this project, as I sort out my mental health and other issues.

[woodruffw]

Yup, and since we ship pure wheels and don't need to build for wide set of platforms/environments, I struggle to see the benefit of building in the CI. Trusted publishing solves an issue for users who want to build release artifacts in the CI, however, I don't think this is an issue we have. Does that make sense?

I understand this position, but I want to provide some pushback on it from two angles:

1. I think a large benefit of publishing in CI is isolation of concerns and process: "concerns" in the sense that the CI job is responsible for a single task (publishing) and has no permissions larger than that task (e.g can't modify the upstream repo, like a developer's laptop can), and "process" in the sense that it ensures that the publishing process is fully defined by a CI setup without implicit local development state (undocumented deps, steps, that kind of thing).
2. From a security perspective, the general benefit of publishing with CI falls under the separation of concerns point above. However, using trusted publishing specifically has additional security benefits: the credentials involved are self-expiring and can't be mis-scoped, and provide a strong link between the repository identity (e.g. pypa/build) and the distribution being uploaded to PyPI. That link isn't exposed publicly but the plan is eventually to do so, meaning that users will be able to make security decisions like "this distribution says that it's hosted at this repository, but the source artifact didn't actually come from there, so I won't trust it."

TL;DR: I think on a practical level, CI publishing makes for good process. With my security hat on, CI publishing (especially with trusted publishing) reduces the overall number of ways an attacker can compromise a Python package.

With all that said, I want to acknowledge that it's your project and ultimately your call to determine an appropriate threat model for yourselves. So if I haven't been persuading enough to at least continue this conversation, please feel free to close this 🙂