←back to thread

PyPI now supports digital attestations

(blog.pypi.org)
218 points miketheman | 6 comments | 14 Nov 24 14:25 UTC | HN request time: 1.385s | source | bottom
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 #
silverwind ◴[14 Nov 24 16:15 UTC] No.42137658[source]▶
Why does this need to allowlist CI providers in first place? Why not publish an open interface any CI provider can integrate against?
replies(2): >>42137703 #>>42137727 #
woodruffw ◴[14 Nov 24 16:20 UTC] No.42137727[source]▶
Because the security benefit of Trusted Publishing via OIDC versus normal API tokens is marginal at small scales, in two senses:

1. The primary benefit of Trusted Publishing over a manual API token is knowing that the underlying OIDC IdP has an on-call staff, proper key management and rotation policies, etc. These can be guaranteed for GitHub, GitLab, etc., but they're harder to prove for one-off self-hosted CI setups. For the latter case, the user is no better off than they would be with a manual API token, which is still (and will always be) supported.

2. If the overwhelming majority of traffic comes from a single CI/CD provider, adding more code to support generic OIDC IdPs increases PyPI's attack surface for only marginal user benefit.

There also is no "open interface" for PyPI to really use here: this is all built on OIDC, but each OIDC provider needs to have its unique claims mapped to something intelligible by PyPI. That step requires thoughtful, manual, per-IdP consideration to avoid security issues.

replies(4): >>42138661 #>>42140243 #>>42142417 #>>42144916 #
1. chippiewill ◴[14 Nov 24 23:29 UTC] No.42142417[source]▶
I still think this is overly strict. Supporting arbitrary OIDC providers is not excessively complex or particularly rare, the major cloud providers all support it in one way or another [1][2][3], as does Hashicorp Vault [4]. I disagree that the primary benefit over a manual API token is _knowing_ that the OIDC IdP is following the best practices you talk about. Having it rely on asymmetric keys makes the process more secure and scalable than API tokens for those that choose to use it.

I think there's a separate question around trust. But I think blocking non-trusted publishers from using a more secure form of authentication isn't the answer. Instead I think it makes more sense to use nudges in the PyPI UI and eventually of consumers (e.g. pip) to indicate that packages have come from non-trusted publishers.

[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr... [2] https://learn.microsoft.com/en-us/graph/api/resources/federa... [3] https://cloud.google.com/identity-platform/docs/web/oidc [4] https://developer.hashicorp.com/vault/docs/auth/jwt

replies(1): >>42144570 #
2. guappa ◴[15 Nov 24 07:09 UTC] No.42144570[source]▶
I can create a github account. How does that make me trustworthy? How being able to create a github account prevents me from adding a virus in my module?
replies(1): >>42145442 #
3. chippiewill ◴[15 Nov 24 10:02 UTC] No.42145442[source]▶
It's not about the package maintainer, it's about the trustworthiness of the OIDC issuer to prove the identity of a user.

A poorly maintained issuer could leak their secret keys, allowing anyone to impersonate any package from their service.

replies(1): >>42145568 #
4. guappa ◴[15 Nov 24 10:28 UTC] No.42145568{3}[source]▶
But what use does it serve to prove that I am user "qioaisjqowihjdoaih" on github?

I mean it only proves I authenticated successfully. Nothing else.

replies(1): >>42145865 #
5. chippiewill ◴[15 Nov 24 11:17 UTC] No.42145865{4}[source]▶
It proves that a package was definitely uploaded from the correct repo.

Without trusted publishers a nefarious actor could use a leaked PyPI API key to upload from anywhere. If the only authorised location is actions on a specific Github repo then it makes a supply chain attack much trickier and much more visible.

With the new attestations it's now possible for package consumers to verify where the package came from too.

replies(1): >>42183118 #
6. guappa ◴[19 Nov 24 13:21 UTC] No.42183118{5}[source]▶
But… a github token could leak just as easily?