4 ms·
The real question: how can pip still not allow me to verify a downloaded package with a public key of my choice (PGP key or others, the format is irrelevant)?
by zimmerfrei 3y ago
The real question: how can pip still not allow me to verify a downloaded package with a public key of my choice (PGP key or others, the format is irrelevant)?
In most cases, I don't even want to know who the author is, but just be warned if the signing key changed since last time (possibly because pypi has been compromised, which is the elephant in the python ecosystem room).
This minor feature has been blocked for years on ideological basis (and matched to questionable decisions like hiding on purpose the signatures from the pypi UI), on the grounds that keys are not discoverable and not attached to a strong identity (which happens to be an argument close to what this article say).
Just add that possibility, make it opt in, and allow the ecosystem to figure how out solve the key management/trust/identity problem.
- lukeschlather 3y agoIIRC Google solved this recently in the Play Store by signing packages themselves. But the cost was that it's much harder (impossible?) for me as a package maintainer to be sure that the package I built is the one I'm distributing; it means now Google can alter the package and nobody will be any the wiser. I think a lot of the trouble with this article (and the article it links about why PGP is broken) is that it doesn't specify a threat model. It makes some good arguments why specific threats are not mitigated, but rather than attempting to fix broken processes or replace specific components it suggests just throwing out the whole idea. And some of the arguments seem to point toward using a Google-style central packager/verifier but there are good reasons PyPy doesn't do this and many wouldn't want them to.
- yjftsjthsd-h 3y agoSurely the correct solution is having both parties sign the same artifact?