On Thu, 1 Feb 2018 09:42:33 -0500 Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote:
> 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 <konstan...@linuxfoundation.org> OK, I've been through all of this. Naturally, I have a few quibbles: - Capitalizing "Kernel" bugs me. Obviously not a big deal. - The "master keys vs. subkeys" section is nice, but it's missing one thing, IMO: a sentence saying what a subkey *is* in the first place. - We don't normally endorse commercial products in kernel docs. OTOH, I don't see any other way for people to know which keycards they should get. This section is sure to go obsolete as products come and go, though - you're on the hook for maintaining it :) - The suggestion to sign individual commits is, as I understand it, controversial (Linus doesn't agree with it) and is 100% contrary to current practice. Are there any signed commits in the kernel repo now? Given that, I'm a bit nervous about putting commit-signing forward as standard practice. - I'm not quite sure what the "finding paths to Linus" link is supposed to do for the reader. Anyway, these are all quibbles, and I think the documentation is definitely improved by having this, so I'm going ahead and applying it. It may be worth considering some tweaks for the issues above, though, as time allows. Thanks, jon
