PGP signatures on PyPI: worse than useless

https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI-worse-than-useless

by woodruffw • 3 years ago

93 157 3 years ago

blog.yossarian.net

kibwen• 3 years ago

Are there any public package repos that do package signing well, or is this still an unsolved problem?

taeric• 3 years ago

I'm tempted to give in to the claim that a problem that is fundamentally a liability concern, and therefore needs legal fallback, is unlikely to have a technical solution.

Closest you can get is probably the Apple model?

ecliptik• 3 years ago

Debian packages, although they aren't signed but "use apt-secure (also known as secure apt) which is a tool that will allow a system administrator to test the integrity of the packages downloaded" [1].

1. https://www.debian.org/doc/manuals/securing-debian-manual/de...

exabrial9• 3 years ago

I think Maven does PGP fairly well. It's not perfect, but enh.

Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert.

They _require_ signatures for _every_ artifact uploaded.

The maven repository manager makes your release transactional. Either all of your artifacts are signed and the signatures match, or none of the artifacts are published.

Your release is rejected if you fail to pass the test.

After the checks, you are given the option to publish the transaction or not.

There is no undo button, as it should be.

I also reported a bug/security issue to Sonatype and they fixed it within a few weeks.

There is room for improvement:

I think they could get stricter and require the signing keys be listed in the pom or whatever build file you use.

Maven does some signature checking, but it oddly enough doesn't do pgp verification. Given that 100% of signatures are checked on upload, it technically is redundant since nearly everything is TLS these days.

I think Sonatype should publish a transparency keymap. This would probably be an actual good real-world use case for a blockchain too. KeyId -> Artifact Namespace controlled.

zokier3• 3 years ago

Does Maven Central check that the GPG key used matches anything? Or can you just use whatever random key to sign your packages?

woodruffw16• 3 years ago

Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert.

This isn't a property anywhere in PGP: a PGP identity can be an email, or it can be any other free-form identifier.

Individual keyservers can gatekeep inclusion based on email verification (which itself is flimsy, but ignoring that for the moment), but there's no strong guarantee that any particular keyserver does that (or will continue to do it, as a matter of policy). Uploading certs for "bill@microsoft.com" was a joke on the SKS servers for years.

blibble• 3 years ago

I write both Java and Python for a living

trying to guide junior devs in the right direction for python is nearly impossible (don't use setup.py, it's deprecated, ah except that, ah setup.cfg is now too, use setup.toml, ah I'll just check the docs, crap they're incomplete and inconsistent)

you can't call your package that as someone already used that name on the internet and it's a flat namespace, sorry you can't share modules between teams because everyone has their own mini pypi to push to and the tooling is actively hostile against namespacing

and the same is true of the build chain, trying to version the packages, even getting coherent dependency resolution between machines is a complete disaster

Java sorted out all the packaging mess 20 years ago, meanwhile Python continues to re-invent everything badly, and not just badly, really really badly

meanwhile pypa are faffing about mission statements and making github uploads very slightly more secure

python needs a Sonatype to replace pypa

zokier3• 3 years ago

NuGet (the .net package manager) maybe?

dale_glass14• 3 years ago

PGP is an unfortunate obsolete technology, which sadly failed to evolve with the times.

I think the main thing that crippled PGP is tooling. What we have available is GnuPG, and GnuPG is horrible for every use case but what it was made for: A command-line interactive application, made for a single person's personal usage.

GnuPG insists on a model where it manages everything: key parsing, a key database, and the entire signing/verification process. There's no proper libgnupg either, what gpgme does is calling gpg, and presenting a library interface.

The problem with this is that GnuPG is very unfriendly towards attempts to build something new from the pieces. It really wants to be a commandline application that deals with a single person's encryption/decryption activities. So if you want to say, run statistics on PGP keys, or write a keyserver, or use it to implement signatures for packages, either you do it the GnuPG way, or you very laboriously trick it into doing what you need, or you write your own crypto code.

Option 1 isn't great if you want anything weird like statistics gathering.

