Adding badges / indicators for Trusted Publishers

[rsokl]

Context: the new trusted publishers method rocks, you all rock, and I want as many prominent pypi projects to adopt this as possible.

What's the problem this feature will solve?

• Improve discoverability of the Trusted Publishers method
• Incentivize projects to migrate to Trusted Publishers
• Make it easier for people doing OSS supply chain assessments to see, at a glance, that a project is using Trusted Publishers

Describe the solution you'd like
Now that hydra-zen is using trusted publishers, I want my little pypi badge to display some kind of shield, letting my users know about the enhanced security / advertising to other projects that this is a thing

(gimme a shield with, like, some fierce looking snake on it!)

It would also be nice if hydra-zen's pypi page featured some Trusted Publishers checkmark. Namely, when I am doing a supply chain review, it would be great to see if a project is utilizing this at a glance.

Additional context
Love this new capability! Awesome work!

[webknjaz]

I think that something similar was proposed by GitHub during the private beta. I think it was mostly concerning the PyPI side badges, not the embedded ones.

[tmr232]

Would be nice to have something akin to Mastodon's "verified" checkmarks near the repo link.
That way I can tell at a glance "this is really the project published from that repo".

I guess flagging all other projects linking the same repo would also be nice...

[woodruffw]

Triaging: this will happen with the completion of #15871 -- when a Trusted Publisher uploads an attestation alongside the normal package upload, we'll mark the project on PyPI's side with a little UI boondoggle.

