PEP 761: Deprecating PGP signatures for CPython artifacts

[sethmlarson (Seth Michael Larson)]

@malemburg

I’m not sure why all this PGP/GPG bashing is needed to make an argument for not providing PGP/GPG sigs anymore.

Indeed, this is why I’ve avoided in the PEP using the security of PGP as a justification for its discontinuance. I don’t think we need to prove or disprove whether PGP is “dead” or insecure to improve the ergonomics of our release workflow.

@malemburg

This would eliviate the need for manual interaction by the RM and also removes the need for the RMs to maintain personal PGP/GPG keys - those can be managed in a central place and also easily rotated on a regular basis.

This would still require management by someone, likely release managers, and mostly for the benefit of downstreams that are likely to want to adopt Sigstore anyway to serve the thousands of PyPI packages that will be providing verification materials in the near-future.

@malemburg

I think the PEP ought to put more emphasis on this aspect, rather than using the new shiny thing is so much better and we should all use it approach.

I apologize if the PEP had this tone anywhere as that wasn’t the intention, I don’t subscribe to “new shiny thing”-driven development. I tried to capture the difference in security model in the “Security Considerations” section without duplicating too much of the nitty-gritty, instead linking out to Sigstore’s more authoritative documentation for folks interested in the details.

@thesamesam

In Gentoo, we’re not able to start evaluating or testing sigstore until CLI: --offline should mean fully offline · Issue #483 · sigstore/sigstore-python · GitHub is fixed (which it appears to be now) and it lands in a release, as it can’t work offline otherwise.

Thanks for joining this thread and providing feedback!

I’ll ask @woodruffw to publish a release of the Python Sigstore client (edit: Sigstore-Python v3.4.0 is now available on PyPI, thanks William!), I know the Go client is also available which Gentoo might be interested in. edit: I’ve confirmed directly with the Sigstore Go client folks that the client supports offline verification without TUF so should be acceptable to Gentoo’s needs, please report back with any issues.

@thesamesam

I would encourage both PGP + sigstore for at least one more release cycle to allow folks to both adapt and provide feedback, with a warning on the PGP sigs on the download page at least.

The final decision on discontinuation timeline rests with the SC, accepting or editing this PEP doesn’t remove the ability to delay discontinuation. To inform the SC decision-making and Sigstore maintainers on what they might work on next, could you answer these questions:

When does Gentoo start packaging a new Python version, betas? In the most aggressive timeline the first 3.14 beta is available mid-May, meaning 7 months before any real “disruption” is experienced. This can be extended if a manual verification process is acceptable for some time (which is what Debian maintainer @stefanor mentioned as their worst-case if Sigstore support can’t be added to uscan fast enough).

Are there any other blockers to Sigstore adoption beyond offline verification? I’m aware you may not have had an opportunity to fully test Sigstore yet, but how soon could you know whether there are blockers or not?

It’s definitely the plan to put a warning on the PGP signature page if this PEP is accepted. I think it’s better to get awareness and feedback earlier, because I would much rather have either verifiers or Sigstore folks working on fixing the integration problems. If you have ideas where this thread can be syndicated to get more feedback into specific difficulties around using Sigstore as a distro that would be very helpful.

Thanks again!