Re: [gentoo-dev] Trustless Infrastructure

[Alec Warner]

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

Mostly re-posting my comments from irc (including typos!)

18:03 < antarus> zx2c4: my other problem with these scheme is simply a
QA / functionality one
18:04 < antarus> zx2c4: we currently have tools that operate on the entire repo
18:04 < antarus> I'm not convinced we can really make any gaurantees
about the subtree
18:04 < antarus> e.g. if my commits are not trusted for example; it
might result in a tree that can't install any packages
18:05 < antarus> Which I mean, from some PoV is great (because antarus
is a terrible human)
18:05 < antarus> but if at the end of the day you need to trust
antarus to use Gentoo; I guess this leads you back to "why am I using
gentoo", questoin
18:06 < antarus> (its nto a problem in practice because antarus
doesn't have commit access to ::gentoo; but as a hypothetical,
obviously
18:06 < antarus> It also means that support for anyone with this
'filtering' is a nightmare
18:06 < antarus> because who knows what subset of the tree their keyring filters

In short I'm looking for a support and QA story here (how do we tell if a
compilation failure is real, or just due to an incomplete tree?)
We have similar efforts in QA (e.g. continuous integration projects) that
verifies the dependency trees and those too require a consistent repo
snapshot of the tree.

We might reduce the complexity here by saying things like:

"We have N trust levels"

0) We believe this person is using state of the art processes.
...) Some other level descriptor.
N) This persons security stance is unknown.

Then we can do stuff like run CI against each level (because we can compute
the tree users will see on every commit) and it clarifies the support story
somewhat.

-A


>
> > The original point zx2c4 is making is reasonably valid.  IMO it is
> > much cleaner to just verify directly against the git history.  If you
> > wanted to verify the whole git history via rsync you're going to have
> > to extract a lot more metadata from the git repo to reconstruct all of
> > that down to the blobs, because otherwise the commit content hashes
> > are referring to blobs that are no longer in the rsync tree.
>
> 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.
>
> > I think a big question here is whether we just need to test the last
> > dev's commit for normal user use.  If so, then that simplifies things
> > a lot, either for rsync or git syncing.  If you want to test all the
> > prior history then the rsync solution gets more complex if you want to
> > leverage git sigs.  However, I'd argue that with our current trust
> > model the entire history is only as good as the last dev's commit
> > anyway.  Maybe if devs had a more limited scope of authority that a
> > verification tool could take into account you'd get more from looking
> > backwards in time (it would reject a commit to openrc by an X11 dev,
> > as an example).
>
> 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.
>
>
From a user-story prospective, I'm curious how end users (e.g. people who
are not you) are supposed to go about vetting developer keys.

Is there a story there?

-A