Commit Graph

3 Commits

Author SHA1 Message Date
Konstantin Ryabitsev
1ba2211c52 Documentation/process: updates to the PGP guide
Small tweaks to the Maintainer PGP guide:

 - Use --quick-addkey command that is compatible between GnuPG-2.2 and
   GnuPG-2.1 (which many people still have)
 - Add a note about the Nitrokey program
 - Warn that some devices can't change the passphrase before there are
   keys on the card (specifically, Nitrokeys)
 - Link to the GnuPG wiki page about gpg-agent forwarding over ssh
 - Tell git to use gpgv2 instead of legacy gpgv when verifying signed
   tags or commits

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-04-16 14:03:50 -06:00
Konstantin Ryabitsev
78ed784519 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>
2018-02-06 16:31:56 -07:00
Konstantin Ryabitsev
b72dde3869 Documentation/process: kernel maintainer PGP guide
This guide is an adapted version of the more general "Protecting Code
Integrity" guide written and maintained by The Linux Foundation IT for
use with open-source projects. It provides the oft-lacking guidance on
the following topics:

- how to properly protect one's PGP keys to minimize the risks of them
  being stolen and used maliciously to impersonate a kernel developer
- how to configure Git to properly use GnuPG
- when and how to use PGP with Git
- how to verify fellow Linux Kernel developer identities

I believe this document should live with the rest of the documentation
describing proper processes one should follow when participating in
kernel development. Placing it in a wiki on some place like kernel.org
would be insufficient for a number of reasons -- primarily, because only
a relatively small subset of maintainers have accounts on kernel.org,
but also because even those who do rarely remember that such wiki
exists. Keeping it with the rest of in-kernel docs should hopefully give
it more visibility, but also help keep it up-to-date as tools and
processes evolve.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2018-02-01 10:58:19 -07:00