PyPI now supports digital attestations

Original Article ↗ Hacker News Discussion ↗

PyPI has introduced digital attestations for Python packages, tying uploads to verifiable build provenance via Trusted Publishing and, initially, GitHub Actions. Supporters see this as a major step for supply-chain security and future tooling like automated verification and SBOMs, while critics worry about centralization around large corporate CI providers, the exclusion of self-hosted or smaller platforms, and the quiet sidelining of alternatives like GPG signatures. Project maintainers involved emphasize that attestations and Trusted Publishing are optional and that API token uploads will remain supported, but many expect social pressure and tooling defaults to make attested packages effectively preferred over time.

Overview of PyPI Attestations Feature

  • New feature lets PyPI store and verify digital attestations tied to package uploads.
  • Implemented via PEP 740 and built on Trusted Publishing and OIDC.
  • Currently works automatically only for GitHub Actions + Trusted Publishing + official PyPI GitHub action; other providers planned (GitLab, etc.).
  • Manual attestation generation is documented but discouraged for most users due to complexity.

Security Goals and Benefits

  • Aim: better supply-chain security and provenance (“where did this artifact come from, which repo/commit?”).
  • Attestations are bound to a specific commit and recorded in a transparency log; provenance can be inspected.
  • Seen as an improvement over long‑lived API tokens and unused PGP signatures.
  • View from some security-minded commenters: raises the bar materially, even without reproducible builds.

Limitations and Open Questions

  • Does not address a compromised maintainer machine: stolen GitHub credentials or edited source can still produce “valid” attestations.
  • Attestations only cover part of the supply chain (build step), not full end‑to‑end security or identity trust.
  • Reproducible and bootstrappable builds are discussed as the stronger but much harder goal.
  • How future tooling (pip, uv, rye, hatch, etc.) will verify or surface attestations is still experimental/unclear.

Concerns About GitHub-Centric Design and Lock-In

  • Strong criticism that the UX and docs heavily push GitHub Actions, with other providers lagging.
  • Many worry this creates two classes of packages: attested (via a few large CI/IdPs) vs. others.
  • Fear that, even if optional now, ecosystem pressure and future installer behavior will make attestations de facto mandatory.
  • Self-hosted CI and smaller/open providers are effectively excluded unless PyPI explicitly onboards them; criteria prioritize large, “notable” IdPs.

GPG/PGP and Alternatives

  • PGP signatures on PyPI were removed earlier; defenders say they were largely unused and hard to verify correctly.
  • Critics argue PGP capabilities were degraded over time and that key-hosting could have helped.

Wider Governance and Trust Issues

  • Thread reflects broad distrust of Python packaging decisions, perceived corporate capture, and state funding tied to US-based platforms.
  • Some maintainers prefer avoiding PyPI entirely (local mirrors, distro packages, or self-hosted repos) and see this as further centralization.