From nobody Sat Apr 11 17:01:49 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FD8AC25B0D for ; Mon, 8 Aug 2022 21:32:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244393AbiHHVcH (ORCPT ); Mon, 8 Aug 2022 17:32:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238069AbiHHVcE (ORCPT ); Mon, 8 Aug 2022 17:32:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91B0FDFB8; Mon, 8 Aug 2022 14:32:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CD73C60EFC; Mon, 8 Aug 2022 21:32:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2B99C433C1; Mon, 8 Aug 2022 21:32:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1659994322; bh=CkFamQElMBdW/Xk/iv1dKAw5mdgxBh9BRwVx32FpGJI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=eWbYrGQKRn+/0f9GiAuFn7ZfmRm2Z7wwcpM/GHuA00OgHsWeNBirXCHmt81YV8alP AC4un/zyrjCjeiNHJVjl9q4FzmPMfXE6UjeQhBqG7UQUTm2bpEhQdLR+a+rEKVvjN1 fdFdbV+pfYPtg86fSMT987uV63SZGyhUgk2WhzDE= From: Konstantin Ryabitsev Date: Mon, 08 Aug 2022 17:31:49 -0400 Subject: [PATCH v2 1/5] maintainer-pgp-guide: use key terminology consistent with upstream MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20220727-docs-pgp-guide-v2-1-e3e6954affb6@linuxfoundation.org> References: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> In-Reply-To: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org X-Mailer: b4 0.10.0-dev-fe10a X-Developer-Signature: v=1; a=openpgp-sha256; l=11348; i=konstantin@linuxfoundation.org; h=from:subject:message-id; bh=CkFamQElMBdW/Xk/iv1dKAw5mdgxBh9BRwVx32FpGJI=; b=owGbwMvMwCW27YjM47CUmTmMp9WSGJI+Nly0qv46cetyAdbcENPcX6xSFaU39m9+fvz2yj8/LGtl V1zP7yhlYRDjYpAVU2Qp2xe7KajwoYdceo8pzBxWJpAhDFycAjAR3okM/8wmR5/LNHgSkFex9Xfwvv 68XA+bOjPblBsaTvP2SsV1vmRkuLRBeIHG3tQ43aw3j5+b+F2qDAn9ZmZ8NfFYRd7Nmivs3AA= X-Developer-Key: i=konstantin@linuxfoundation.org; a=openpgp; fpr=DE0E66E32F1FDD0902666B96E63EDCA9329DD07E Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org GnuPG does not use the word "master key" when referring to the subkey marked with the "certification" capability. Our use of this term was not only inconsistent, but also misleading, because in real life "master keys" are able to open multiple locks made for different keys, while PGP Certify key has no such capability. Signed-off-by: Konstantin Ryabitsev diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation= /process/maintainer-pgp-guide.rst index 29e7d7b1cd44..7dada4eaedca 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -133,45 +133,56 @@ daily cronjob:: Check the full path to your ``gpg`` or ``gpg2`` command and use the ``gpg2`` command if regular ``gpg`` for you is the legacy GnuPG v.1. =20 -.. _master_key: +.. _protect_your_key: =20 -Protect your master PGP key -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D +Protect your PGP key +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 This guide assumes that you already have a PGP key that you use for Linux kernel development purposes. If you do not yet have one, please see the "`Protecting Code Integrity`_" document mentioned earlier for guidance on how to create a new one. =20 -You should also make a new key if your current one is weaker than 2048 bits -(RSA). - -Master key vs. Subkeys ----------------------- - -Subkeys are fully independent PGP keypairs that are tied to the "master" -key using certifying key signatures (certificates). It is important to -understand the following: - -1. There are no technical differences between the "master key" and "subkey= s." -2. At creation time, we assign functional limitations to each key by - giving it specific capabilities. -3. A PGP key can have 4 capabilities: - - - **[S]** key can be used for signing - - **[E]** key can be used for encryption - - **[A]** key can be used for authentication - - **[C]** key can be used for certifying other keys - -4. A single key may have multiple capabilities. -5. A subkey is fully independent from the master key. A message - encrypted to a subkey cannot be decrypted with the master key. If you - lose your private subkey, it cannot be recreated from the master key - in any way. - -The key carrying the **[C]** (certify) capability is considered the -"master" key because it is the only key that can be used to indicate -relationship with other keys. Only the **[C]** key can be used to: +You should also make a new key if your current one is weaker than 2048 +bits (RSA). + +Understanding PGP Subkeys +------------------------- + +A PGP key rarely consists of a single keypair -- usually it is a +collection of independent subkeys that can be used for different +purposes based on their capabilities, assigned at their creation time. +PGP defines four capabilities that a key can have: + +- **[S]** keys can be used for signing +- **[E]** keys can be used for encryption +- **[A]** keys can be used for authentication +- **[C]** keys can be used for certifying other keys + +The key with the **[C]** capability is often called the "master" key, +but this terminology is misleading because it implies that the Certify +key can be used in place of any of other subkey on the same chain (like +a physical "master key" can be used to open the locks made for other +keys). Since this is not the case, this guide will refer to it as "the +Certify key" to avoid any ambiguity. + +It is critical to fully understand the following: + +1. All subkeys are fully independent from each other. If you lose a + private subkey, it cannot be restored or recreated from any other + private key on your chain. +2. With the exception of the Certify key, there can be multiple subkeys + with identical capabilities (e.g. you can have 2 valid encryption + subkeys, 3 valid signing subkeys, but only one valid certification + subkey). All subkeys are fully independent -- a message encrypted to + one **[E]** subkey cannot be decrypted with any other **[E]** subkey + you may also have. +3. A single subkey may have multiple capabilities (e.g. your **[C]** key + can also be your **[S]** key). + +The key carrying the **[C]** (certify) capability is the only key that +can be used to indicate relationship with other keys. Only the **[C]** +key can be used to: =20 - add or revoke other keys (subkeys) with S/E/A capabilities - add, change or revoke identities (uids) associated with the key @@ -180,7 +191,7 @@ relationship with other keys. Only the **[C]** key can = be used to: =20 By default, GnuPG creates the following when generating new keys: =20 -- A master key carrying both Certify and Sign capabilities (**[SC]**) +- One subkey carrying both Certify and Sign capabilities (**[SC]**) - A separate subkey with the Encryption capability (**[E]**) =20 If you used the default parameters when generating your key, then that @@ -192,9 +203,6 @@ for example:: uid [ultimate] Alice Dev ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23] =20 -Any key carrying the **[C]** capability is your master key, regardless -of any other capabilities it may have assigned to it. - The long line under the ``sec`` entry is your key fingerprint -- whenever you see ``[fpr]`` in the examples below, that 40-character string is what it refers to. @@ -215,9 +223,9 @@ strong passphrase. To set it or change it, use:: Create a separate Signing subkey -------------------------------- =20 -Our goal is to protect your master key by moving it to offline media, so -if you only have a combined **[SC]** key, then you should create a separate -signing subkey:: +Our goal is to protect your Certify key by moving it to offline media, +so if you only have a combined **[SC]** key, then you should create a +separate signing subkey:: =20 $ gpg --quick-addkey [fpr] ed25519 sign =20 @@ -230,8 +238,8 @@ your new subkey:: =20 GnuPG 2.1 and later has full support for Elliptic Curve Cryptography, with ability to combine ECC subkeys with traditional - RSA master keys. The main upside of ECC cryptography is that it is - much faster computationally and creates much smaller signatures when + RSA keys. The main upside of ECC cryptography is that it is much + faster computationally and creates much smaller signatures when compared byte for byte with 2048+ bit RSA keys. Unless you plan on using a smartcard device that does not support ECC operations, we recommend that you create an ECC signing subkey for your kernel @@ -244,8 +252,8 @@ your new subkey:: "nistp256" instead or "ed25519." =20 =20 -Back up your master key for disaster recovery ---------------------------------------------- +Back up your Certify key for disaster recovery +---------------------------------------------- =20 The more signatures you have on your PGP key from other developers, the more reasons you have to create a backup version that lives on something @@ -300,7 +308,7 @@ will use for backup purposes. You will need to encrypt = them using LUKS -- refer to your distro's documentation on how to accomplish this. =20 For the encryption passphrase, you can use the same one as on your -master key. +PGP key. =20 Once the encryption process is over, re-insert the USB drive and make sure it gets properly mounted. Copy your entire ``.gnupg`` directory @@ -319,7 +327,7 @@ far away, because you'll need to use it every now and a= gain for things like editing identities, adding or revoking subkeys, or signing other people's keys. =20 -Remove the master key from your homedir +Remove the Certify key from your homedir ---------------------------------------- =20 The files in our home directory are not as well protected as we like to @@ -334,7 +342,7 @@ think. They can be leaked or stolen via many different= means: Protecting your key with a good passphrase greatly helps reduce the risk of any of the above, but passphrases can be discovered via keyloggers, shoulder-surfing, or any number of other means. For this reason, the -recommended setup is to remove your master key from your home directory +recommended setup is to remove your Certify key from your home directory and store it on offline storage. =20 .. warning:: @@ -343,7 +351,7 @@ and store it on offline storage. your GnuPG directory in its entirety. What we are about to do will render your key useless if you do not have a usable backup! =20 -First, identify the keygrip of your master key:: +First, identify the keygrip of your Certify key:: =20 $ gpg --with-keygrip --list-key [fpr] =20 @@ -359,7 +367,7 @@ The output will be something like this:: Keygrip =3D 3333000000000000000000000000000000000000 =20 Find the keygrip entry that is beneath the ``pub`` line (right under the -master key fingerprint). This will correspond directly to a file in your +Certify key fingerprint). This will correspond directly to a file in your ``~/.gnupg`` directory:: =20 $ cd ~/.gnupg/private-keys-v1.d @@ -369,13 +377,13 @@ master key fingerprint). This will correspond directl= y to a file in your 3333000000000000000000000000000000000000.key =20 All you have to do is simply remove the .key file that corresponds to -the master keygrip:: +the Certify key keygrip:: =20 $ cd ~/.gnupg/private-keys-v1.d $ rm 1111000000000000000000000000000000000000.key =20 Now, if you issue the ``--list-secret-keys`` command, it will show that -the master key is missing (the ``#`` indicates it is not available):: +the Certify key is missing (the ``#`` indicates it is not available):: =20 $ gpg --list-secret-keys sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] @@ -404,7 +412,7 @@ file, which still contains your private keys. Move the subkeys to a dedicated crypto device =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -Even though the master key is now safe from being leaked or stolen, the +Even though the Certify key is now safe from being leaked or stolen, the subkeys are still in your home directory. Anyone who manages to get their hands on those will be able to decrypt your communication or fake your signatures (if they know the passphrase). Furthermore, each time a @@ -627,10 +635,10 @@ Other common GnuPG operations Here is a quick reference for some common operations you'll need to do with your PGP key. =20 -Mounting your master key offline storage -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Mounting your safe offline storage +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 -You will need your master key for any of the operations below, so you +You will need your Certify key for any of the operations below, so you will first need to mount your backup offline storage and tell GnuPG to use it:: =20 @@ -644,7 +652,7 @@ your regular home directory location). Extending key expiration date ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 -The master key has the default expiration date of 2 years from the date +The Certify key has the default expiration date of 2 years from the date of creation. This is done both for security reasons and to make obsolete keys eventually disappear from keyservers. =20 --=20 b4 0.10.0-dev-fe10a From nobody Sat Apr 11 17:01:49 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C7F3C25B08 for ; Mon, 8 Aug 2022 21:32:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238378AbiHHVcK (ORCPT ); Mon, 8 Aug 2022 17:32:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244025AbiHHVcF (ORCPT ); Mon, 8 Aug 2022 17:32:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4AFB1836E; Mon, 8 Aug 2022 14:32:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 618FF60F40; Mon, 8 Aug 2022 21:32:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 843AAC433B5; Mon, 8 Aug 2022 21:32:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1659994322; bh=sPldY5OOK0lFXoqD+bbxVQOlfH0Oqs80plXbsIzeR9w=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=B5I15c/dWoLtGLxHhvS2ExxITF/WoTYpULPDVs89KRar3yiWS1ZGFA3wns3af3fdv vP+bofpb+0jBEvs8G1/5kFF43PL27ey6w4i8qGkoUji9S1V9IYy6QvqcyzRp77WyOv WVDQMJ+q7sqql7ZJNh5gBbmFpQbBfoEm+9DtVMm8= From: Konstantin Ryabitsev Date: Mon, 08 Aug 2022 17:31:50 -0400 Subject: [PATCH v2 2/5] maintainer-pgp-guide: remove keyserver instructions MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20220727-docs-pgp-guide-v2-2-e3e6954affb6@linuxfoundation.org> References: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> In-Reply-To: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org X-Mailer: b4 0.10.0-dev-fe10a X-Developer-Signature: v=1; a=openpgp-sha256; l=5444; i=konstantin@linuxfoundation.org; h=from:subject:message-id; bh=sPldY5OOK0lFXoqD+bbxVQOlfH0Oqs80plXbsIzeR9w=; b=owGbwMvMwCW27YjM47CUmTmMp9WSGJI+NlyS3nft2897+xfOuCIuP4n/KOf6J9/FtmpGsBmquVrs WLRJs6OUhUGMi0FWTJGlbF/spqDChx5y6T2mMHNYmUCGMHBxCsBEYuIZ/ilMKU1X319w+tO9aR2MR2 ZMsAgIU81ULv2UZsLP8Pf81PcMfzjWFtnVxh7z/JXkLD61ZU1ViPWy2xX8i8MKr7JIc0t8ZgEA X-Developer-Key: i=konstantin@linuxfoundation.org; a=openpgp; fpr=DE0E66E32F1FDD0902666B96E63EDCA9329DD07E Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Keyservers are largely a thing of the past with the replacement systems like keys.openpgp.net specifically designed to offer no support for the web of trust. Remove all sections that talk about keyservers and add a small section with the link to kernel.org documentation that talks about using the kernel.org public key repository. Signed-off-by: Konstantin Ryabitsev diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation= /process/maintainer-pgp-guide.rst index 7dada4eaedca..ead5bc815017 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -121,18 +121,6 @@ edit your ``~/.gnupg/gpg-agent.conf`` file to set your= own values:: to remove anything you had in place for older versions of GnuPG, as it may not be doing the right thing any more. =20 -Set up a refresh cronjob -~~~~~~~~~~~~~~~~~~~~~~~~ - -You will need to regularly refresh your keyring in order to get the -latest changes on other people's public keys, which is best done with a -daily cronjob:: - - @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1 - -Check the full path to your ``gpg`` or ``gpg2`` command and use the -``gpg2`` command if regular ``gpg`` for you is the legacy GnuPG v.1. - .. _protect_your_key: =20 Protect your PGP key @@ -229,11 +217,6 @@ separate signing subkey:: =20 $ gpg --quick-addkey [fpr] ed25519 sign =20 -Remember to tell the keyservers about this change, so others can pull down -your new subkey:: - - $ gpg --send-key [fpr] - .. note:: ECC support in GnuPG =20 GnuPG 2.1 and later has full support for Elliptic Curve @@ -907,65 +890,17 @@ the new default in GnuPG v2). To set it, add (or modi= fy) the =20 trust-model tofu+pgp =20 -How to use keyservers (more) safely ------------------------------------ - -If you get a "No public key" error when trying to validate someone's -tag, then you should attempt to lookup that key using a keyserver. It is -important to keep in mind that there is absolutely no guarantee that the -key you retrieve from PGP keyservers belongs to the actual person -- -that much is by design. You are supposed to use the Web of Trust to -establish key validity. - -How to properly maintain the Web of Trust is beyond the scope of this -document, simply because doing it properly requires both effort and -dedication that tends to be beyond the caring threshold of most human -beings. Here are some shortcuts that will help you reduce the risk of -importing a malicious key. - -First, let's say you've tried to run ``git verify-tag`` but it returned -an error saying the key is not found:: - - $ git verify-tag sunxi-fixes-for-4.15-2 - gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST - gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F= 2430 - gpg: issuer "wens@...org" - gpg: Can't check signature: No public key - -Let's query the keyserver for more info about that key fingerprint (the -fingerprint probably belongs to a subkey, so we can't use it directly -without finding out the ID of the master key it is associated with):: - - $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430 - gpg: data source: hkp://keys.gnupg.net - (1) Chen-Yu Tsai - 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires:= 2019-03-15 - Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter n= umber(s), N)ext, or Q)uit > q - -Locate the ID of the master key in the output, in our example -``C94035C21B4F2AEB``. Now display the key of Linus Torvalds that you -have on your keyring:: - - $ gpg --list-key torvalds@kernel.org - pub rsa2048 2011-09-20 [SC] - ABAF11C65A2970B130ABE3C479BE3E4300411886 - uid [ unknown] Linus Torvalds - sub rsa2048 2011-09-20 [E] - -Next, find a trust path from Linus Torvalds to the key-id you found via ``= gpg ---search`` of the unknown key. For this, you can use several tools includ= ing -https://github.com/mricon/wotmate, -https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, and -https://the.earth.li/~noodles/pathfind.html. - -If you get a few decent trust paths, then it's a pretty good indication -that it is a valid key. You can add it to your keyring from the -keyserver now:: - - $ gpg --recv-key C94035C21B4F2AEB - -This process is not perfect, and you are obviously trusting the -administrators of the PGP Pathfinder service to not be malicious (in -fact, this goes against :ref:`devs_not_infra`). However, if you -do not carefully maintain your own web of trust, then it is a marked -improvement over blindly trusting keyservers. +Using the kernel.org web of trust repository +-------------------------------------------- + +Kernel.org maintains a git repository with developers' public keys as a +replacement for replicating keyserver networks that have gone mostly +dark in the past few years. The full documentation for how to set up +that repository as your source of public keys can be found here: + +- `Kernel developer PGP Keyring`_ + +If you are a kernel developer, please consider submitting your key for +inclusion into that keyring. + +.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.h= tml --=20 b4 0.10.0-dev-fe10a From nobody Sat Apr 11 17:01:49 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F182C00140 for ; Mon, 8 Aug 2022 21:32:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244452AbiHHVcS (ORCPT ); Mon, 8 Aug 2022 17:32:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244376AbiHHVcG (ORCPT ); Mon, 8 Aug 2022 17:32:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5100F1AF3B; Mon, 8 Aug 2022 14:32:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E1A0660F42; Mon, 8 Aug 2022 21:32:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1465AC43470; Mon, 8 Aug 2022 21:32:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1659994323; bh=A9375CUslLLzBRLppAdcbV4Xp1zIhYndjn1o38kpK1g=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=q2KimLvmGjOhrLqaD/MyhdxHcr+y8RMhSbHJ86OqE5ngLOocAuY4z2c00upcLnKGb xfd038hMY7DdKpO/dE6buQe6mJSffEPGTSt88Cp4cEOpDljlTbO4lnx7EV+gsIE1Ik 9Z6TGGz3qa0IwI6IPRRWmyHjDWtKyIGOiRqBkgyw= From: Konstantin Ryabitsev Date: Mon, 08 Aug 2022 17:31:51 -0400 Subject: [PATCH v2 3/5] maintainer-pgp-guide: update ECC support information MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20220727-docs-pgp-guide-v2-3-e3e6954affb6@linuxfoundation.org> References: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> In-Reply-To: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org X-Mailer: b4 0.10.0-dev-fe10a X-Developer-Signature: v=1; a=openpgp-sha256; l=2325; i=konstantin@linuxfoundation.org; h=from:subject:message-id; bh=A9375CUslLLzBRLppAdcbV4Xp1zIhYndjn1o38kpK1g=; b=owGbwMvMwCW27YjM47CUmTmMp9WSGJI+NlyqvxCoHf36snKgX/lN68mqgdelf2n6bGQzVvdN2p+z lndmRykLgxgXg6yYIkvZvthNQYUPPeTSe0xh5rAygQxh4OIUgIm8y2dkOBAe/aOFL9I3/8Q0tbUTJX JDowSlvTkntryoPnlMj0XxE8N/55z7756nR3RGJM9lZhc0PnbB6WRWZez2jofPRYxsX/7lBQA= X-Developer-Key: i=konstantin@linuxfoundation.org; a=openpgp; fpr=DE0E66E32F1FDD0902666B96E63EDCA9329DD07E Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update ECC sections with the latest details, now that Yubikeys are able to support ED25519 curves. Tweak a few links to smartcard devices to reflect the latest URL changes. Signed-off-by: Konstantin Ryabitsev diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation= /process/maintainer-pgp-guide.rst index ead5bc815017..bf288925973e 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -228,11 +228,9 @@ separate signing subkey:: recommend that you create an ECC signing subkey for your kernel work. =20 - If for some reason you prefer to stay with RSA subkeys, just replace - "ed25519" with "rsa2048" in the above command. Additionally, if you - plan to use a hardware device that does not support ED25519 ECC - keys, like Nitrokey Pro or a Yubikey, then you should use - "nistp256" instead or "ed25519." + Note, that if you plan to use a hardware device that does not + support ED25519 ECC keys, you should choose "nistp256" instead or + "ed25519." =20 =20 Back up your Certify key for disaster recovery @@ -438,7 +436,8 @@ functionality. There are several options available: - `Yubikey 5`_: proprietary hardware and software, but cheaper than Nitrokey Pro and comes available in the USB-C form that is more useful with newer laptops. Offers additional security features such as FIDO - U2F, among others, and now finally supports ECC keys (NISTP). + U2F, among others, and now finally supports NISTP and ED25519 ECC + keys. =20 `LWN has a good review`_ of some of the above models, as well as several others. Your choice will depend on cost, shipping availability in your @@ -451,7 +450,7 @@ geographical region, and open/proprietary hardware cons= iderations. Foundation. =20 .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-star= t-6 -.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-= 2-3 +.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nkpr2-nitroke= y-pro-2-3 .. _`Yubikey 5`: https://www.yubico.com/products/yubikey-5-overview/ .. _Gnuk: https://www.fsij.org/doc-gnuk/ .. _`LWN has a good review`: https://lwn.net/Articles/736231/ --=20 b4 0.10.0-dev-fe10a From nobody Sat Apr 11 17:01:49 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC860C00140 for ; Mon, 8 Aug 2022 21:32:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244470AbiHHVc1 (ORCPT ); Mon, 8 Aug 2022 17:32:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244385AbiHHVcG (ORCPT ); Mon, 8 Aug 2022 17:32:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8B4E1AF3D; Mon, 8 Aug 2022 14:32:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6F2DC60F39; Mon, 8 Aug 2022 21:32:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9969AC433D7; Mon, 8 Aug 2022 21:32:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1659994323; bh=MlTGunZJ9ulhMIP2HxaX8CXCaBRqtCKdfkBycK+w3YU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=YuEmZnMFsvyqX09mlUc8JXh9jtoKsGmFlgHulh21vj4eOrTtDXAj0n0naLN+fOwKv x1P4fpDeQ0a+tM6pefvjgeSzyC3dwHaH39ketXto26BHHHuvIH4OIHZWhC+FvLRNa5 d3iQ5DM82nfP4DdVbmbsn5rR/8GCDvQ3Nnl+xv7U= From: Konstantin Ryabitsev Date: Mon, 08 Aug 2022 17:31:52 -0400 Subject: [PATCH v2 4/5] maintainer-pgp-guide: add a section on PGP-signed patches MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20220727-docs-pgp-guide-v2-4-e3e6954affb6@linuxfoundation.org> References: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> In-Reply-To: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org X-Mailer: b4 0.10.0-dev-fe10a X-Developer-Signature: v=1; a=openpgp-sha256; l=3027; i=konstantin@linuxfoundation.org; h=from:subject:message-id; bh=MlTGunZJ9ulhMIP2HxaX8CXCaBRqtCKdfkBycK+w3YU=; b=owGbwMvMwCW27YjM47CUmTmMp9WSGJI+NlzuEFlhf/FF18sf8vZv8vTu5nUtsswKrexPlVkak5fH E2bcUcrCIMbFICumyFK2L3ZTUOFDD7n0HlOYOaxMIEMYuDgFYCK25xgZznzTXBuoqCv4eBNbo3fnpz fyVRcnSSm35q61Tbzz5kvBPkaGnRvSCuqrrjSeE7HlDNSomu+Vrnzk7kme0rrqerU/BptZAQ== X-Developer-Key: i=konstantin@linuxfoundation.org; a=openpgp; fpr=DE0E66E32F1FDD0902666B96E63EDCA9329DD07E Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With more developers beginning to use b4 and patatt, add a section to the guide that talks about setting up and using patatt for PGP-signing patch submissions. Signed-off-by: Konstantin Ryabitsev diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation= /process/maintainer-pgp-guide.rst index bf288925973e..27c42762edd7 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -675,6 +675,7 @@ remote end. =20 .. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding =20 +.. _pgp_with_git: =20 Using PGP with Git =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -818,6 +819,63 @@ You can tell git to always sign commits:: =20 .. _verify_identities: =20 + +How to work with signed patches +------------------------------- + +It is possible to use your PGP key to sign patches sent to kernel +developer mailing lists. Since existing email signature mechanisms +(PGP-Mime or PGP-inline) tend to cause problems with regular code +review tasks, you should use the tool kernel.org created for this +purpose that puts cryptographic attestation signatures into message +headers (a-la DKIM): + +- `Patatt Patch Attestation`_ + +.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/ + +Installing and configuring patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Patatt is packaged for many distributions already, so please check there +first. You can also install it from pypi using "``pip install patatt``". + +If you already have your PGP key configured with git (via the +``user.signingKey`` configuration parameter), then patatt requires no +further configuration. You can start signing your patches by installing +the git-send-email hook in the repository you want:: + + patatt install-hook + +Now any patches you send with ``git send-email`` will be automatically +signed with your cryptographic signature. + +Checking patatt signatures +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you are using ``b4`` to retrieve and apply patches, then it will +automatically attempt to verify all DKIM and patatt signatures it +encounters, for example:: + + $ b4 am 20220720205013.890942-1-broonie@kernel.org + [...] + Checking attestation on all messages, may take a moment... + --- + =E2=9C=93 [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation = for SVE Z registers + =E2=9C=93 [PATCH v1 2/3] arm64/sve: Document our actual ABI for clea= ring registers on syscall + =E2=9C=93 [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE= syscalls + --- + =E2=9C=93 Signed: openpgp/broonie@kernel.org + =E2=9C=93 Signed: DKIM/kernel.org + +.. note:: + + Patatt and b4 are still in active development and you should check + the latest documentation for these projects for any new or updated + features. + +.. _kernel_identities: + How to verify kernel developer identities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 b4 0.10.0-dev-fe10a From nobody Sat Apr 11 17:01:49 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32E75C25B08 for ; Mon, 8 Aug 2022 21:32:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244462AbiHHVcY (ORCPT ); Mon, 8 Aug 2022 17:32:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244374AbiHHVcF (ORCPT ); Mon, 8 Aug 2022 17:32:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C70F1B780; Mon, 8 Aug 2022 14:32:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 942E660F46; Mon, 8 Aug 2022 21:32:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28925C433D6; Mon, 8 Aug 2022 21:32:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1659994324; bh=xJhW7d248iritQ4ymw3QmYT6FjZI7Ec9pUmutSBZaCs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=lo01OUoa00XM8QNR3I3/DoTyrHcvhaacj2U/5fAQu9NHvzaYPpXeSQ7YBhVDpYS29 1k8l+0xsgIV8x7vlC2DLUm5TE02qEENXv/+Fl/X0QkBJTKEV4ONzl3XkLxe5au+0u4 mO1JwpMDf1OQqTTw7M6WDqUZtXJoQV297VRAB7H0= From: Konstantin Ryabitsev Date: Mon, 08 Aug 2022 17:31:53 -0400 Subject: [PATCH v2 5/5] maintainer-pgp-guide: minor wording tweaks MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20220727-docs-pgp-guide-v2-5-e3e6954affb6@linuxfoundation.org> References: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> In-Reply-To: <20220727-docs-pgp-guide-v2-0-e3e6954affb6@linuxfoundation.org> To: Jonathan Corbet Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org X-Mailer: b4 0.10.0-dev-fe10a X-Developer-Signature: v=1; a=openpgp-sha256; l=991; i=konstantin@linuxfoundation.org; h=from:subject:message-id; bh=xJhW7d248iritQ4ymw3QmYT6FjZI7Ec9pUmutSBZaCs=; b=owGbwMvMwCW27YjM47CUmTmMp9WSGJI+NlyZ8j756aPovvZvE3uf9Tns/FLgmfXvDEsGlxj3PTFn O6n+jlIWBjEuBlkxRZayfbGbggofesil95jCzGFlAhnCwMUpABO52cjIcEfhpdb3y+ldndVxN1fpva tyb204Mk1huZDKfK7GOkWHDYwM676vvyGcNunVlx07lVtmPK2WuM99PN715PrCKb8EJSZEcwMA X-Developer-Key: i=konstantin@linuxfoundation.org; a=openpgp; fpr=DE0E66E32F1FDD0902666B96E63EDCA9329DD07E Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tweak some wording to remove redundant information. Signed-off-by: Konstantin Ryabitsev diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation= /process/maintainer-pgp-guide.rst index 27c42762edd7..40bfbd3b7648 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -266,9 +266,7 @@ home, such as your bank vault. Your printer is probably no longer a simple dumb device connected to your parallel port, but since the output is still encrypted with your passphrase, printing out even to "cloud-integrated" modern - printers should remain a relatively safe operation. One option is to - change the passphrase on your master key immediately after you are - done with paperkey. + printers should remain a relatively safe operation. =20 Back up your whole GnuPG directory ---------------------------------- --=20 b4 0.10.0-dev-fe10a