Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63171 - Use a Web Key Directory (WKD) to publish package signing keys

Attached to Project: Arch Linux
Opened by Jonas Witschel (diabonas) - Friday, 12 July 2019, 11:05 GMT
Last edited by Allan McRae (Allan) - Friday, 12 July 2019, 11:36 GMT
Task Type Feature Request
Category Web Sites
Status Assigned
Assigned To Allan McRae (Allan)
Florian Pritz (bluewind)
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

To verify package signatures, pacman currently uses the SKS keyserver network to fetch unknown PGP keys or to refresh expired keys. This keyserver network has recently been attacked by spamming some high-profile keys with so many signatures that they can't be imported any more into GnuPG [1]. If one of the Arch Linux developer keys were spammed in this way, it would break the keyring of users running "pacman-key --refresh-keys" or that don't have this key in their local keyring yet. It is unclear how likely such an attack is, but since the Tor Browser Developers signing key is also affected [2], there seem to be some attackers intent on breaking as many user keyrings as possible, making the Arch Linux developers a possible target as well.

To overcome this problem, I suggest hosting the package signing keys in a trustworthy, read-only location to where such an attack is impossible. While it is possible to host a dedicated keyserver for this purpose, this is a relatively complex process that requires running additional server software. Instead I recommend hosting the keys in a Web Key Directory (WKD) [3]: this is simply a static list of files in a well-known directory of a server from where they can be retrieved using GnuPG. Setting up such a directory is as easy as running [4]

export GNUPGHOME=/etc/pacman.d/gnupg/
gpg --list-options show-only-fpr-mbox -k '@archlinux.org' | /usr/lib/gnupg/gpg-wks-client -v --install-key

and then copying the ./openpgpkey/archlinux.org/hu/ directory to the Arch Linux server, serving it as https://openpgpkey.archlinux.org/.well-known/openpgpkey/archlinux.org/hu/.

No further maintenance apart from occasionally adding new keys or refreshing expired ones is needed. Other projects like kernel.org [5], Debian [6] or Gentoo [7] are also using a WKD to publish their keys.

After this is implemented, the next step is to change pacman to lookup keys using WKD first (falling back to the keyservers if no key is found this way). This requires changes to "lib/libalpm/signing.c" (replacing "GPGME_KEYLIST_MODE_EXTERN" by "GPGME_KEYLIST_MODE_LOCATE"), "scripts/pacman-key.sh.in" (replacing "--search-keys" by "--locate-key") and possibly other places. I am happy to provide appropriate patches, but I think the WKD should be set up first so that the changes can be properly tested.

[1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
[2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f#gistcomment-2959168
[3] https://wiki.gnupg.org/WKD
[4] https://wiki.gnupg.org/WKDHosting
[5] https://www.kernel.org/doc/html/latest/process/maintainer-pgp-guide.html
[6] https://dkg.fifthhorseman.net/blog/wkd-for-debian.org.html
[7] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html
This task depends upon

Comment by Allan McRae (Allan) - Friday, 12 July 2019, 11:39 GMT
Assigning to devops for the setup of the WKD. Ping it back to the pacman project once it is set up.

Comment by Levente Polyak (anthraxx) - Friday, 12 July 2019, 12:16 GMT Comment by Eli Schwartz (eschwartz) - Friday, 12 July 2019, 13:20 GMT
If I understand correctly, this only helps us publish keys that use an @archlinux.org uid for lookup (and in $PACKAGER). Which is still useful, but I think that we may need some changes to the TU admission process (that is, the administrivium portion) as well for full effect.
Comment by Jonas Witschel (diabonas) - Friday, 12 July 2019, 13:42 GMT
Correct, WKD works with email addresses instead of key fingerprints for lookup, so for pacman-key needs to lookup the @archlinux.org UIDs in the keyring and refresh these, for new key discovery pacman needs to extract the email address from the packager field and do a lookup with that. Putting everything in place will certainly take a while, but I think it is wise to start the process now when nothing bad has happened yet. The idea would be to keep the keyserver lookup as a fallback for problematic packages and keys, but getting WKD set up to a point where we can pull the plug on keyserver lookup if the need should arise.
Comment by Pol Van Aubel (MacGyver) - Friday, 12 July 2019, 13:54 GMT
If signatures are made using --local-user (-u) with an @archlinux.org UID, the UID is added to the signature and the WKD lookup should, according to the manpage, automatically resolve. There is no need for that UID to actually be e-mail-backed, but it would require all signers to add such a UID to the key they use for signing. (I haven't tested this because I'm not running a WKD myself (yet)). There would then be no need for pacman to implement key discovery based on the packager-field, but it does require the currently used tooling to be changed to include this UID in all future signatures.

Loading...