Re: [gentoo-dev] Trustless Infrastructure

[Rich Freeman]

On Mon, Jul 2, 2018 at 1:50 PM Jason A. Donenfeld <zx2c4@g.o> wrote:
>
> On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman <rich0@g.o> 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