PyPI now supports digital attestations

Original Article ↗ Hacker News Discussion ↗

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.