PEP 761: Deprecating PGP signatures for CPython artifacts

[sethmlarson (Seth Michael Larson)]

@ambv

One thing I would like Sigstore to allow us is for any release manager from the team to be able to issue a new release of any Python version. I did do this a few times over the years, and the last attempt (although generally successful) caused confusion as to why the Sigstore signatures are mine and not Pablo’s. But this is probably off-topic here.

Yeah, this is something that’s on my long-term roadmap as well: the adoption of “workload identities” instead of using release manager identity. In short, this would be possible if all of our artifacts were generated on platforms that are supported by Sigstore. Outstanding we have macOS artifacts that are generated outside of a hosted build platform and Azure Pipelines doesn’t support OpenID Connect identities last I checked (which wasn’t that long ago?)

@merwok

Is there a way to engage with downstream distributors (conda, debian, fedora, BSDs…) to coordinate this change and be sure the dates chosen don’t cause avoidable trouble or ill-will?

I pinged a few folks from Red Hat and Fedora that I knew about in the pre-PEP discussion. As you mentioned Debian and Ubuntu are also aware, the discussion spawned from the pre-PEP discussion as well, I think there is alignment on adding support for Sigstore to tooling because there are becoming more-and-more Sigstore signatures for projects being repackaged (ie, from NPM and soon from PyPI with PEP 740).

My hopeful read of the situation is that if support is added to tooling then our decision isn’t as negatively impactful one as it might have been a few years ago where there wasn’t as much interest in adding Sigstore support to tooling.

I can try to find some more people, I’m not sure what other levers we have to spread the word about this upcoming change, maybe the Python blog?