| Age | Commit message (Collapse) | Author |
|---|
|
It is finally becoming increasingly rare to find a distribution that
still ships with gnupg-1.x, so remove the last vestiges of "gpg" vs
"gpg2" from documentation.
Similarly, starting with GnuPG 2.2 and above, the default --gen-key
operation creates ed25519/cv25519 keypairs, so update all example
command outputs to use that combination instead of rsa2048.
Lastly, add a few wording tweaks and remove links that lead to stale
information (e.g. hardware tokens overview from 2017).
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20221220-docs-pgp-guide-v1-1-9b0c0bf974fb@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Tweak some wording to remove redundant information.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220727-docs-pgp-guide-v2-5-e3e6954affb6@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220727-docs-pgp-guide-v2-4-e3e6954affb6@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220727-docs-pgp-guide-v2-3-e3e6954affb6@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220727-docs-pgp-guide-v2-2-e3e6954affb6@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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 <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220727-docs-pgp-guide-v2-1-e3e6954affb6@linuxfoundation.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
finder
PGP pathfinder[1], which is suggested for finding a trust path to
unknown PGP keys by 'maintainer-pgp-guide.rst', is not working now.
This commit replaces it with other available tools.
[1] https://pgp.cs.uu.nl/
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210812095030.4704-2-sj38.park@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Link: https://lore.kernel.org/r/20200621133630.46435-1-grandmaster@al2klimov.de
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Newer devices like Yubikey 5 and Nitrokey Pro 2 have added support for
NISTP's implementation of ECC cryptography, so update the guide
accordingly and add a note on when to use nistp256 and when to use
ed25519 for generating S keys.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Fix typo in the GPG guide for maintainers
Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
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>
|
|
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 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>
|
