On Mon, Jul 2, 2018 at 1:50 PM Jason A. Donenfeld <zx...@gentoo.org> wrote: > > On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman <ri...@gentoo.org> wrote: > > To be fair, this is relying quite a bit on the last dev doing a commit > > to be checking his own tree, though that would certainly be helped if > > repoman/portage/etc were checking git sigs so that the starting tree > > is more likely to be clean. Also, if the last dev's key is > > compromised you're hosed no matter what as they can introduce anything > > to the tree and everybody will trust it. > > Actually, no. By keeping a local keychain of trusted developer keys -- > Arch Linux style -- you can just remove developers you don't trust, > and since the .asc files they signed will no longer verify, files from > them will no longer be copied into the real portage tree. It's a nice > way to make the entire process granular, yet still flexible.
This only helps you if a dev you don't trust is compromised. If a dev you trust is compromised, they can modify anything in the tree and you're hosed. > > This kind of git-signature extraction also just sounds difficult and > fiddly to do, even if you do manage to figure out which partial bits > of metadata you need for reconstructing signed hashes. Whereas simply > adding .asc files is a single invocation of GPG -- a pretty > well-understood non fancy procedure. Sure, I'd prefer to not extract git signatures and just distribute via git purely without any rsync. > I think you assessment of the situation here is incorrect. It's not > necessary to trust a developer for the entire state of the tree. You > only need to trust (or distrust) a developer for the files he's > changed. Sure, but since any developer can change any file, that is basically the same thing. If somebody steals a single dev's key they can just rootkit any file of their choosing, sign that one change, and it will slip through any of these methods. The only protection against that is tracking who is allowed to touch what files, and then you're still hosed if a dev for a widely-used file gets their key stolen. I still prefer it to trusting infra though, because: 1. The same attacks still work even with a final infra signoff. 2. The dev signoffs could use hardware tokens where a random server process doesn't have the ability to trigger the signoffs (think hardware button on a yubikey/etc). 3. This enables more mirroring options - like sticking the whole repo on github/etc for direct syncing that is still completely secure due to signoffs. -- Rich
