This series updates the guide to match terminology used in the upstream
"protecting code integrity" guide [1] and brings the documentation in
line with the latest developments in the GnuPG world:
- uses "Certify key" instead of "master key" terms to remove common
confusion that the "Certify key" is somehow able to restore lost
private subkeys
- removes keyserver instructions because keyservers have largely gone
semi-extinct due to GDPR enforcement and just general neglect
- adds a link to the kernel.org PGP keyring documentation
- updates information about ECC curve support among the devices the
guide talks about (Yubikeys are able to use ED25519 curves with the
latest firmware updates)
- adds a section on using PGP-signed patches with b4 and patatt
Signed-off-by: Konstantin Ryabitsev <[email protected]>
---
Konstantin Ryabitsev (5):
maintainer-pgp-guide: use key terminology consistent with upstream
maintainer-pgp-guide: remove keyserver instructions
maintainer-pgp-guide: update ECC support information
maintainer-pgp-guide: add a section on PGP-signed patches
maintainer-pgp-guide: minor wording tweaks
Documentation/process/maintainer-pgp-guide.rst | 287 ++++++++++++-------------
1 file changed, 142 insertions(+), 145 deletions(-)
---
base-commit: e0dccc3b76fb35bb257b4118367a883073d7390e
change-id: 20220727-docs-pgp-guide-1dfc91614c0f
Best regards,
--
Konstantin Ryabitsev <[email protected]>
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 <[email protected]>
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index cdd108f50fe7..01112ac7723e 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.
-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:
Protect your PGP key
@@ -228,11 +216,6 @@ separate signing subkey::
$ gpg --quick-addkey [fpr] ed25519 sign
-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
GnuPG 2.1 and later has full support for Elliptic Curve
@@ -906,65 +889,17 @@ the new default in GnuPG v2). To set it, add (or modify) the
trust-model tofu+pgp
-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 DA73759BF8619E484E5A3B47389A54219C0F2430
- gpg: issuer "[email protected]"
- 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 <[email protected]>
- 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
- Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(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 [email protected]
- pub rsa2048 2011-09-20 [SC]
- ABAF11C65A2970B130ABE3C479BE3E4300411886
- uid [ unknown] Linus Torvalds <[email protected]>
- 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 including
-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.html
--
b4 0.10.0-dev-49460
Tweak some wording to remove redundant information or fix spacing.
Signed-off-by: Konstantin Ryabitsev <[email protected]>
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index 2ce38e5d547d..ea74c87d09d8 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -265,9 +265,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.
Back up your whole GnuPG directory
----------------------------------
@@ -311,7 +309,7 @@ Remove the Certify key from your homedir
----------------------------------------
The files in our home directory are not as well protected as we like to
-think. They can be leaked or stolen via many different means:
+think. They can be leaked or stolen via many different means:
- by accident when making quick homedir copies to set up a new workstation
- by systems administrator negligence or malice
--
b4 0.10.0-dev-49460
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 <[email protected]>
diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
index 01112ac7723e..62b0bab5d7c5 100644
--- a/Documentation/process/maintainer-pgp-guide.rst
+++ b/Documentation/process/maintainer-pgp-guide.rst
@@ -227,11 +227,9 @@ separate signing subkey::
recommend that you create an ECC signing subkey for your kernel
work.
- 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."
Back up your Certify key for disaster recovery
@@ -437,7 +435,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.
`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
@@ -450,7 +449,7 @@ geographical region, and open/proprietary hardware considerations.
Foundation.
.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
-.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
+.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nkpr2-nitrokey-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/
--
b4 0.10.0-dev-49460
On 7/29/22 03:57, Konstantin Ryabitsev wrote:
> 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.
>
AFAIK, keyservers are synchronized (federated). For example, when I submit
my key to keys.openpgp.net, other keyservers (like keyserver.ubuntu.com
that I use) also gets a copy of my key. So "replacement systems" in
this case is referred to kernel.org key repository (using git). The
wording should be "Replace keyservers section with kernel.org public
key repository usage".
--
An old man doll... just what I always wanted! - Clara
On Thu, Jul 28, 2022 at 04:57:06PM -0400, Konstantin Ryabitsev wrote:
>
> - 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."
>
nistp256 isn't just ECC key algo other than ed25519. In fact, it is a
part of NIST curve family (the others are nistp384 and nistp521).
Maybe we can just say "If unsure, or if your hardware device does not
support ED25519, use one of NIST curves (nistp256, nistp384, or nistp521)
instead".
--
An old man doll... just what I always wanted! - Clara
On 7/28/22 13:57, Konstantin Ryabitsev wrote:
> Tweak some wording to remove redundant information or fix spacing.
>
> Signed-off-by: Konstantin Ryabitsev <[email protected]>
>
> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
> index 2ce38e5d547d..ea74c87d09d8 100644
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
> @@ -265,9 +265,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.
>
> Back up your whole GnuPG directory
> ----------------------------------
> @@ -311,7 +309,7 @@ Remove the Certify key from your homedir
> ----------------------------------------
>
> The files in our home directory are not as well protected as we like to
> -think. They can be leaked or stolen via many different means:
> +think. They can be leaked or stolen via many different means:
One or 2 spaces after a period is one of the things that we historically
don't care about (can go either way).
Along with use the serial comma and British/American spellings.
>
> - by accident when making quick homedir copies to set up a new workstation
> - by systems administrator negligence or malice
>
--
~Randy
Hallo Konstantin,
Am Thu, Jul 28, 2022 at 04:57:03PM -0400 schrieb Konstantin Ryabitsev:
> This series updates the guide to match terminology used in the upstream
> "protecting code integrity" guide [1] and brings the documentation in
> line with the latest developments in the GnuPG world:
I could not find [1]. Did you miss to add the footnote?
Greets
Alex
> - uses "Certify key" instead of "master key" terms to remove common
> confusion that the "Certify key" is somehow able to restore lost
> private subkeys
> - removes keyserver instructions because keyservers have largely gone
> semi-extinct due to GDPR enforcement and just general neglect
> - adds a link to the kernel.org PGP keyring documentation
> - updates information about ECC curve support among the devices the
> guide talks about (Yubikeys are able to use ED25519 curves with the
> latest firmware updates)
> - adds a section on using PGP-signed patches with b4 and patatt
>
> Signed-off-by: Konstantin Ryabitsev <[email protected]>
>
> ---
> Konstantin Ryabitsev (5):
> maintainer-pgp-guide: use key terminology consistent with upstream
> maintainer-pgp-guide: remove keyserver instructions
> maintainer-pgp-guide: update ECC support information
> maintainer-pgp-guide: add a section on PGP-signed patches
> maintainer-pgp-guide: minor wording tweaks
>
> Documentation/process/maintainer-pgp-guide.rst | 287 ++++++++++++-------------
> 1 file changed, 142 insertions(+), 145 deletions(-)
> ---
> base-commit: e0dccc3b76fb35bb257b4118367a883073d7390e
> change-id: 20220727-docs-pgp-guide-1dfc91614c0f
>
> Best regards,
> --
> Konstantin Ryabitsev <[email protected]>
On Tue, Aug 02, 2022 at 11:07:21AM +0200, Alexander Dahl wrote:
> Hallo Konstantin,
>
> Am Thu, Jul 28, 2022 at 04:57:03PM -0400 schrieb Konstantin Ryabitsev:
> > This series updates the guide to match terminology used in the upstream
> > "protecting code integrity" guide [1] and brings the documentation in
> > line with the latest developments in the GnuPG world:
>
> I could not find [1]. Did you miss to add the footnote?
I did. I'll send a follow-up v2. The footnote was supposed to be to the
following URL:
[1]: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
-K
On Fri, Jul 29, 2022 at 04:11:26PM +0700, Bagas Sanjaya wrote:
> > - 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."
> >
>
> nistp256 isn't just ECC key algo other than ed25519. In fact, it is a
> part of NIST curve family (the others are nistp384 and nistp521).
>
> Maybe we can just say "If unsure, or if your hardware device does not
> support ED25519, use one of NIST curves (nistp256, nistp384, or nistp521)
> instead".
Hm... ED25519 is the default for GnuPG 2.3+, so I'm not sure it makes sense to
go into this level of detail here. Folks who are likely to need to use NIST
curves will probably already know this information without needing to list it
in this guide. As far as I can recall, TPMs and older Nitrokey Pros are some
of the few remaining devices that can't do ed25519, so the number of people
who would need to use NIST curves will likely be super small.
-K
On Fri, Jul 29, 2022 at 08:47:02AM +0700, Bagas Sanjaya wrote:
> On 7/29/22 03:57, Konstantin Ryabitsev wrote:
> > 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.
> >
>
> AFAIK, keyservers are synchronized (federated).
This is only the case for the keyserver network that has to the large degree
gone dark. The few remaining keyservers are either configured to be
non-federating (pgp.mit.edu, afaik), or written without that feature in the
first place (keys.openpgp.org).
> For example, when I submit
> my key to keys.openpgp.net, other keyservers (like keyserver.ubuntu.com
> that I use) also gets a copy of my key.
I would be very much susprised if that's the case (unless the ubuntu keyserver
pulls updates from keys.openpgp.org). Last I looked, hagrid-keyserver did not
support replication/federation.
-K
On Fri, Jul 29, 2022 at 03:55:45PM -0700, Randy Dunlap wrote:
> > The files in our home directory are not as well protected as we like to
> > -think. They can be leaked or stolen via many different means:
> > +think. They can be leaked or stolen via many different means:
>
> One or 2 spaces after a period is one of the things that we historically
> don't care about (can go either way).
Hm... I didn't know that applied within the context of a single file. Anyway,
I'm happy to drop this change -- pretty sure it's only there because my vim is
configured to replace ". " with ". " on "gq" operations.
-K