Implement PyPI Trusted Publisher

[richardfan1126]

I'm surprised nobody talked about PyPI Trusted Publisher on this important security-related library.

I know this can't solve all the problem, but with increasing supply chain attack, trusted publisher could possibly mitigate part of the attack vector.

I'm not sure what the reason is behind it. Is there concerns I'm not aware of, or just no manpower to do it

If it's just manpower issue, I'm happy to contribute

[EpicWink]

I also recommend publishing the packages with trusted publishing. Trusted publishing (with attestations) means I can know for certain¹ that what I download from PyPI is the same artefact which was generated in GitHub CI, meaning that what I see in GitHub is the same as what is installed - handy for auditing (rather than having to manually review all of the installed files on each release).

See the Python packaging documentation, the PyPI documentation, and the official pypi-publish GitHub action documentation on trusted publishing - you'll need to configure an environment in PyPI and GitHub.

You would create a new release job in the Wheels workflow, adding the environment and permissions (contents: read and id-token: write), and add steps which downloads the wheel artefacts and publishes them (using the PyPI publish action: uses: pypa/gh-action-pypi-publish@release/v1).

You will be able to remove the PYPI_USERNAME and PYPI_USERNAME project secrets.

Footnotes

1. as mentioned below, PyPI is assumed to be trusted ↩

[Legrandin]

Trusted publishing (with attestations) means I can know for certain that what I download from PyPI is the same artefact which was generated in GitHub CI

That is not what Trusted publishing (alone) gives you though: if PyPI was compromised and malware was overtly published on it, for any package, you wouldn't be able to tell. Trusted publishing is just a way for PyPI (not you) to be assured that the package was built by GitHub CI.

Things have improved a bit with the addition of sigstore in the workflow: I have not had a chance to check it out fully, but one can't help noticing that it relies on signatures by a centralized and unaudited CA (the fulcio public instance) and that neither pip nor uv currently check the CT log of said CA when they pull the package. The whole setup is now quite convoluted, and although it doesn't hurt and it perhaps improves things a bit (so that it could be indeed used by this project), it doesn't give you the straight guarantee you are looking for.

[Varbin]

have not had a chance to check it out fully, but one can't help noticing that it relies on signatures by a centralized and unaudited CA (the fulcio public instance) and that neither pip nor uv currently check the CT log of said CA when they pull the package.

Trusted publishing refers to using a GitHub OIDC token when uploading to GitHub rather than using an API token. In the OIDC token the repository and workflow is included. The signatures of packages AFAIK are not included anywhere at all.

Signatures by Fulcio are completely unrelated, but AFAIK use the same OIDC mechanism to authorize you (the GitHub workflow) to the CA.