Next steps for kernel workflow improvement

Posted Nov 25, 2019 22:49 UTC (Mon) by dkg (subscriber, #55359)
Parent article: Next steps for kernel workflow improvement

It's not clear to me what specific gain Ryabitsev hopes to get from moving from OpenPGP signatures to minisign signatures.

if the goal is small signatures, GnuPG (or any other OpenPGP implementation) using modern cryptography (e.g. Curve25519) produces a signature object that is about 119 octets. If you ASCII-armor it, it's up to 228 octets. None of this is even close to a quarter of the standard MTU, and barely noticeable among (for example) the Received: e-mail headers that will get attached to the message while it's in transit.

If the goal is simplicity, then mandating a specific profile of OpenPGP is the way to go -- the existing tooling already offers cryptographic validation, just tell people that they need to use Curve25519, and not the larger RSA keys. Modern elliptic curves have been available in gpg in Debian for years now (in stable since the release of debian 9 ("stretch") back in June 2017.

But perhaps the bigger questions are: who is verifying these signatures, at what stage, where are they recording these verifications, what do they do if the verifications are missing, how do we use these verifications going forward?

Are all patches going to need a cryptographic signature? If so, whose signatures will be acceptable? how is that tracked/changed over time?
Are we talking about replacing (or augmenting) Signed-off-by lines with cryptographic signatures? if so, we will need more work to streamline the process of accumulating multiple signatures on a commit, as well as thinking about what those signatures mean (do they break?) when a commit is rebased.
Are we talking about including the signatures in the official git repos, so that other people can review them, or are they simply for the mainline mergers to consider during their merge process?
Can we be sure that any given signed commit is actually relevant for the changes proposed for the kernel as opposed to a signature for a separate project entirely? Some of us work on multiple projects, and the fact that a commit happens to be signed on its own isn't necessarily sufficient to verify that the commit is authorized by the author to have it applied to a specific project.
Even if you have the signed commit scoped to a particular developer and a particular project, many features go through multiple revisions before being accepted into the mainline. Presumably each of those revisions would have been cryptographically signed by the author, despite the fact that each revision is expected to supercede the previous one. Surely the fact that you've found a signed commit from developer Alice addressing feature X on project foo doesn't mean that it represents the best revision that Alice prefers for feature X on project foo. There's no "take-backs" on a standard digital signature -- either for OpenPGP or for minisign that i'm aware of.

and so on…

None of these harder questions are affected by a proposal to switch from OpenPGP to minisign, as far as i can tell, and minisign adds an additional technical hurdle of deployment.

I should be clear: I'm a fan of moving to a cryptographically-strong attestation model. I'd love to see us as a community grapple with what that really means, and with what we want from it. I don't think that switching from OpenPGP to minisign addresses any of the deeper underlying issues, though, and it seems like it might be a distraction instead.