(I'm not 100% how markdown badges are generated, though, or if PyPI even has any control over those...)

[di]

(I'm not 100% how markdown badges are generated, though, or if PyPI even has any control over those...)

We will likely not inject additional badges into a project description, since this is all user-supplied and we have no precedent for modifying it besides rendering it.

I think now that we have a "verified metadata" section, we can elevate the link to the source repository for projects that use trusted publishing for a release instead.

@woodruffw I don't think we need to wait for #15871 to do that though? We can verify the publisher was used without the attestation being present, and I wouldn't want to limit this only to projects that use trusted publishing AND publish attestations.

[woodruffw]

@woodruffw I don't think we need to wait for #15871 to do that though? We can verify the publisher was used without the attestation being present, and I wouldn't want to limit this only to projects that use trusted publishing AND publish attestations.

Yep -- this was based on an earlier misunderstanding of mine 🙂.

For others' visibility, the current WIP for this does not require #15781: #16205

[mgorny]

I'm not sure if it's really the same issue, but I'd really love to see some better visibility for trusted publishing use. I mean, I didn't even realize that projects have actually started using it until I actively started looking for information.

Please correct me if I'm mistaken, but currently you can determine that project is using signed publishing by either:

• using the API
• looking into "file details" for a specific upload
• noticing that "Verified details" contains "project links", whereas otherwise it only lists maintainers

The first two options basically means going out of your way to check, and the third option ­— well, I never even noticed the difference! I mean, reordering the same items between two sections is hardly a readable way to expose such an important detail.

I would really love to see an UI element saying explicitly "this project uses trusted publishing", and I also think it would make sense to indicate that on the file list, rather than only in the details.

[webknjaz]

Note, sure about “uses trusted publishing” signal, but maybe “Some/all of this project's distribution packages have attestations uploaded”?

[woodruffw]

@mgorny

Please correct me if I'm mistaken, but currently you can determine that project is using signed publishing by either:

Sort of: this will tell you if the project is using Trusted Publishing (not necessarily uploading attestations, per below), but only for Trusted Publishing providers that we currently do URL verification for.

Not all Trusted Publisher providers have meaningful URLs (e.g. Google Cloud), so it's possible to publish with Trusted Publishing and not have any verified URLs.

I would really love to see an UI element saying explicitly "this project uses trusted publishing", and I also think it would make sense to indicate that on the file list, rather than only in the details.

I think this would be good, although I think we also need to think a bit about how best to signal it in the UI -- users already find Trusted Publishing vs. attestations confusing, and there's a reasonable concern that highlighting a project's publishing technique can (effectively) "punish" projects that don't use Trusted Publishing for whatever reason (and there are lots of decent reasons).

Related to this, I've been wanting to expose more index-site project state (primarily the archive status, but also things like TP status) in the standard APIs. There's a DPO discussion on that which you might find interesting 🙂

---

@webknjaz

but maybe “Some/all of this project's distribution packages have attestations uploaded”?

This is currently signaled by the integrity endpoint: if a file has a provenance response, then it has one or more attestations (present in that response) 🙂

This in turn is an injective signal for Trusted Publishing, since attestations currently imply Trusted Publishing. However this is not bijective, since someone can still enable Trusted Publishing solely without using/uploading attestations.

[mgorny]

Hmm, that's a fair problem. My point was mostly being able to quickly tell whether to attempt verifying the attestations for a given project. I suppose that for me. the most convenient way would be to include that information in RSS, ideally, in <title/> of each version (i.e. have some marker if at least one artifact is signed), so my RSS reader would tell me "verify attestations before adding the new version".

[woodruffw]

Makes sense!

My point was mostly being able to quickly tell whether to attempt verifying the attestations for a given project.

FWIW, you can do this currently with the integrity API. It doesn't have a UI element yet, but a 404 response from the API is intended to convey "nothing to verify" while a 200 response conveys "you should verify the response's attestations."

Including this in the release RSS feeds makes a lot of sense to me as well; I can look into trying that, assuming @miketheman and @di have no objections 🙂

[miketheman]

Something I thought of over the weekend.

TP verification is located as metadata on files, not a release, nor a project.
Using Trusted Publishing can state: at one point in time, when this file was uploaded, it was from a TP-enabled verification flow.
If any other files were uploaded via non-TP methods (either at the same time from another uploader using an API Token, or sometime later by a human adding another file to an existing release), then the release is no longer fully TP-verified, and may affect the way things are displayed or considered.

I don't know if RSS is the right place to surface this kind of behavior either, but would be cautious about adding more metadata to endpoints without a thought-out approach for API-driven changes on that front.

[woodruffw]

Using Trusted Publishing can state: at one point in time, when this file was uploaded, it was from a TP-enabled verification flow.
If any other files were uploaded via non-TP methods (either at the same time from another uploader using an API Token, or sometime later by a human adding another file to an existing release), then the release is no longer fully TP-verified, and may affect the way things are displayed or considered.

Yep, I think this is one of the things that's really hard to communicate about how TP/attestations work (since users think in terms of releases, and PyPI thinks in terms of files).

OTOH we already have a helper for this: Release.trusted_published true if and only if all files in the release were uploaded via TP:

warehouse/warehouse/packaging/models.py

Lines 839 to 847 in 834086f

	def trusted_published(self) -> bool:
	"""
	A Release can be considered published via a trusted publisher if
	**all** the Files in the release are published via a trusted publisher.
	"""
	files = self.files.all() # type: ignore[attr-defined]
	if not files:
	return False
	return all(file.uploaded_via_trusted_publisher for file in files)

I think it would make sense to use this to drive an API field (JSON or RSS or whatever else).

[di]

For context, we've requested support from the OpenSSF to improve the UX/UI here: ossf/tac#424. If that grant is accepted, any improvements here would probably wait until that project is complete (or be included in it).

The general long-term plan here is to make verification of build provenance (which Trusted Publishing enables) happen by default at install-time without the user needing inspect a badge, manually use the API, look at file details, etc.

Given that there are valid and legitimate reasons for not using Trusted Publishing (e.g. we don't support the publisher yet), I don't think we should effectively penalize projects by creating a status badge or indicator that may be unavailable to them.

Additionally, @miketheman is correct that Trusted Publishing happens at the per-file level, not the release or project level, which complicates whether or not we'd display such an indicator (there are also legitimate reasons for using a mix of Trusted Publishing and non- Trusted Publishing, and a project that made releases before Trusted Publishing was available would not be able to achieve an indicator that says "all files for this project were published via Trusted Publishing").

That said:

I also think it would make sense to indicate that on the file list, rather than only in the details.

I do think it would be meaningful to add an indicator to the file list in the web UI, potentially linking back to the build.