git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: git@vger.kernel.org
Subject: RFC: Cryptographic attestation for email-based patch workflows
Date: Tue, 10 Sep 2019 08:13:24 -0400	[thread overview]
Message-ID: <20190910121324.GA6867@pure.paranoia.local> (raw)

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
  taglines
- 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
process:

- 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:

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

Change the greeting.

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

 Minisig: RWT9fcUvSnHPLiqWgXEnn98sgk8nl4FteDRkD+9lVK+He//eLOxNZ5QjCROoKJgPGpL4uzoHicN+f6gB54qmtO1cQtfvjS+++QU=
 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!");
 }
--ᐞ
2.21.0
---8<---

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
   like:

   konstantin@linuxfoundation.org: RWT9fcUvSnHPLqqyfLbkGBMEscBWciFFp2iBj2XnZPzW69OVIoYwZ25q

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
   attacker).

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,
e.g.:

pub   rsa4096/E63EDCA9329DD07E 2011-11-07 [SC]
      DE0E66E32F1FDD0902666B96E63EDCA9329DD07E
uid                 [ultimate] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
uid                 [ultimate] Konstantin Ryabitsev <RWT9fcUvSnHPLqqyfLbkGBMEscBWciFFp2iBj2XnZPzW69OVIoYwZ25q>

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.

-K

             reply	other threads:[~2019-09-10 12:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 12:13 Konstantin Ryabitsev [this message]
2019-09-27 15:24 ` RFC: Cryptographic attestation for email-based patch workflows dwh
2019-09-30 15:37   ` Konstantin Ryabitsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190910121324.GA6867@pure.paranoia.local \
    --to=konstantin@linuxfoundation.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).