I have a bit of uneasiness about how this is heavily pushing GitHub actions as the correct way to publish to PyPI. I had to check PEP740 to make sure it was not directly supported by Microsoft.<p>> The generation and publication of attestations happens by default, and no changes are necessary for projects that meet all of these conditions: publish from GitHub Actions; via Trusted Publishing; and use the pypa/gh-action-pypi-publish action to publish.<p>If you then click on "The manual way" it adds a big disclaimer:<p>> STOP! You probably don't need this section; it exists only to provide some internal details about how attestation generation and uploading work. If you're an ordinary user, it is strongly recommended that you use one of the official workflows described above.<p>Where the only official workflow is "Use GitHub Actions".<p>I guess I am an idealist but as a maintainer this falls short of my expectations for the openness of Python and PyPI.
I'm not really convinced of the value of such attestations until a second party can reproduce the build themselves on their own hardware.<p>Putting aside the fact that the mechanisms underpinning Github Actions are a mystery black box, the vast vast vast majority of github workflows are not built in a reproducible way - it's not even something that's encouraged by Github Actions' architecture, which emphasises Actions' container images that are little more than packaged installer scripts that go and download dependencies from random parts of the internet at runtime. An "attestation" makes no guarantee that one of these randomly fetched dependencies hasn't been usurped.<p>This is not to go into the poor security record of Github Actions' permissions model, which has brought us all a number of "oh shit" moments.
After 2FA, the previous PyPI buzzword that was forced on everyone, JFrog discovered a key leak that compromised everything:<p><a href="https://news.ycombinator.com/item?id=40941809">https://news.ycombinator.com/item?id=40941809</a><p>JFrog also discovered multiple malicious package exploits later.<p>Now we get a Github centric new buzzword that could be replaced by trusted SHA256 sums. Python is also big on business speak like SBOM. The above key leak of course occurred after all these new security "experts" manifested themselves out of nowhere.<p>The procedure remains the same. Download a package from the original creators, audit it, use a local repo and block PyPI.
From the [docs](<a href="https://docs.pypi.org/trusted-publishers/internals/" rel="nofollow">https://docs.pypi.org/trusted-publishers/internals/</a>):<p>> Reliability & notability: The effort necessary to integrate with a new Trusted Publisher is not exceptional, but not trivial either. In the interest of making the best use of PyPI's finite resources, we only plan to support platforms that have a reasonable level of usage among PyPI users for publishing. Additionally, we have high standards for overall reliability and security in the operation of a supported Identity Provider: in practice, this means that a home-grown or personal use IdP will not be eligible.<p>From what I can tell, this means using self-hosted Github/Gitlab/Gitea/whatever instances is explicitly not supported for most projects. I can't really tell what "a reasonable level of usage among PyPI users" means (does the invent.kde.org qualify? gitlab.gnome.org? gitlab.postmarketos.org?) but I feel like this means "Gitlab.com and maybe gitea.com" based on my original reading.<p>Of course by definition PyPI is already a massive single point of failure, but the focus on a few (corporate) partners to allow secure publishing feels like a mistake to me. I'm not sure what part of the cryptographic verification process restricts this API to the use of a few specific cloud providers.
They even got some public money from Germany's sovreign tech fund to couple uploads with gigantic USA companies.<p>This is probably deserving a criminal investigation since it appears the funds were probably misused?<p>Well done guys! Good job!
Supply chain security is very important, and this seems like an important step. Seems absolutely essential that something like the Mozilla foundation, or EFF, or some other open-source friendly entity help provide such a service, instead of corralling users into companies with exploitative business models.<p>I am in no hurry to be pushed into using Github, Gitlab or whatever else. Programmer's open source code has been monetized by these companies to feed AI LLM beasties, and it's fundamentally objectionable to me. I self-host my code using Gitea for that reason.
Congratulations to everyone involved in this work! This is an incredible building block for not just supply-chain security both inside and downstream of the PyPI ecosystem but also for data analysis of open source projects (through strong linkage back to source repositories). Thank you all <3
Here is the GitHub issue you can subscribe to for automatically generated attestations in the GitHub CI PyPi upload action: <a href="https://github.com/pypa/gh-action-pypi-publish/issues/288">https://github.com/pypa/gh-action-pypi-publish/issues/288</a>
Very cool, and congrats!<p>The corresponding ToB blog post says the following:<p>> Longer term, we can do even better: doing “one off” verifications means that the client has no recollection of which identities should be trusted for which distributions. To address this, installation tools need a notion of “trust on first use” for signing identities, meaning that subsequent installations can be halted and inspected by a user if the attesting identity changes (or the package becomes unattested between versions).<p>Agree: signing is only as good as verification. However, trust-on-first-use (TOFU) is not the most secure way to map packages to attestations because nothing stops attackers who have taken over PyPI from tampering with the _unsigned_ mapping of identities to attestations in package lockfiles for new clients (certainly in containerized environments where everything could look new), and even just new versions of packages.<p>Although [PEP 458](<a href="https://peps.python.org/pep-0458/" rel="nofollow">https://peps.python.org/pep-0458/</a>) is about signing the Python package index, it sets the foundation for being able to securely map packages to signed in-toto _policies_, which would in turn securely map identities to attestations. I think it is worth noting how these different PEPs can work together :)
The root point of this seems to be PyPI does not have the resources to manage user identity, and wants to outsource that component to Github, et al. That sounds fairly reasonable. But why deprecate GPG signatures? The problem with GPG signatures as I understand it is it's difficult to find the associated public key. That's fair. Why not host and allow users to add their public keys to their accounts? Wouldn't that solve the problem?
I'm very excited this has come to fruition!<p>PyPI's user docs[1] have some more details, as does the underlying PEP[2].<p>[1]: <a href="https://docs.pypi.org/attestations/" rel="nofollow">https://docs.pypi.org/attestations/</a><p>[2]: <a href="https://peps.python.org/pep-0740/" rel="nofollow">https://peps.python.org/pep-0740/</a>
Despite crypto getting easier and easier + more main stream. You often don't see it used that often. Even in ((('"```blockchain'"```))) projects (wink emoji; skull emoji; frown; picture of a chart crashing.) I welcome these additions to PyPI. I am a proud Python Chad and always will be.
Wonder when PyPI will be doing bootstrappable and reproducible builds.<p><a href="https://bootstrappable.org/" rel="nofollow">https://bootstrappable.org/</a> <a href="https://reproducible-builds.org/" rel="nofollow">https://reproducible-builds.org/</a>
So, let me get this clear, after PyPA enshittifying the package expérience for more than a decade, and now mess has been clean by uv, the security FUD (and let not be naive here, the power struggle) move onto enshittifying PyPI and make Python user miserable for a decade more ?