FS#63147 - [gnupg] 2.2.17 release is broken by design and breaks pacman
Attached to Project:
Arch Linux
Opened by Eli Schwartz (eschwartz) - Wednesday, 10 July 2019, 17:09 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 11 July 2019, 16:55 GMT
Opened by Eli Schwartz (eschwartz) - Wednesday, 10 July 2019, 17:09 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 11 July 2019, 16:55 GMT
|
Details
From the changelog:
gpg: Ignore all key-signatures received from keyservers. This change is required to mitigate a DoS due to keys flooded with faked key-signatures. The old behaviour can be achieved by adding keyserver-options no-self-sigs-only,no-import-clean to your gpg.conf. [T4607] This DoS has been known for many, many years, but as soon as it becomes a dramatic headline all of a sudden it needs to be "fixed". The consequences of trying to import one of the few flooded keys (so far it seems to basically be two keys that were flooded as a proof-of-concept to show that the issue is "serious") is that gnupg hangs. The consequence of actually trying to use the new gnupg version is that the entire web of trust is neutered and stripped away, unless you use options to (drumroll) revert back to the original behavior. This is problematic due to the fact that often we need the web of trust, and one of the things that will break as a result of this is pacman-key. By default, pacman itself will try to look up keys which it does not know about yet, and download them with the master key signatures in order to validate signed packages/repositories. Arch Linux relies on this heavily to ensure that users do not suffer signature errors for packages signed by new members of the packaging team (or current packagers with updated keys via pacman-key -r), during the transition time before an updated archlinux-keyring package is released. Until the ramifications of this change are understood, and affected programs like pacman are patched to revert the behavior via gpg.conf, we should not let this package migrate to core. Even then, I strongly suggest a post_upgrade warning be implemented to prevent silently breaking user workflows. |
This task depends upon
Closed by Gaetan Bisson (vesath)
Thursday, 11 July 2019, 16:55 GMT
Reason for closing: Fixed
Additional comments about closing: gnupg-2.2.17-2 in [testing]
Thursday, 11 July 2019, 16:55 GMT
Reason for closing: Fixed
Additional comments about closing: gnupg-2.2.17-2 in [testing]
The simplest solution for the time being seems to be making `keyserver-options no-self-sigs-only,no-import-clean` the default behavior.
I'll try to find the time to implement this in the coming days but if anyone else beats me to it or thinks of a better solution, all the better! Cheers.
That doesn't answer the IMO questionable usability problem for non-pacman consumers which is posed by the politics of this change.
The GnuPG changeset that toggled this is https://dev.gnupg.org/rG2b7151b0a57f5fe7d67fd76dfa1ba7a8731642c6 which seems like it would be easy to revert, but reverting the behavior does have the downside of playing politics with the upstream sources. I'd feel more comfortable if they had provided official mechanisms for configuring the old or new behavior, so it might be a good idea to start a dialogue with the GnuPG devs about this.
Then we have a bit of time to figure out what to do. As you suggest, pacman may wish to impose certain options to better control the gnupg profile it uses, but I concur this does not answer the underlying issue which is that gnupg appears to be growingly unsuitable for a web-of-trust key distribution model. I'd like to wait and see what other distros do, since we're far from being the only ones using gnupg for signing packages. Waiting is also convenient for me as I'm on vacation with little Internet access for yet another month. If nothing has moved when I get back I'll get in touch with the GnuPG crowd to ask where they see all this going for our use case. If anyone from Arch wants to get in touch with them and propose a solution before I come back, that's fine too. Cheers.