On Thu, Feb 01, 2018 at 11:14:50AM -0700, Jonathan Corbet wrote:
- Capitalizing "Kernel" bugs me. Obviously not a big deal.
Noted.
- 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.
I'll work that in for subsequent changes
- 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 :)
If we wanted to avoid this, one way would be to refer people to the "Protecting Code Integrity" guide for smartcard recommendations, though it uses slightly different criteria (Mac users suddenly become important).
- 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.
Linus isn't against it, he just points out that it serves no purpose -- the only thing that needs to be signed is the tip of each branch. Since each commit contains the parent checksum of the previous commit, that provides a backward chain for the rest of the branch, and that is sufficient to give cryptographic assurances for the remainder of all repo objects without needing to separately sign each of the commits leading to the tip.
And, of course, all those PGP signatures are lost when commits are converted to patches, so in his view the whole thing is pretty pointless. All he needs is signatures on tags that he pulls directly from maintainers.
However, there is currently no way to tell git "sign just the tip of the branch" -- I'm not even sure how it would work, because git has no knowledge of your intentions. A tip may only remain a tip for a couple of seconds before you add more commits. And should signatures be removed from previous commit tips, or just left there? And if so, why not just sign every commit anyway, since it doesn't *hurt* anything, especially if gpg-agent is properly configured -- it's just a background operation that doesn't even slow down your work if you use ECC subkeys.
Anyway, I feel it should remain as a weak recommendation just in case someone has to prove at any point their authorship of a specific commit, but I'm happy to change it, remove it, or add more detail explaining the above if you think the section should be expanded. I can talk about it for pages on end, I was just trying to be succinct. ;)
- I'm not quite sure what the "finding paths to Linus" link is supposed to do for the reader.
The idea is that it's a weak substitute for a web of trust. If someone isn't keeping one going, then using the PGP Pathfinder will give them at least *some* indication about whether the key is trusted or not. I do agree that if you don't already know what you're looking at, the output is fairly opaque. It's long been my desire to put together a kernel.org-specific tool where you can check similar data using pretty graphs (e.g. https://mricon.com/misc/korg-wot-graph.png), but I haven't had a chance yet.
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.
Will do, thank you for the feedback! -K
