summaryrefslogtreecommitdiffstats
path: root/Documentation/process/maintainer-pgp-guide.rst (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Documentation/process: updates to the PGP guideKonstantin Ryabitsev2018-04-161-2/+37
| | | | | | | | | | | | | | | | 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>
* Documentation/process: tweak pgp maintainer guideKonstantin Ryabitsev2018-02-071-16/+34
| | | | | | | | | | | | | | | 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>
* Documentation/process: kernel maintainer PGP guideKonstantin Ryabitsev2018-02-011-0/+911
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>