Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 30 Aug 2019 10:30:27 -0400
From:   Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To:     linux-kernel@vger.kernel.org
Subject: Distributing kernel developer PGP keys via pgpkeys.git
Message-ID: <20190830143027.cffqda2vzggrtiko@chatter.i7.local>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="d433sdinoctmgvmm"
Content-Disposition: inline
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--d433sdinoctmgvmm
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi, all:

As you may be aware, the SKS keyserver network has been very unreliable=20
lately due to two general factors:

- a large number of SKS servers were shut down in the past year or so=20
  due to GDPR compliance concerns (as designed, SKS is not compliant and=20
  cannot be made compliant)
- the recent signature poisoning attack generated general distrust of=20
  the keyserver network, so people have been avoiding submitting key=20
  updates to the keyservers, resulting in keyserver data becoming=20
  increasingly stale
- the web of trust concept is seen as an obsolete concept because it=20
  doesn't scale to the whole of the internet, so there is little=20
  motivation for anyone to fix the keyserver problem

This has caused an issue for the kernel development community, since=20
many do rely on the PGP web of trust when performing such actions like=20
checking PGP signatures on git tags found in pull requests. A=20
significant number of developers have also been increasingly relying on=20
kernel.org to maintain the Web Key Directory (WKD), which now acts as a=20
certifying authority.

Unfortunately, if we abandon the web of trust completely, we will have=20
to go back to relying on kernel.org infrastructure as the source of=20
trust. Kernel.org has been hacked in the past -- ever since then our=20
goal has always been to keep developers as the sole and only source of=20
truth. This requirement is why we cannot and should not abandon the=20
developer web of trust and must keep it going, at least in parallel to=20
the WKD and similar efforts.

I've investigated a bunch of keyserver/key distribution options=20
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=20
  vulnerable to DoS attacks via signature poisoning.
- Hagrid (keys.openpgp.org): strips 3rd-party signatures, so cannot be=20
  used for WoT purposes (also, it requires a Rust nightly build to run).
- Web Key Submission (WKS): strips both 3rd-party signatures and any=20
  UIDs that aren't @kernel.org -- so while we will offer it as a way to=20
  publish key updates, it is neither sufficient for Linux development=20
  (not all developers have kernel.org accounts), nor is useful for WoT=20
  maintenance purposes.

So, we are going to do something similar to Debian's keyring package --=20
I will maintain a git repository of developer keys and everyone=20
interested will be able to pull and refresh from that repository.

Here's what is already done:

- the repository is available here:=20
  https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
- it provides both .asc exports of individual keys and handy graphs to=20
  see each key's trust paths to Linus (done with wotmate, see=20
  https://git.kernel.org/pub/scm/utils/korg/wotmate.git)
- it additionally provides a korg-refresh-keys script that can be run=20
  either manually or from cron to automatically refresh updated keys
- any 3rd-party signatures from keys not present in the repo are=20
  stripped during export
- to submit key updates, send an ascii-armoured key export to=20
  keys@linux.kernel.org, which is currently processed manually, but=20
  we'll be adding automation to streamline the process
- the keys submission archive is available on=20
  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 keys@linux.kernel.org to add pre-validation via=20
  one of the key's UIDs (e.g. via requiring a valid signature of a=20
  specific nonce)
- add automatic notifications of key expiry with instructions of how to=20
  extend expiry dates and resubmit
- add automatic tracking of additions to the MAINTAINERS file so new=20
  people can be auto-spammed to send their keys to keys@linux.kernel.org

As you can see, this project is still young, so if you have any=20
improvement recommendations, please feel free to let me know.

Best regards,
-K

--d433sdinoctmgvmm
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXWkzAQAKCRC2xBzjVmSZ
bL0OAP4uEEF1JWWmjTgedDCVh8f1VDapdqZ+fTQj+5o5HPdtSgEA12++Ekwj1X3T
5F2MnwKV42n+P+odt4uqbCx0hkMbsAc=
=qr9m
-----END PGP SIGNATURE-----

--d433sdinoctmgvmm--