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