Some constructive suggestions that might address some (but not all!) maliability concerns and some clunkiness concerns: A. What data are you signing? Your current approach is to split up the email into parts, canonicalize them, hash them, and then sign those hashes. Instead you could actually more easily canonicalize the applied email. That is: when you have a commit in a git tree, you can always git-format-patch it into the same format. So, if you git-am an email, and then git-format-patch it out, you'll get some standard format. You could insist all signatures are made over this standard format. There's still the same set of attacks I mentioned earlier here, but it's a bit less frail. B. How are you communicating the signatures? Your approach sticks these on a separate mailing list, linked by some hash prefixes. Two approaches that would make the whole thing a lot less clunky: 1. Include it as a separate part in a multi-part mime message. Lore web interface could bury it someplace reasonable. vger could learn to accept these parts, and since hashing is already mega fast, it could even validate that the hashes are correct and reject emails with bad (or missing) hashes. (I'm not suggesting validating the signature, but rather just the hashes.) 2. Switch to using the tiny ed25519 signatures provided by signify/minisign -- which has numerous benefits over gpg alone -- and stick it in the mail headers. This is something git-send-email could learn to add. X-Git-Format-Patch-Hash: aC1ywMbaJpiMFJY7vK/62eBKtrgKiVIXFHa+WPQwBJk= X-Git-Format-Patch-Ed25519-Signature: aSscBu2pXbIEDCuRZ7E0uKWVsE5SitNM8UA44tuFc/rg3GQwv5Ur/mpOk2mQJbT6dPDghuxJ1gwZKAZK20BXAQ== I prefer (2), but (1) would be acceptable if you're some how wedded to pgp and I can't talk you out of it. I can write whatever cryptographic code we need to do (2), but I suspect signify/minisign have everything we need.
