←back to thread

PyPI now supports digital attestations

(blog.pypi.org)
218 points miketheman | 5 comments | 14 Nov 24 14:25 UTC | HN request time: 0.831s | 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 #
freeone3000 ◴[14 Nov 24 19:34 UTC] No.42140207[source]▶
It requires an OIDC IdP, though… with PGP, I can verify that my identity is constant, but now, I’m reliant on some chosen third-party. And it has to keep being the same one, to boot! I don’t like the lock-in this causes, and I definitely don’t like the possibility of my right to publish being revoked by a third party.
replies(1): >>42141767 #
beng-nl ◴[14 Nov 24 22:12 UTC] No.42141767[source]▶
I’m only now learning about what OIDC IdP is (for those like me: openid connect identity provider). But from my reading, a self hosted gitlab can function as an oidc idp.

That would be enough control, right?

replies(1): >>42142276 #
chippiewill ◴[14 Nov 24 23:14 UTC] No.42142276[source]▶
You can't use a self-hosted Gitlab because you can only use a "trusted publisher".

There's no hard technical reason for that. It's mostly that PyPI only want to trust certain issuers who they think will look after their signing keys responsibly.

replies(2): >>42143624 #>>42143918 #
1. woodruffw ◴[15 Nov 24 04:15 UTC] No.42143918[source]▶
There is a technical reason for it, and it’s explained in an adjacent thread. Accepting every single small-scale IdP would result in a strictly worse security posture for PyPI as a whole, with no actual benefit to small instances (who are better off provisioning API tokens the normal way instead of using Trusted Publishing).
replies(2): >>42145455 #>>42147268 #
2. chippiewill ◴[15 Nov 24 10:04 UTC] No.42145455[source]▶
I don't think that's a technical reason, that's more of a social reason about trust. Adding configurable JWT issuers is not technically hard or difficult to do in a way that doesn't compromise PyPI's inherent security. There's a configuration difficulty, but those using it will generally know what they're doing and it only compromises their own packages (which they can already compromise by losing tokens etc.)

I disagree with your assessment that provisioning API tokens is better than being able to authenticate with a JWT. It makes managing credentials in an organisation much easier as far fewer people need access to the signing key compared to who would need access to the API token. Using asymmetric keys also means there's less opportunity for keys to be leaked.

replies(1): >>42147194 #
3. woodruffw ◴[15 Nov 24 14:22 UTC] No.42147194[source]▶
Adding another IdP is not the hard part; establishing the set of claims that IdP should be presenting to interoperate with PyPI is. The technical/social distinction is specious in this context: the technical aspects are hard because the social aspects are hard, and vice versa.

If you work in a large organization that has the ability to maintain a PKI for OIDC, you should open an issue on PyPI discussing its possible inclusion as a supported provider. The docs[1] explain the process and requirements.

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

4. Spivak ◴[15 Nov 24 14:30 UTC] No.42147268[source]▶
> who are better off provisioning API tokens the normal way

As long as those packages get digital attestation, perhaps attested by PyPI itself post-upload or from a well-known user provided key similar to how GPG worked but managed by PyPI this time.

Surely you see how this is creating two classes of packages, where the favored one requires you use a blessed 3rd party?

replies(1): >>42147406 #
5. woodruffw ◴[15 Nov 24 14:51 UTC] No.42147406[source]▶
No, I don't. There's no plan, and there will be no plan, to make installers reject packages that don't have attestations. Doing so is technically and socially impossible, and undesirable to boot.

The strongest possible version of this is that projects that do provide attestations will be checked by installers for changes in identity (or regression in attestations). In other words, this feature will only affect packages that opt to provide attestations. And even that is uncertain, since Python packaging is devolved and neither I (nor anybody else involved in this effort) has literally any ability to force installers to do anything.