Hello, all:

This is a very "raw" idea that stems from a handful of conversations
that took place at the Kernel Summit. I wanted to pass it along to this
list in hopes that it can generate some workable ideas (or shot down and
allowed to die early).

# Problem

One of the recurring concerns raised by kernel developers is the fact
that email-based patch workflow offers no git-native mechanism of
cryptographic integrity attestation. In other words, the only mechanism
for someone to verify that patch contents have not been altered is
via PGP-signed email. For a slew of reasons, this is not a sufficiently
good solution:

- PGP support in mail clients continues to be sub-par
- Patch archival and management tools (like patchwork) remove easy
  ability to verify PGP signatures because they need to modify email
  bodies (but not patch content), e.g. to add Reviewed-By: or similar
- Tools like git-am have no native support for verifying PGP signatures

# Proposed approach

I recommend that we provide a way to include cryptographic signature
information natively using git-format-patch, using roughly the following

- generate a signify-compatible cryptographic signature of the verbatim
  patch content, perhaps slightly normalized for things like LF vs. CRLF
  line endings (see minisign/libsodium for crypto details)
- include both the signature and the public key in the area below '---',
  using "Minisig:" and "Minikey:" taglines

For example:

>From b41a2a0f817caddc9a76f43c3c9ed7d8edd6b2de Mon Sep 17 00:00:00 2001
From: Konstantin Ryabitsev <konstan...@linuxfoundation.org>
Date: Tue, 10 Sep 2019 06:15:36 -0400
Subject: [PATCH] Second commit

Change the greeting.

Signed-off-by: Konstantin Ryabitsev <konstan...@linuxfoundation.org>
 foo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

 Minikey: RWT9fcUvSnHPLqqyfLbkGBMEscBWciFFp2iBj2XnZPzW69OVIoYwZ25q

diff --git a/foo.c b/foo.c
index d40a2b9..dcfad55 100644
--- a/foo.c
+++ b/foo.c
@@ -1,5 +1,5 @@
 #include <stdio.h>
 int main()
-    printf("Hello, World!");
+    printf("Hello, Signed World!");

When git-am encounters a signed patch, it should:

1. check if the email in From: matches existing entries in git's TOFU
   (trust on first use) database, which is a simple key-value store


2. if no matches, add a new entry to the TOFU tracking database and
   consider the key automatically trusted (perhaps configurable)
3. if there are existing matches:

   a. compare the keys to make sure they haven't changed
   b. if keys changed, emit a warning and let developer decide if they
      trust the key change
   c. if keys did not change, validate the signature
   d. if validation failed, alert the developer and error out

4. if the TOFU db exists at all, git-am should check if the email
   address in From: matches any existing records and alert if the patch
   carries no signature (in case it's been removed by a malicious

All of these operations should be sufficiently fast, since both ECC
crypto and key-value lookups are fast operations that don't require a
lot of resources.

# Why minisigs?

In my experience, the kinds of developers who submit patches to mailing
lists would consider PGP/GnuPG too cumbersome to bootstrap, which is why I
lean towards managing keys natively by git. In my mind, the process
would go like this:

- developer sends patches to the mailing list
- maintainer responds with "looks good, but please sign and resubmit
  by passing --minisign to git-format-patch"
- developer runs `git format-patch --minisign`, which walks them through
  generating the key and storing it in a dedicated file
- git can take care of passphrase handling by hooking into
  credential-helper and credential-cache routines

# Coupling with PGP

Communities relying on the PGP web of trust can tie minikeys with their
PGP identity by creating a UID entry containing their minisign public key,

pub   rsa4096/E63EDCA9329DD07E 2011-11-07 [SC]
uid                 [ultimate] Konstantin Ryabitsev 
uid                 [ultimate] Konstantin Ryabitsev 

Such UIDs can be revoked as necessary and new ones can be created --
plus they are searchable using standard gnupg/keyserver tools.

# Comments?

I'd love to hear your feedback on the idea. Even if this scheme is not
used by maintainers directly, it offers ways of verifying if patches
stored in public archives (such as public-inbox) have been modified and
provides some developer attestation of email-based workflows.


Reply via email to