archive mirror
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <>
Subject: Distributing kernel developer PGP keys via pgpkeys.git
Date: Fri, 30 Aug 2019 10:30:27 -0400	[thread overview]
Message-ID: <20190830143027.cffqda2vzggrtiko@chatter.i7.local> (raw)

[-- Attachment #1: Type: text/plain, Size: 4173 bytes --]

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 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 infrastructure as the source of 
trust. 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 ( 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 -- so while we will offer it as a way to 
  publish key updates, it is neither sufficient for Linux development 
  (not all developers have 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:
- it provides both .asc exports of individual keys and handy graphs to 
  see each key's trust paths to Linus (done with wotmate, see
- 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, which is currently processed manually, but 
  we'll be adding automation to streamline the process
- the keys submission archive is available on for historical purposes
- see the README.rst file for more info on these topics:

Here's what is left to be done:

- add automation around 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

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,

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

                 reply	other threads:[~2019-08-30 14:30 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190830143027.cffqda2vzggrtiko@chatter.i7.local \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).