Re: Patch attestation RFC + proof of concept

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux