Hi, all:
As you may be aware, the SKS keyserver network has been very unreliable
lately due to two general factors:
- a large number of SKS servers were shut down in the past year or so
due to GDPR compliance concerns (as designed, SKS is not compliant and
cannot be made compliant)
- the recent signature poisoning attack generated general distrust of
the keyserver network, so people have been avoiding submitting key
updates to the keyservers, resulting in keyserver data becoming
increasingly stale
- the web of trust concept is seen as an obsolete concept because it
doesn't scale to the whole of the internet, so there is little
motivation for anyone to fix the keyserver problem
This has caused an issue for the kernel development community, since
many do rely on the PGP web of trust when performing such actions like
checking PGP signatures on git tags found in pull requests. A
significant number of developers have also been increasingly relying on
kernel.org to maintain the Web Key Directory (WKD), which now acts as a
certifying authority.
Unfortunately, if we abandon the web of trust completely, we will have
to go back to relying on kernel.org infrastructure as the source of
trust. Kernel.org has been hacked in the past -- ever since then our
goal has always been to keep developers as the sole and only source of
truth. This requirement is why we cannot and should not abandon the
developer web of trust and must keep it going, at least in parallel to
the WKD and similar efforts.
I've investigated a bunch of keyserver/key distribution options
available today and none of the current ones offer what we need to do:
- SKS: hasn't been maintained in 15+ years, isn't and cannot be made
GDPR-compliant, is written in a quaint implementation of OCaml, and is
vulnerable to DoS attacks via signature poisoning.
- Hagrid (keys.openpgp.org): strips 3rd-party signatures, so cannot be
used for WoT purposes (also, it requires a Rust nightly build to run).
- Web Key Submission (WKS): strips both 3rd-party signatures and any
UIDs that aren't @kernel.org -- so while we will offer it as a way to
publish key updates, it is neither sufficient for Linux development
(not all developers have kernel.org accounts), nor is useful for WoT
maintenance purposes.
So, we are going to do something similar to Debian's keyring package --
I will maintain a git repository of developer keys and everyone
interested will be able to pull and refresh from that repository.
Here's what is already done:
- the repository is available here:
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
- it provides both .asc exports of individual keys and handy graphs to
see each key's trust paths to Linus (done with wotmate, see
https://git.kernel.org/pub/scm/utils/korg/wotmate.git)
- it additionally provides a korg-refresh-keys script that can be run
either manually or from cron to automatically refresh updated keys
- any 3rd-party signatures from keys not present in the repo are
stripped during export
- to submit key updates, send an ascii-armoured key export to
[email protected], which is currently processed manually, but
we'll be adding automation to streamline the process
- the keys submission archive is available on
https://lore.kernel.org/keys/ for historical purposes
- see the README.rst file for more info on these topics:
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/README.rst
Here's what is left to be done:
- add automation around [email protected] to add pre-validation via
one of the key's UIDs (e.g. via requiring a valid signature of a
specific nonce)
- add automatic notifications of key expiry with instructions of how to
extend expiry dates and resubmit
- add automatic tracking of additions to the MAINTAINERS file so new
people can be auto-spammed to send their keys to [email protected]
As you can see, this project is still young, so if you have any
improvement recommendations, please feel free to let me know.
Best regards,
-K