6 ms·

So they examined everything uploaded to PyPi with a signature over three years, including old versions, and classify those packages whose signing key is expired

So they examined everything uploaded to PyPi with a signature over three years, including old versions, and classify those packages whose signing key is expired today, possibly years later, as "impossible to meaningfully verify." Never mind that the package may have been verifiable with a valid key for a full year or two before the key expired, and in the meantime may have been superseded by a newer version. They also say they can't "meaningfully verify" packages if the key does not have "binding identify information," by which they presumably mean automatically verifiable binding identity information, which usually means someone verified an email from keys.openpgp.org. This is a really narrow way to establish "binding identity information." For example someone who is a PyPi author and publicly links their PGP key from a (https) website on the same domain as the email on the key would not count. A well known longtime PyPi author with a well known key would not count. The ad hoc, out of band nature of how PGP keys are trusted is not remotely new - PyPi would have known from the very start of adopting PGP that many keys would not be automatically verifiable. It makes little sense to turn around now and act like this is some surprising thing. This has the smell of "we didn't want to bother supporting PGP any more because it's hard so we came up with an excuse." No need for an excuse, though: Just be honest about it and let the chips fall where they may, if you really don't want to support PGP. God knows there are valid reasons for not having the energy to deal with PGP. (FWIW I think it's a good solution for packages, for those who can navigate the tooling, but on the other hand I'm not volunteering my time to run PyPi.) P.S. There is a link in their post saying PGP has "documented issues." The specific issue described in the linked document is "packaging signing is not the holy grail" and a list of known things about PGP, like that verification of keys is ad hoc. It also concludes that there is no known better alternative.

tptacek 3y ago
There are much, much better solutions for packaging!
- c0l0 3y ago
  And which of those are in use/available at the Python Package Index?
  - tptacek 3y ago
    I don't know, but PGP isn't either, so the comparison holds.
- 5e92cb50239222b 3y ago
  Like signify (developed and adopted by OpenBSD) and minisign. AFAIK Debian has been working on abandoning GPG in favor of something very similar to those two. Not sure when it's going to be shipped, though. https://wiki.debian.org/Teams/Apt/Spec/AptSign https://wiki.debian.org/Teams/Apt/Spec/AptSign
- eduction 3y ago
  Which you do not describe, but set that aside: A post that honestly said "we do not like PGP, but here is our alternate plan" would be great. On an actual better solution, I don't think anyone has proposed a good one. Here is the closest I've seen from PyPi (or at least linked from this post as describing their thinking), from 10 years ago: "Everything is Terrible So What Do We Do? Bluntly put, I don’t know for sure. This isn’t an already solved problem nor is it an easy to solve one." https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/ https://caremad.io/posts/2013/07/packaging-signing-not-holy-... What I'll say on PGP is the perfect is the enemy of the good. It's not a tech anyone has much fun using, but in a group setting, used regularly, I have found it can fade into the background at least. I don't want to go any further down the "is PGP good or bad" rabbit hole than that. But if you have a better solution for package security, please do describe it here.
  - tptacek 3y ago
    It's not really up to you or me, it's up to PyPI. For my part: their logic seems pretty sound.
  - donaldstufft 3y ago
    The current documented plans revolve around TUF (https://peps.python.org/pep-0458/ https://peps.python.org/pep-0458/, https://peps.python.org/pep-0480/ https://peps.python.org/pep-0480/). Those links have probably bit rotted a bit by now, progress has been slow on implementing them for a number of reasons (mostly OSS reasons, volunteers etc). There's also a general consensus (not documented) that sigstore will play some kind of role here. Possibly in-toto as well? In the 10 years since my post that you referenced, we've laid some decent plans I believe, and have just slowly been working on them, to the extent that we've been able to given our own time constraints.
woodruffw 3y ago
> The ad hoc, out of band nature of how PGP keys are trusted is not remotely new - PyPi would have known from the very start of adopting PGP that many keys would not be automatically verifiable. It makes little sense to turn around now and act like this is some surprising thing. This is revisionist: in 2005, PGP was approachingly modern and represented an acceptable tradeoff between usability, legal and patent constraints, and arms laws. It was also accompanied by a network of synchronizing keyservers and a "strong set" within the Web of Trust that, in principle, gave you transitive authenticity for artifacts. That never really worked as expected, but it's all code and infrastructure that was actually running in 2005, when PyPI chose to allow PGP signatures. None of that is the case in 2023: PGP is 20 years behind cryptographic best practices, and has 30 years of unresolved technical debt. There is no web of trust, and the synchronizing keyserver network has been broken for years. The argument for PGP in 2005 was that it was, to a first approximation, the best that could be done. The argument against PGP in 2023 is that, to a first approximation, it's worse than useless by virtue of providing false security guarantees.
- eduction 3y ago
  There wasn't any sign or promise in 2005 (that I'm aware of, and I had a key back then) that PGP would soon get meaningfully better, for example that it would suddenly, magically solve the issue of verifying keys in a decentralized system. It was a pain in the arse then as now. There has been some improvement in the meantime, in that keys.openpgp.org started unilaterally doing its own email verification. And you say that it's been 18 years and PGP is behind best practices, but you don't describe how those best practices would better solve the package verification challenge that PyPi faces. So in the absence of an actual alternative system why not keep using PGP? Perfect is the enemy of good (IMO!). But again, I'm not even really feeling strongly that PyPi should use PGP or not. I mostly posted just to say that they should be honest about why they are leaving it, and these seem like bad/misleading stats that for some reason they are hiding behind instead of coming out and saying they changed their mind about PGP (or new people are now running things and don't like dealing with PGP - many people would sympathize).
  - woodruffw 3y ago

