| 1 |
On Mon, Jul 2, 2018 at 1:23 PM Matthias Maier <tamiko@g.o> wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld" <zx2c4@g.o> wrote: |
| 5 |
> |
| 6 |
> > Aren't git signatures done over the full commit objects? Meaning you'd |
| 7 |
> > need the entire tree of metadata and thus all commits in order to |
| 8 |
> > verify? Or do you see some clever opportunity for extracting just |
| 9 |
> > enough metadata that you could actually have a file-based, rather than |
| 10 |
> > commit-based, verification? |
| 11 |
> |
| 12 |
> |
| 13 |
> Git signatures are over the full commit object - and the commit contains |
| 14 |
> a hash of the root of the full repository tree. Git internally only |
| 15 |
> stores tree snapshots (and not differences). So all you need is exactly |
| 16 |
> one signed commit to verify that |
| 17 |
> |
| 18 |
> - this is the full repository tree the developer saw at the time of the |
| 19 |
> commit |
| 20 |
> |
| 21 |
> - this is the full history the developer saw at the time of the commit |
| 22 |
> |
| 23 |
|
| 24 |
To be fair, this is relying quite a bit on the last dev doing a commit |
| 25 |
to be checking his own tree, though that would certainly be helped if |
| 26 |
repoman/portage/etc were checking git sigs so that the starting tree |
| 27 |
is more likely to be clean. Also, if the last dev's key is |
| 28 |
compromised you're hosed no matter what as they can introduce anything |
| 29 |
to the tree and everybody will trust it. |
| 30 |
|
| 31 |
The original point zx2c4 is making is reasonably valid. IMO it is |
| 32 |
much cleaner to just verify directly against the git history. If you |
| 33 |
wanted to verify the whole git history via rsync you're going to have |
| 34 |
to extract a lot more metadata from the git repo to reconstruct all of |
| 35 |
that down to the blobs, because otherwise the commit content hashes |
| 36 |
are referring to blobs that are no longer in the rsync tree. |
| 37 |
|
| 38 |
I think a big question here is whether we just need to test the last |
| 39 |
dev's commit for normal user use. If so, then that simplifies things |
| 40 |
a lot, either for rsync or git syncing. If you want to test all the |
| 41 |
prior history then the rsync solution gets more complex if you want to |
| 42 |
leverage git sigs. However, I'd argue that with our current trust |
| 43 |
model the entire history is only as good as the last dev's commit |
| 44 |
anyway. Maybe if devs had a more limited scope of authority that a |
| 45 |
verification tool could take into account you'd get more from looking |
| 46 |
backwards in time (it would reject a commit to openrc by an X11 dev, |
| 47 |
as an example). |
| 48 |
|
| 49 |
I'm just trying to avoid going back to the old manifest solution when |
| 50 |
git seems a lot cleaner otherwise. |
| 51 |
|
| 52 |
-- |
| 53 |
Rich |
Archives