←back to thread

PyPI now supports digital attestations

(blog.pypi.org)
218 points miketheman | 2 comments | 14 Nov 24 14:25 UTC | HN request time: 0.416s | source
Show context
belval ◴[14 Nov 24 16:05 UTC] No.42137562[source]▶
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.

> 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.

If you then click on "The manual way" it adds a big disclaimer:

> 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.

Where the only official workflow is "Use GitHub Actions".

I guess I am an idealist but as a maintainer this falls short of my expectations for the openness of Python and PyPI.

replies(9): >>42137628 #>>42137831 #>>42138035 #>>42138967 #>>42140525 #>>42140881 #>>42142188 #>>42144001 #>>42144423 #
woodruffw ◴[14 Nov 24 16:12 UTC] No.42137628[source]▶
> Where the only official workflow is "Use GitHub Actions".

The standard behind this (PEP 740) supports anything that can be used with Trusted Publishing[1]. That includes GitLab, Google Cloud, ActiveState, and can include any other OIDC IdP if people make a good case for including it.

It's not tied to Microsoft or GitHub in any particular way. The only reason it emphasizes GitHub Actions is because that's where the overwhelming majority of automatic publishing traffic comes from, and because it follows a similar enablement pattern as Trusted Publishing did (where we did GitHub first, followed by GitLab and other providers).

[1]: https://docs.pypi.org/trusted-publishers/

replies(6): >>42137658 #>>42137713 #>>42139209 #>>42140207 #>>42140433 #>>42143213 #
belval ◴[14 Nov 24 16:19 UTC] No.42137713[source]▶
I get that, that's why I didn't go "This is Embrace Extend Extinguish", but as constructive feedback I would recommend softening the language and to replace:

> STOP! You probably don't need this section;

In https://docs.pypi.org/attestations/producing-attestations/#t...

Perhaps also add a few of the providers you listed as well?

> The only reason it emphasizes GitHub Actions is because that's where the overwhelming majority of automatic publishing traffic comes from

GitHub being popular is a self-reinforcing process, if GitHub is your first class citizen for something as crucial as trusted publishing then projects on GitHub will see a higher adoption and become the de-facto "secure choice".

replies(2): >>42137810 #>>42145611 #
HelloNurse ◴[15 Nov 24 10:36 UTC] No.42145611[source]▶
PyPI should support and encourage open infrastructure.

If I don't want to use GitHub, let alone GitHub Actions, I am now effectively excluded from publishing my work on PyPI: quite unacceptable.

replies(2): >>42146737 #>>42155149 #
woodruffw ◴[15 Nov 24 13:30 UTC] No.42146737[source]▶
That’s now how any of this works. I am begging you to re-read the docs and understand that this does not require anybody to use GitHub, much less GitHub Actions, much less Trusted Publishing, much less attestations.

You can still, and will always be able to use API tokens.

replies(3): >>42146895 #>>42147060 #>>42147226 #
1. st3fan ◴[15 Nov 24 14:26 UTC] No.42147226[source]▶
Well, yes and no. From the perspective of an infosec professional who is focussed on supply chain security I can tell you that your package having an attestation from a trusted platform like GitHub or GitLab gives me a warm feeling. It is not the only thing we will look at but definitely part of a longer list of checks to understand risk around dependencies.

With an attestation from GitHub I know at least that the workflow that ran it and the artifacts it produced will be 100% traceable and verifyable. This doesn't mean the code was not malicious, but for example it will rule out that someone did the build at home and attached an alternative version of an artifact to a GitHub release. Like how that was done with the xz project.

It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.

replies(1): >>42147273 #
2. woodruffw ◴[15 Nov 24 14:31 UTC] No.42147273[source]▶
> It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.

Yes, agreed. This is why the docs explicitly say that we’re planning on enabling support for other publisher providers, like GitLab.