tptacek 3y ago

There are much, much better solutions for packaging!

c0l0 3y ago
And which of those are in use/available at the Python Package Index?
- tptacek 3y ago
  I don't know, but PGP isn't either, so the comparison holds.
5e92cb50239222b 3y ago
Like signify (developed and adopted by OpenBSD) and minisign. AFAIK Debian has been working on abandoning GPG in favor of something very similar to those two. Not sure when it's going to be shipped, though. https://wiki.debian.org/Teams/Apt/Spec/AptSign https://wiki.debian.org/Teams/Apt/Spec/AptSign
eduction 3y ago
Which you do not describe, but set that aside: A post that honestly said "we do not like PGP, but here is our alternate plan" would be great. On an actual better solution, I don't think anyone has proposed a good one. Here is the closest I've seen from PyPi (or at least linked from this post as describing their thinking), from 10 years ago: "Everything is Terrible So What Do We Do? Bluntly put, I don’t know for sure. This isn’t an already solved problem nor is it an easy to solve one." https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/ https://caremad.io/posts/2013/07/packaging-signing-not-holy-... What I'll say on PGP is the perfect is the enemy of the good. It's not a tech anyone has much fun using, but in a group setting, used regularly, I have found it can fade into the background at least. I don't want to go any further down the "is PGP good or bad" rabbit hole than that. But if you have a better solution for package security, please do describe it here.
- tptacek 3y ago
  It's not really up to you or me, it's up to PyPI. For my part: their logic seems pretty sound.
- donaldstufft 3y ago
  The current documented plans revolve around TUF (https://peps.python.org/pep-0458/ https://peps.python.org/pep-0458/, https://peps.python.org/pep-0480/ https://peps.python.org/pep-0480/). Those links have probably bit rotted a bit by now, progress has been slow on implementing them for a number of reasons (mostly OSS reasons, volunteers etc). There's also a general consensus (not documented) that sigstore will play some kind of role here. Possibly in-toto as well? In the 10 years since my post that you referenced, we've laid some decent plans I believe, and have just slowly been working on them, to the extent that we've been able to given our own time constraints.

woodruffw 3y ago

> The ad hoc, out of band nature of how PGP keys are trusted is not remotely new - PyPi would have known from the very start of adopting PGP that many keys would not be automatically verifiable. It makes little sense to turn around now and act like this is some surprising thing. This is revisionist: in 2005, PGP was approachingly modern and represented an acceptable tradeoff between usability, legal and patent constraints, and arms laws. It was also accompanied by a network of synchronizing keyservers and a "strong set" within the Web of Trust that, in principle, gave you transitive authenticity for artifacts. That never really worked as expected, but it's all code and infrastructure that was actually running in 2005, when PyPI chose to allow PGP signatures. None of that is the case in 2023: PGP is 20 years behind cryptographic best practices, and has 30 years of unresolved technical debt. There is no web of trust, and the synchronizing keyserver network has been broken for years. The argument for PGP in 2005 was that it was, to a first approximation, the best that could be done. The argument against PGP in 2023 is that, to a first approximation, it's worse than useless by virtue of providing false security guarantees.

eduction 3y ago
There wasn't any sign or promise in 2005 (that I'm aware of, and I had a key back then) that PGP would soon get meaningfully better, for example that it would suddenly, magically solve the issue of verifying keys in a decentralized system. It was a pain in the arse then as now. There has been some improvement in the meantime, in that keys.openpgp.org started unilaterally doing its own email verification. And you say that it's been 18 years and PGP is behind best practices, but you don't describe how those best practices would better solve the package verification challenge that PyPi faces. So in the absence of an actual alternative system why not keep using PGP? Perfect is the enemy of good (IMO!). But again, I'm not even really feeling strongly that PyPi should use PGP or not. I mostly posted just to say that they should be honest about why they are leaving it, and these seem like bad/misleading stats that for some reason they are hiding behind instead of coming out and saying they changed their mind about PGP (or new people are now running things and don't like dealing with PGP - many people would sympathize).
- woodruffw 3y ago