On Mon, Jul 2, 2018 at 1:23 PM Matthias Maier <tam...@gentoo.org> wrote: > > > On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld" <zx...@gentoo.org> > wrote: > > > Aren't git signatures done over the full commit objects? Meaning you'd > > need the entire tree of metadata and thus all commits in order to > > verify? Or do you see some clever opportunity for extracting just > > enough metadata that you could actually have a file-based, rather than > > commit-based, verification? > > > Git signatures are over the full commit object - and the commit contains > a hash of the root of the full repository tree. Git internally only > stores tree snapshots (and not differences). So all you need is exactly > one signed commit to verify that > > - this is the full repository tree the developer saw at the time of the > commit > > - this is the full history the developer saw at the time of the commit >
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. 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. 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'm just trying to avoid going back to the old manifest solution when git seems a lot cleaner otherwise. -- Rich
