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