PyPI now supports digital attestations

Packaging
1

PSA: PyPI’s support for PEP 740 is now live, and enabled by default for packages that use Trusted Publishing with the canonical PyPA pypi-publish action!

The switch was silently flipped a few weeks ago, but today makes it official. Since enablement, we’ve seen over 20,000 attestations uploaded to PyPI and 20/360 (so far) of the top packages upload attestations. The latter can be tracked with Are we PEP 740 yet?.

User docs: Introduction - PyPI Docs

More details on the PyPI blog: PyPI now supports digital attestations - The Python Package Index Blog

My colleagues and I have also written an internals-focused blog post: Attestations: A new generation of signatures on PyPI | Trail of Bits Blog

13 Likes
2

Congratulations!

What’s the current progress on manual attestations to support projects not hosted on GitHub (or instructions for how we can integrate our own code forges)?

Edit: Mea culpa, I should have read the linked blog more closely. Looks like there is a manual workflow available but it still requires the use of GitHub Actions (so not really sensible for those of us not using GitHub). Progress on supporting additional code forges seems to be tracked in PEP 740: Post-deployment tasks · Issue #17001 · pypi/warehouse · GitHub for the time being.

3 Likes
3

Congratulations @woodruffw, and thank you for your help and work (and patience with various problems I’ve had!) to allow and encourage adoption.

A

1 Like
4

Yep! The plan is to enable GitLab in short order, followed by the other currently supported Trusted Publisher providers, followed by looking into non-TP identities (like emails).

1 Like
5

Maybe this is a stupid question but where and what are the attestations? Are they on PyPI somewhere and if so how do you see them for a package?

6

See the “How to view a file’s attestations” section in the blog post.

1 Like
7

The part that is missing from the docs is that when looking at a PyPI package the attestations are found by going to the “download files” page and then clicking the “view details” link next to an artifact. I guess that view details page has been there a long time although I haven’t looked at it before.

Looking at that attestation report I see that it notes the publisher with a link to the workflow file but that is a HEAD link. I thought that this would trace it back to the exact commit but I don’t see any identifier for the commit that was used.

1 Like
8

The exact commit information is present, but we aren’t presenting it in the web UI yet. If you click on the transparency log entry link you’ll see it in the signing certificate’s extensions. My colleagues and I will be working on refining the web UI in the coming days!

3 Likes
9

Okay I see the workflow SHA there. Does the trusted publishing mechanism ensure that the commit itself can still be found in future? For example if someone used force push to remove the commit from the GitHub repo would it still be possible to view the code from the commit somewhere?

10

GitHub shows the old commit even if the user pushed over it, it just displays a warning like

:warning: This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

This just happened to me :sweat_smile:, so for example:

2 Likes
11

It’s only a record and not an archive, so a you’d see the kind of warning @edgarrmondragon hit.