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@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 10 Sep 2019 06:15:36 -0400
Subject: [PATCH] Second commit
Change the greeting.
Signed-off-by: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
---
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@xxxxxxxxxxxxxxxxxxx: 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@xxxxxxxxxxxxxxxxxxx>
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
