Re: Patch attestation RFC + proof of concept

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Fri, Feb 28, 2020 at 09:57:47AM +0800, Jason A. Donenfeld wrote:
> On Thu, Feb 27, 2020 at 10:29 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> > This is why I've been keeping pgpkeys.git repository around.
> > https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
> 
> Ah, right, that seems good. There's also signify, by the way, if you
> ever feel the urge to jump ship from pgp. We can add cgit support for
> it too.

I like minisign/signify, but not for this. It would be a great addition 
to signing tarballs and other project releases, but it is poorly suited 
for inter-developer attestation, for the following reasons:

- There is no key management framework. If I lose access to my key, or 
  it's stolen, or whatever else, I have no mechanism for revoking the 
  old key beyond sending out a "please don't trust my old key." PGP is 
  not great for this either, because we have to rely on the rotting
  remains of the keyservers network, but at least there is *some* 
  mechanism for propagating key revocation.
- There is no support for cross-attestation, so owner trust must be 
  bootstrapped via some other mechanism -- either via TOFU, or via 
  delegating it to HTTPS (I trust that this key belongs to Alex Dev 
  because I downloaded it from https://alexdev.foo). Everyone likes to 
  dump on the Web of Trust because it is hard to grok and can't possibly 
  scale, but for niche applications like development communities it 
  actually works reasonably well and serves its purpose.
- There is no support for offloading crypto operations to specialized 
  portable hardware tokens (Yubikeys, Nitrokeys, whatnot). This means 
  that unless you always protect your minisign key with a passphrase, it 
  can leak off your disk in any number of ways (careless backups, 
  fat-fingered rsync jobs, vulnerable browsers, etc). If you *do* 
  protect your key with a strong passphrase, though...
- There is no support for any kind of PIN entry agent. If you need to 
  invoke minisign 50 times, then you will be typing in that passphrase 
  50 times. Or you will be copy-pasting it, which means it'll be 
  floating in your copypaste buffer for hours or days after you're done.

Sure, the answer to many of the above is "provide wrapper tooling that 
does what you need" -- but if we provide that kind of tooling for 
minisign, then we will end up with something that is similar to GnuPG 
and everyone will start hating on it just as much as they hate on PGP 
(me included). :)

PGP sucks not because its core concepts suck -- it sucks because 
implementing delegated trust in something resembling a secure way is 
super hard to do. That, and because GnuPG tries to remain compatible 
with all of the legacy crypto of the past 30 years. If it drops support 
for that legacy, it will start sucking a lot less.

The only way I see being able to use signify-style signatures is if 
there is broad adoption of did:git or any number of other nascent 
"sovereign identity" proposals. At this time, PGP/GnuPG is the best tool 
for decentralized delegated trust that we have.

> > This doesn't really concern me as much. Anyone can submit 
> > attestation
> > signatures, true, but we throw out anything that doesn't validate and
> > also any PGP keys where none of the UIDs match the From: header. So, if
> > a malicious person sends a bunch of attestations, then they will just be
> > noise and fail at the "gpg --verify" stage because you won't have that
> > key on your keyring.
> 
> That From header is forgeable too, by the way. (Some patches even have
> two From headers -- one in the body of the email for git and one that
> actually sent the email.)

Right, git-mailinfo will pick the one that's in the body. To reiterate, 
git-mailinfo returns whatever Git decides to use for its commit 
purposes, which is why I defer to it for most decisions.

> > Why does it matter?
> 
> You send the patch to lkml. Then your Internet cuts out while the
> firemen deal with an unidentified creature stuck in a nearby tree
> meowing loudly. Finally it's back on and you submit the attestation.
> However, while the cat was ruining your workflow, tglx went to apply
> your patch but wasn't able to find the signature email, since you
> hadn't posted it yet. Hence, a better flow is to just post the
> signature email first.

I'd expect him to treat it in the same way as "you forgot to 
Signed-off-by your patches, please resubmit." However, signing before 
you send is fine, too, I'm not picky. :)

> > I agree that Attestation-verified is redundant with Signed-off-by. I
> > think Attestation-by is helpful for the purposes of seeing the
> > attestation chain. If Developer A sent patches to Submaintainer B, and
> > Submaintainer B sent it to Maintainer C, these headers will help us
> > figure out which steps were attested. If you only see:
> >
> > Attestation-by: Submaintainer B
> >
> > You'll know that there probably was no attestation submitted/checked for
> > when the patches travelled between Developer A and Submaintainer B.
> >
> > However, I don't feel strongly about this. If the community decides that
> > these trailers are not useful, we can drop them. Most of this can be
> > otherwise traced via Link: trailers.
> 
> I think this too is redundant and mostly theater. Those trailers
> aren't authenticated, so they communicate basically nothing useful
> except, "I'm one of the cool maintainers who use this thing!" For
> everyone else, it's just clutter.

Okay, like I said, I don't feel strongly about it.

> I like that this all uses email and simple python command line tools
> and whatnot. But the whole scheme just seems kind of brittle and
> clunky.

It's not any more brittle and clunky than using email for patches. :)

-K