p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Documentation/process: tweak pgp maintainer guide 

Based on the feedback provided:

- Uniformly use lowercase k in "Linux kernel"
- Give a one-sentence explanation of what subkeys are
- Explain what signed commits might be useful for even if upstream
  developers do not use them for much of anything
- Admonish to set up gpg-agent if signed commits are turned on in
  git config
- Fix a typo reported by Luc Van Oostenryck

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Konstantin Ryabitsev 2018-02-06 11:51:19 -05:00 committed by Jonathan Corbet
parent 54e36a2dc5
commit 78ed784519
1 changed files with 33 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
Documentation/process/maintainer-pgp-guide.rst
View File

@ -18,10 +18,10 @@ The role of PGP in Linux Kernel development
===========================================
PGP helps ensure the integrity of the code that is produced by the Linux
Kernel development community and, to a lesser degree, establish trusted
kernel development community and, to a lesser degree, establish trusted
communication channels between developers via PGP-signed email exchange.
The Linux Kernel source code is available in two main formats:
The Linux kernel source code is available in two main formats:
- Distributed source repositories (git)
- Periodic release snapshots (tarballs)
@ -53,7 +53,7 @@ want to make sure that by placing trust into developers we do not simply
shift the blame for potential future security incidents to someone else.
The goal is to provide a set of guidelines developers can use to create
a secure working environment and safeguard the PGP keys used to
establish the integrity of the Linux Kernel itself.
establish the integrity of the Linux kernel itself.
.. _pgp_tools:
@ -139,7 +139,7 @@ Protect your master PGP key
===========================
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
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.
@ -149,7 +149,9 @@ You should also make a new key if your current one is weaker than 2048 bits
Master key vs. Subkeys
----------------------
It is important to understand the following:
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 "subkeys."
2. At creation time, we assign functional limitations to each key by
@ -742,17 +744,29 @@ How to work with signed commits
-------------------------------
It is easy to create signed commits, but it is much more difficult to
use them in Linux Kernel development, since it relies on patches sent to
use them in Linux kernel development, since it relies on patches sent to
the mailing list, and this workflow does not preserve PGP commit
signatures.
signatures. Furthermore, when rebasing your repository to match
upstream, even your own PGP commit signatures will end up discarded. For
this reason, most kernel developers don't bother signing their commits
and will ignore signed commits in any external repositories that they
rely upon in their work.
If you have your working git tree publicly available at some git hosting
service (kernel.org, infradead.org, ozlabs.org, or others), then the
recommendation is that you sign all your git commits even if upstream
developers do not directly benefit from this practice. Should there ever
be a need to perform code forensics or track code provenance, even
externally maintained trees carrying PGP commit signatures will be
extremely valuable for such purposes.
However, if you have your working git tree publicly available at some
git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
then the recommendation is that you sign all your git commits even if
upstream developers do not directly benefit from this practice.
We recommend this for the following reasons:
1. Should there ever be a need to perform code forensics or track code
provenance, even externally maintained trees carrying PGP commit
signatures will be valuable for such purposes.
2. If you ever need to re-clone your local repository (for example,
after a disk failure), this lets you easily verify the repository
integrity before resuming your work.
3. If someone needs to cherry-pick your commits, this allows them to
quickly verify their integrity before applying them.
Creating signed commits
~~~~~~~~~~~~~~~~~~~~~~~
@ -770,6 +784,10 @@ You can tell git to always sign commits::
git config --global commit.gpgSign true
.. note::
Make sure you configure ``gpg-agent`` before you turn this on.
.. _verify_identities:
How to verify kernel developer identities
@ -882,7 +900,7 @@ 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::
$ git --list-key torvalds@kernel.org
$ gpg --list-key torvalds@kernel.org
pub rsa2048 2011-09-20 [SC]
ABAF11C65A2970B130ABE3C479BE3E4300411886
uid [ unknown] Linus Torvalds <torvalds@kernel.org>