On Fri, Feb 28, 2020 at 10:30:23AM +0800, Jason A. Donenfeld wrote: > 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. This won't work because we can't count on the "Date" field to remain the same between when "git-format-patch" is run on the developer's workstation vs. when it's run on the maintainer's workstation. The outputs will not be the same. Furthermore, we need to be able to git-am the patches in order to attest them, which poses the following difficulties: - we need to have the git tree locally - we need to be able to fork it - we need to be able to cleanly git-am the patches, which means that - we need to know at least the base-commit info This will also break down if series have inter-dependencies that require that Series A is applied before Series B can be cleanly applied. > 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: I don't think it's clunky, because we're gearing up to spend a lot of effort enhancing public-inbox cross-list search capabilities. It's clunky *right now* because the proof-of-concept script uses a search-based atom feed to look up attestation messages, but that interface should be dramatically better in the near future. Looking up attestation will be a REST call to lore.kernel.org. Once that happens, we won't need to care on which list the attestation document is present. It can just as well exist on the developer's personal outbox feed -- lore.kernel.org or any of its mirrors will be able to find it based on the attestation ID. > 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.) Sure, mime-attaching it to the cover letter is one of the options I mentioned, but if we call it something other than text/plain, mailman will probably strip it off (or corporate MTAs will helpfully quarantine it); and if we stick with text/plain, everyone will see it in their mail client anyway, so there is little reason to mime-attach it in the first place. I'm actually considering making it possible to send it as a separate message in the series: [PATCH 00/10] Implement adding foo to bar [PATCH 01/10] Move foo into libfoo ... [PATCH 10/10] Remove old bar interface [PSIGN XX/10] Attestation: Implement adding foo to bar I'm just worried that this will create too much clutter, especially on lists that mostly see one-off patches. I can imagine it will be annoying if most of the stuff you receive is: [PATCH] Add foo to bar [PSIGN] Add foo to bar So, I'm sticking it into signatures@xxxxxxxxxx for now and using the search interface to find it. > 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. I'd much rather that git gained the ability to incorporate full commit metadata into git-format-patch output. Then we won't have to invent anything at all -- we can just "git am" the series, then "git verify-commit HEAD" and let git handle all the crypto for us, whatever it happens to be (pgp, s/mime, minisign, or any other crypto ability it gains in the future). There are still problems with this approach (see my comments about git-am above), but at least we can work with this and depend on it not suddenly breaking. However, quite a few of existing developers and maintainers don't work directly with git -- they prefer to queue things up with quilt or similar tools, so we cannot approach this purely from the git workflow perspective. For this reason, I'm pursuing both strategies: - make git-format-patch/git-am a lossless operation - provide an out-of-band attestation mechanism Best, -K