Option 2 is just awkward and messy. Both 1 and 2 quickly run into limits. GPG for instance doesn't like trying to work with a database of a million keys. It has heavy startup costs. It's made for humans, not for any kind of heavy lifting.

Option 3 sucks because OpenPGP is extremely complex, and writing crypto code is very ill advised for most people.

And I think that's kinda what crippled the ecosystem. Doing anything but what gnupg wants to do has extreme startup costs, so few people ever try, and most people do it badly.

Doing what the author did here involves really going out of your way -- in a better world we'd have simple to use tooling to do this work, and PyPI would just do validation and reject bad stuff, but doing so is extremely non-trivial in PGP.

*Edit:* Case in point, I wondered how the author did this analysis. They made a tool for it, in April 2023: https://blog.yossarian.net/2023/04/14/Introducing-pgpkeydump

This is a tool that GPG should have had decades ago, and yet it didn't exist until now, when pretty much everyone has given up on PGP signing.

Edit 2: A nice blog post on how painful it is to deal with gpg if you want to actually build on top of it: https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_Gnu...

WesolyKubeczek7• 3 years ago

Isn't there that new thing called Sequoia which is supposed to have all advantages of PGP while having none of its drawbacks?

dale_glass14• 3 years ago

Yup, but it's a new thing. It's something like 2-3 years old, I think?

I'm not sure, maybe that'll revive things some? But something of this sort has been needed for decades.

woodruffw16• 3 years ago

Sequoia is an implementation of OpenPGP, i.e. RFC 4880. It also supports a few non-standard extensions to OpenPGP, e.g. ECDSA and EdDSA signatures, better stream ciphers than CAST5, etc.

I think a legitimate selling point of Sequoia is simplicity: it's a new implementation, written in a memory-safe language[1], and it can make better (but still not optimal) default decisions.

At the same time, I don't think Sequoia succeeds in avoiding PGP's baggage or drawbacks: PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with.

It's unclear to me (personally) what the value proposition for Sequoia is meant to be, given that it's shackled to the past and can't do better on basic things like certificate malleability. If the goal is for it to be something better, I think it'd be best to cut the losses and start from stronger (and more modern) foundations.

[1]: Except that they've chosen to use Nettle for the cryptographic components, meaning that there's still a good chunk of C under the hood.

arthur2e5• 3 years ago

The pgpkeydump page links to... six pages about GPG in the "Much has been written about this" part.

GnuPG is one of the cases where "rewrite it in rust" helps a little. rPGP and sequoia-openpgp offer somewhat reasonable library interfaces. pgpkeydump depends on sequoia.

With a rewrite you also don't get maintainer issues like https://twitter.com/FiloSottile/status/1355194247482384392 either.

chlorion2• 3 years ago

Thanks for posting that link. I did not realize that the GPG maintainers were so terrible. This strongly reaffirms my choice to move away from GPG where possible!

forgotmypw1710• 3 years ago

It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist.

Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures.

I found GnuPG and OpenPGP.js are incredibly easy to integrate into my project. I didn't like the current ways that it is used, so I designed a new way, with disposable private keys, which frees the user from key management burdens. I don't use many of PGP's features which I don't need, such as key management and nested keys.

PGP is still an incredible standard and technology, the rare kind that's remained supported and (mostly) backwards-compatible for 25+ years, like HTML and Perl.

I'm glad it exists, and I anticipate it being useful for at least another 25, thanks to the Lindy Effect.

dale_glass14• 3 years ago

It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist.\

And arguably, it shouldn't exist. Modern thinking is that encryption is integral to a project and how it's implemented depends on what the project does.

The old way is: Secure mail by passing it through PGP. Secure messages by passing them though PGP. Secure packages by passing them through PGP.

The new way is: secure stuff by designing a system specific to what you need. So for instance, encrypting IM gives you the https://en.wikipedia.org/wiki/Signal_Protocol which has a whole bunch of complexity you wouldn't have for signing RPM packages because it needs it, while RPM doesn't.

arp2424• 3 years ago

It seems like without fail, whenever PGP is mentioned, someone is ready to offer criticism of it, usually without offering a better alternative, since one doesn't really exist.

