Top
Best
New

Posted by jwilk 10/25/2024

Python PGP proposal poses packaging puzzles(lwn.net)
44 points | 8 comments
tptacek 10/28/2024|
This leaves out the important context that key verification for these packages isn't functional.

In the last 3 years, about 50k signatures had been uploaded to PyPI by 1069 unique keys. Of those 1069 unique keys, about 30% of them were not discoverable on major public keyservers, making it difficult or impossible to meaningfully verify those signatures. Of the remaining 71%, nearly half of them were unable to be meaningfully verified at the time of the audit (2023-05-19) 2.

More, recently, on this thread:

https://news.ycombinator.com/item?id=41873215

ArchOversight 10/28/2024|
This is related to the distribution of CPython itself, the key verification for those artifacts does work and has worked forever. The packaging referred to by the article is about packaging Python itself by upstream distributions.

Python packages developed by third party developers and uploaded to PyPi are indeed not verifiable due to the key issues you mentioned, and is a minor note in the article.

woodruffw 10/28/2024|||
> the key verification for those artifacts does work and has worked forever.

Go try to verify some of the PGP signatures on CPython releases that are older than 2.7. You might be surprised.

westurner 10/28/2024|||
W3C DIDs are verifiable e.g with blockchain-certificates/cert-verifier-js and blockchain-certificates/cert-verifier (Python).

If PyPI is not a keyserver, if it only hosts the attestations and checks checksums, can it fully solve for [Python] software supply chain security?

A table comparing the various known solutions might be good; including md5, sha3, GPG .ASC signatures, TUF, Uptane, Sigstore (Cosign + Rekor), PyPI w/w/o attestations, VC Verifiable Credentials, and Blockcerts (Verifiable Credentials (DIDs))

hifromwork 10/28/2024||
>In the PEP, Larson argues that providing PGP and sigstore signatures fails to give downstream projects any incentive to adopt sigstore. So long as CPython continues to provide PGP signatures, there is little motivation to adopt sigstore.

No better way to convince people to use a standard than forcing them. Taking away choice by force sounds a bit contradictory to the idea of Open Source. I mean, maybe sigstore is a better idea, but why not let people make their choice.

SethMLarson 10/29/2024|
Hello! Great question.

I tried to cover this in PEP 761, this comes down to a few things:

Python release managers don't want to use PGP due to the ergonomic burden. They are volunteers too, after all. This is the key point, and we are making that sentiment clear early (and with an extendable timeline also defining who gets to choose: Steering Council) so that everyone else can plan and take action.

There have been past efforts to stop using PGP that failed likely due to a lack of alternative. Now there is an alternative, but having an alternative is not enough. Verifiers need to start using the new method. It's been 2 years and no Linux distributions support verifying with Sigstore.

From my perspective there has been little to no work to look into Sigstore and whether it's usable by Linux distros. There's a gap in understanding about how Sigstore works in some places. I would not have this perspective without starting this conversation, I've been sharing all the feedback with Sigstore folks along the way.

I hope this provides more context into the "why". This is why "do both forever" is not a solution for us.

wesselbindt 10/28/2024||
Awesome alliteration always achieves amusement.
dmwilcox 10/30/2024||
I'm not an openbsd person, though maybe one day!, but why change to complicated failure-prone tech when you could have something simpler and more secure?

https://man.openbsd.org/signify https://github.com/aperezdc/signify

I used to use PGP yubikey for everything but the subkey renewal process was so onerous I switched to PIV keys with age and haven't looked back. Never mind all those legacy ciphers in GPG are just attack vectors that haven't happened yet.

darig 10/25/2024|
[dead]