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