For signing minisign, signify, and OpenSSH exist; most of them have been around for quite a while (OpenSSH signing is the only one that's relatively new).

They're not "alternatives to PGP" in the sense that they will do everything PGP can (notably, no encryption). But that's not really a bad thing, IMO, and for encryption alternatives exist too.

One of the problems that ecosystem support is often lacking, both for signing and encryption. git can sign with OpenSSH since last year, but that's one of the exceptions. But that doesn't mean alternatives don't exist.

Ecosystem support is hard; you need to convince untold authors of software to implement your new crypto thingymabob, and there's a "well, no one supports it yet, so why should I?" catch-22 here.

bscphil3• 3 years ago

without offering a better alternative

On the one hand, I sort of agree with you, I think the disadvantages of current PGP tools are overstated. But I think there are some plausible alternatives depending on your use case. They just aren't bundled into a single tool.

For file encryption, there's age. This uses all modern crypto and does authenticated encryption.

For signing, there's signify. I wonder if age and signify can be made to use the same keys...?

For live two-party encryption, there are protocols appropriate to the use case. Axolotl for chat, Wormhole for file transfers.

For PKI, there's... whatever people actually do instead of PGP keyservers and WoT, because they've never been a reliable way to find out someone's public key. In practice, you'd either download it from someone's website, get it off a keyring, receive it through some other secure channel, or be given it in person.

It's ironic that people make the argument "the reason no one uses PGP is that it doesn't have network effects, and the reason it can't build a network is that it sucks", because the thing keeping me on PGP is its network effects. In the circles I run in, you can count on people having PGP keys and knowing how to use them for encryption and signing. They've been used in Linux packaging for years, for example. I can't count on someone using age, at least not yet.

jcranmer3• 3 years ago

Yet it is the most stable, the most open, the most proven, and the most supported PKI technology, supporting both encryption and signatures.

You're completely ignoring the CA system used for TLS. In the niche segment of encrypted/signed email, S/MIME sees an order of magnitude or two more use than PGP. Even DNSSEC, for all its issues, is probably more used than PGP.

exabrial9• 3 years ago

signatures that can be correlated, many are generated from weak keys or malformed certificates. The results suggest widespread misuse of GPG and other PGP implementations by Python packagers

So a bunch of python packages don't implement the spec correctly... and this is pgp's fault.

woodruffw16• 3 years ago

Yes. As the post says: well-designed signing schemes need to be misuse resistant.

(And to be clear: it's not the "spec" they're failing to implement. The breakages here indicate that people aren't generating strong keys or doing signing operations correctly with the `gpg` CLI; poor design and documentation there is absolutely the tool's fault.)

tedivm• 3 years ago

This has been a problem with so many cryptographic systems over the years. For various reasons they prefer to be backwards compatible over being secure. As the best practices shift, the default values of these applications stay the same.

I understand why, to a certain extent. If your defaults change and people are expecting the old values it could break existing scripts and tool chains. For most applications this argument makes sense, but for security focused tools I think this is a mistake. Defaults should always represent best practices, and people who want specific flags should specify them.

waynesonfire• 3 years ago

Instead of throwing the baby out with the bath water, try posting on some python discord channel and educate ur users.

exabrial9• 3 years ago

The schema is right here: https://under-the-hood.sequoia-pgp.org/packet-structure/

Each bit in the packet is in an RFC actually and well defined. Again, the problem is on the python side.

donaldstufft9• 3 years ago

To my knowledge, everything in the Python packaging ecosystem that supports PGP signatures, does so by shelling out to the `gpg` command. Presumably gpg should be implementing the spec properly.

hklrc• 3 years ago

Snowden used gpg and taught it to non-programmers:

https://theintercept.com/2014/10/28/smuggling-snowden-secret...

I'm surprised by the number of people who say that gpg is insecure. Is it disliked because it is decentralized and everything has to be owned and tracked by the four MAGA (formerly FAANG) corporations?

A bullet proof HOWTO can fix all of this.

Avamander5• 3 years ago

Is it disliked because it is decentralized and everything has to be owned and tracked by the four MAGA (formerly FAANG) corporations?

It's shit to use and instead of improvements we see deflections like this. Sure, there are better implementations being worked on now, but where were they in the past 10, 20 years?

donaldstufft9• 3 years ago

A bullet proof HOWTO can fix all of this

You cannot document your way out of a usability nightmare.

prepend2• 3 years ago

The “usability nightmare” isn’t PGP/GPG fault, it’s PKI. PKI is hard to use because of its decentralized and free nature.

The “fix” is to channel everything through google, or a government, or some third party that makes it easy and usable, but removes the main benefits of security, transparency, and independence.

I think the reason GPG is all we have and has been for 20+ years is because that’s as good as it gets and better than nothing.

It lets people who know how to use it communicate securely.

So you can document your way out of an impossible to communicate securely nightmare.

Avamander5• 3 years ago

Of the 1067 keys IDs collected through signatures on PyPI, a full 308 (or roughly 29%) had no publicly discoverable key on the major remaining keyservers

Even if they existed on Ubuntu's or OpenPGP's, they'd still be annoying to discover due to the fact that GnuPG only supports a single key server at the same time. You want to have a correspondence with both Protonmail and Mailvelope users? Sucks to be you.

Not to mention the fact that if I wanted to maliciously sign something, I'd upload a wholly forged key to those keyservers and you'd happily discover them. It would be a step forward if we'd have more operators like Protonmail that would certify new keys, at least that way in many cases we'd know a key is actually old, rather than generated recently for an attack.

woodruffw16• 3 years ago

This is a great observation! There's a whole extended digression (which I cut out of the post) on how even the keyserver's response is insufficient, for exactly this reason. PGP as an ecosystem completely lacks any strong identity guarantees of the type that PyPI wants; without those guarantees, this is all just fragile hashing with more steps.

8organicbits• 3 years ago

I've been watching sigstore [1] as a better approach to signing artifacts. Anyone have experience using it with python?

[1] https://www.sigstore.dev/

ewdurbin• 3 years ago

Python release files have been signed with sigstore for the last couple versions. You can peruse the release tooling that uses it at https://github.com/python/release-tools

debatem1• 3 years ago

IME, many people want a very simple "sign this file" interface with a few complicating bells and whistles tacked on: certificate chains (maybe authorities, maybe TOFU/HPKP-style pinning), weak cipher rejection, and crypto hardware support.

That's not that hard in the scheme of things but it's definitely not trivial either, especially supporting weird HSMs.

Until something well supported, modern, and easy to use can do the above uncontroversially for 5-10 years gpg is going to see lots of misuse.

growse3• 3 years ago

Where does signify fall short on these?

progval• 3 years ago

That existing PGP signatures on PyPI serve no security purpose, and that all evidence points to nobody ever attempting to verify them;

Some Debian package maintainers do check them when downloading packages from PyPI. For example, in the .dsc archive for https://packages.debian.org/bullseye/limnoria, debian/upstream/signing-key.asc contains the key used to sign releases of https://pypi.org/project/limnoria/

donaldstufft9• 3 years ago

Debian is basically the reason we didn't delete PGP signature support in 2018, because in theory some handful of Debian packages might be better off with this support.

In practice I think the handful of packages that this happens on isn't particularly meaningful or valuable, and in my experience what happens when Debian finds a new key signing packages is.. highly variable. I've seen them just disable signatures when a new key shows up (on major packages even), I've seen them just blanket copy whatever the new key is, I've seen them look at release notes for what the new key is. In one or two cases I've seen them actually track down the project and ask for verification of the new key.

To me, the PGP support in Debian's uscan feels more like security theater than actual security controls, given my experience with the varied responses to a new release being made by a different key.

lukeschlather4• 3 years ago

Even just as a fancy checksum I think it has some value, and I think it does serve some security goals. I feel like this article also kind of amounts to listing off a bunch of threats that aren't being properly mitigated, and it doesn't really do a good job of separating which threats are not mitigated because of intrinsic deficiencies in PGP from which threats are not mitigated because other parts of the system haven't even made an attempt to mitigate the threat.

And then there's the third category, which is "threats which could be mitigated but PGP makes this hard so people tried and gave up." Just giving up entirely doesn't seem like the right reaction here, and that seems to be what the PGP downers are advocating.

codeguro4• 3 years ago

I disagree. As far as technicality goes, PGP is a pretty strong decentralized model. GnuPG is a pretty solid implementation of PGP.

Are they perfect? No. Do they merit this much criticism? Obviously not. This whole thing reads like an opinion piece criticizing implementation details and attributing it to the whole design. I did a spot check on the guy's authoritative sources and found them _extremely biased_, with one referring to an article disparaging DSA, who prefixes his technicals with "more important articles" arguing that white people somehow cannot experience racism even if they experienced racial prejudice. And they expect to be taken seriously? It's insanity.

But back to the technical aspect - _Of Course_ you should not use 1024-bi RSA or DSA keys. Of course you should choose prime numbers. If someone chooses to use a non-prime field you're going to have problems - that's not a problem with the PGP protocol or with RSA or DSA. If you're trusting public keys from complete strangers, _you're doing it wrong_. If you're not verifying that the fingerprint matches, _you're doing it wrong_.

For a journalist trying to report his findings in an unfriendly country to a secured third party, PGP is an excellent choice. For a client to secure communications with his lawyer, PGP is an excellent choice. And for anyone who would argue the contrary, I challenge them to forge a signature for the following identity. Go on, I dare you.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGRqTLABCADPc27v3wK4EhBAuoWn5GAVz15r/6osSf41eQ5W83dAmUp4IeIq bHLOvI44nVGiTUrawnpk1oHdOyZxthdo14KL0mplLTAWI0oYzcFClrhNOWa1cB5a K8ZYL0lwlM2YvhGQMaLzJKqEjO+JxLnqKIZeV9iYt9c16igvatVm37DP0NBVFF+V /58g3haNDjvQg4fPOvVIJ8SuIK1vPuTrb1ob2PLFBmHwwmzNGWfWHBBm6izxXZ85 ad56Rp/gca7j02qjnSE1X8S9s0OAJ6AAYRkWhtr/EUw3mjOjGSv32lFrsB7qvSu4 kEl/GY0PhcmnpSwi79vvva82fHZrvfKnbuoHABEBAAG0CUFub255bW91c4kBTgQT AQoAOBYhBNXzRmmKCQC9zIAegYhSrtq97HJWBQJkakywAhsDBQsJCAcCBhUKCQgL AgQWAgMBAh4BAheAAAoJEIhSrtq97HJWMUQIALwWlE1MyiL2vOjG3srY2m6gnE/p iDI9YzQECRr88R0CTSFOvGU8rFwwGNBavtMHfl9BJyJFVk82VK/mWCW7j37CJNu9 ObxqIuvZc35Op9G5LHlEFj/Hal4B3LqyIzm0Kb2IsY7HPMGNmLEQW8gw+PvkNJHr jaEF8eQ/vhboh+rxYn1COiAlBcxpHr3vvCtrsrlqhc1bPRb49ItJ5ybooDaLkl9T prHruCUzsCobYSiT7A85i6wwFvkICCIQZpPCR7cgVqyffjmjLlTPSWpu/+aCp1GP c6532MLqPGhEaFGrTWJzq9ApdQnbbNOt9kkMGCL1GLPGkPNQq0k2R0LNkmA= =A+3o

-----END PGP PUBLIC KEY BLOCK-----

Only I own this private key, and only I can sign with it. It's stored offline, secured and airgapped. It'd take more energy than there is on the planet to crack it. But I can easily prove I'm the owner. Trapdoor functions are a wonderful thing. If I were given your public key, and it _followed protocol_ and was a strong key, I'd be able secure communications to you in such a way _even I wouldn't be able to decrypt them_.

----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Go on, forge something. I'm waiting. -----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE1fNGaYoJAL3MgB6BiFKu2r3sclYFAmRqTYgACgkQiFKu2r3s clYdUAf+IBIVIxZ1tSbNsKc/Cay0f6weJwUxmr59v7Q/UNzDUcn468Ei0CO9WSVi klMob9uxBrnB9nGYeHcYULUxGZxAwbooQU8XDrE4x4btvARUaRgP0x+ikw6XY/1t N60SeHG9BVxL0EULrlQpNAbbBEQVk59jcKHTHQg8yTcKujw0DiBlJnmQTW5UOaoq UMJRKDBRJAOsrRBDLO2JjWRuFB8dhcVRNv5gqqPg+YyIdcsd/XQyXObyIyHznoAl gjyu9R8hi2Y0vrpNW8mniapDXsm09hOzpaMZqkNSGDRQJVLYWaUMJMs7epwKnL4z x3Virwk8u9NDj4NqjUmzaw2wpvI5iQ== =f62G

-----END PGP SIGNATURE-----

dale_glass14• 3 years ago

And what use is that? Here's your key:

    pub   rsa2048 2023-05-21 [SC]
          D5F346698A0900BDCC801E818852AEDABDEC7256
    uid           Anonymous

Why is that any more valid than any other key that says "Anonymous"? When you "prove" you own it, how would I know there's not MITM happening over the internet?

codeguro4• 3 years ago

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Its use is securing communications over an insecure channel. I can guarantee you that this message has not been tampered with in any way by HackerNews admins if the public key validates the signature of this message. If they have tried to tampered with it, the fact that they don't have the public key would demonstrate an invalid signature. So not only would you know if this message is really from me, you'd also know if it was tampered with.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE1fNGaYoJAL3MgB6BiFKu2r3sclYFAmRqepgACgkQiFKu2r3s clZ8YQgAkeR2l3eRGZdw0pKGYwO5H7ShqWeQrNK8O5lJVxUmQki+U43CJwlRmhrh iC8dPcSoiv+oXj6ziNxz4zgXnTNsb5OH2/lN7kMBEhsLjFNYMHxbaRfCWeznDrde uYzu0l5RqgTAL8fAxgIQ0smJuT9a8UDqzKmWO8N68nUG/L+aR0EfPb37MnTwXOk6 JGZFhKBEl4ZZ1Fq45YgGQNNX7jDerzxQG5Iu8pEZuVLi3g3d6CrgAEJhP865BjYX FPZ+IcalTkNH9x3IQ8E+QZXatu98mEPCOKLz0jbuJHAhH1TlKy0ya/vNVgVlstgj

9nl5ujnpkCsRn4iUZ+Iq+0vNOxkMbA==

=yisw

-----END PGP SIGNATURE-----

aborsy• 3 years ago

Sequoia PGP is pretty nice, but the issue is not so much the signature/encryption library, or even the interface, but the key management (after all, as far as the end users are concerned, PGP signing and encryption are simple commands). If this was easy, there would have been many solutions by now. Integration with a hardware-based KMS service will go a long way in improving the security. I don’t think the algorithm or file format is the main issue here.

zimmerfrei• 3 years 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.

lukeschlather4• 3 years ago

IIRC 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• 3 years ago

Surely the correct solution is having both parties sign the same artifact?

lukeschlather4• 3 years ago

It seems like the fundamental problem is that clients don't actually verify the signatures. It seems to me like the first step is pip and other clients should be updated to have a verify mode, and PyPy should start flagging packages that don't verify.

There are a lot of arguments in here that PGP is fundamentally broken, but it's a mature PKI system, and it seems to me like PyPy should stick with it and use it properly. If someone has a different PKI system that they think works better, by all means put together a PEP but "let's just do away with PKI because our implementation is half-assed and bad" doesn't really seem like a good path.

woodruffw16• 3 years ago

It’s PyPI, not PyPy. The latter is a Python implementation, not the package index.

Adding verification to pip makes the underlying problem worse: the keys themselves are weak and misconstructed, meaning that “verification” provides a false sense of security.

Finally: PGP is not a mature or successful PKI ecosystem, in any sense of either word. The only marginally successful PKI schemes using PGP are those in Linux distributions, and these benefit from constraints (trusted signer sets, baked in key deployment) that PyPI and other ecosystems can not provide.

lukeschlather4• 3 years ago

I'd argue that the benefit of package signing is only ever going to be marginal, but that's not a reason not to do it, it's a reason for PyPI to fix their processes.

Weak and misconstructed keys should cause the packages to fail to upload to PyPI. Obviously we can't just flip that switch today but that's the direction we should be thinking.

chha3• 3 years ago

This is a universal problem in most of package repositories regardless of language. PKI is difficult, and for it to work the users have to do some homework and place trust somewhere.

XorNot5• 3 years ago

In a healthier OSS ecosystem, we'd have people counter-signing packages after they've vetted them. If Google approves something through to production, then it's probably okay for you too.

This wouldn't be a bad extension to the GNU license really - requiring reciprocal review.

crabbone2• 3 years ago

You can already (and since a while ago) verify GPG signatures when installing Python packages.

Nobody does that. The biggest problem the author didn't really relate to is that most Python packages come with no signature what so ever. So, what are you going to do about those packages if you wanted to verify the rest? -- just verify those that have signatures, and leave those without signatures alone? -- That just sounds ridiculous...

By and large, PyPI is the same story we had with HTML: incompetence that breeds more incompetence. The same way how Web browsers encouraged crappy Web developers to generate ever more broken HTML by "helpfully" fixing the broken parts, PyPI by not enforcing the good practices created a community of people who now don't even understand what the problem is.

Fighting this is hopeless, because security is by far not the biggest reason why people download and use Python packages. So, even if security sucks, the users, who, ultimately should've been the ones responsible for their security won't do squat. Instead, maybe, at best, there'll be some broken / partial solution from PyPI.

donaldstufft9• 3 years ago

gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secure system on top of it.

They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.

hackan• 3 years ago

Indeed. I stopped using gpg for my packages, and started with minisign. Unfortunately, PyPi doesn't support any kind of metadata file, like a signature file, so I can't upload them :( Unless maybe u name it like a pgp file, but them u are hurting UX. Anyway, I simple upload them to my releases anyway, in Gitlab or Github.

remram• 3 years ago

I think the problem is always the same: there is a difference between verfying a library and verifying its authorship. PGP is made strictly to verify authors not artifacts.

If I have people I trust, I want to check whether they trust the library I'm about to download. In PGP like most web-of-trust solutions, what is checked is that they trust that the name of the author is correct. That does nothing for security. This is the same for sigstore, etc.

Other solutions like crev do the right thing, allowing people to assign trust into library releases, not just author's identities.

In PGP terms, it means I don't want PyPI to have PGP signatures from their author, so I can verify their author via my web-of-trust. I want PyPI to have PGP-signed reviews from people I trust, so I can trust the reviews.

greatgib• 3 years ago

I don't think that this complaint is completely meritless but I don't buy most of the arguments.

- keys not in a public keyserver?

Does not mean that the signature is useless.

- half of all keys used to sign on PyPI since 2020 are already expired.

In theory you can't easily sign with an expired key, so I guess what he means is that he found packages using expired keys, but not that the keys were expired at the time the package was signed/pushed. Since them it is normal and does not mean that it will not verify once you take the signature date into account.

I guess that it is heaven more common if you follow the good practice of a dedicated short life subkey of 2 years.

In my own personal experience, I already got reports of an user of my package asking if everything was ok because I accidentally signed a release with a wrong key.

Avamander5• 3 years ago

Does not mean that the signature is useless.

This has been discussed throughly in this and the previous thread. The gist is that without the public key being discoverable, it's not much more than a hash. Which makes it quite useless.

but not that the keys were expired at the time the package was signed/pushed.

We can't know that with PGP. There's no validity stapling showing that a key was valid (or invalid) during the time of signing. All we have is that at the time of verifying the signature it was invalid, thus it's generally useless/invalid.

This is further worsened by the fact that revocations (or extensions) are hard to have an up-to-date eye on, so you might be verifying a signature, finding it valid but they key had been already revoked. Yikes.

PGP signatures on PyPI: worse than useless

Related Stories