| 1 |
On Mon, Jul 2, 2018 at 7:41 PM Rich Freeman <rich0@g.o> wrote: |
| 2 |
> To be fair, this is relying quite a bit on the last dev doing a commit |
| 3 |
> to be checking his own tree, though that would certainly be helped if |
| 4 |
> repoman/portage/etc were checking git sigs so that the starting tree |
| 5 |
> is more likely to be clean. Also, if the last dev's key is |
| 6 |
> compromised you're hosed no matter what as they can introduce anything |
| 7 |
> to the tree and everybody will trust it. |
| 8 |
|
| 9 |
Actually, no. By keeping a local keychain of trusted developer keys -- |
| 10 |
Arch Linux style -- you can just remove developers you don't trust, |
| 11 |
and since the .asc files they signed will no longer verify, files from |
| 12 |
them will no longer be copied into the real portage tree. It's a nice |
| 13 |
way to make the entire process granular, yet still flexible. |
| 14 |
|
| 15 |
> The original point zx2c4 is making is reasonably valid. IMO it is |
| 16 |
> much cleaner to just verify directly against the git history. If you |
| 17 |
> wanted to verify the whole git history via rsync you're going to have |
| 18 |
> to extract a lot more metadata from the git repo to reconstruct all of |
| 19 |
> that down to the blobs, because otherwise the commit content hashes |
| 20 |
> are referring to blobs that are no longer in the rsync tree. |
| 21 |
|
| 22 |
This kind of git-signature extraction also just sounds difficult and |
| 23 |
fiddly to do, even if you do manage to figure out which partial bits |
| 24 |
of metadata you need for reconstructing signed hashes. Whereas simply |
| 25 |
adding .asc files is a single invocation of GPG -- a pretty |
| 26 |
well-understood non fancy procedure. |
| 27 |
|
| 28 |
> I think a big question here is whether we just need to test the last |
| 29 |
> dev's commit for normal user use. If so, then that simplifies things |
| 30 |
> a lot, either for rsync or git syncing. If you want to test all the |
| 31 |
> prior history then the rsync solution gets more complex if you want to |
| 32 |
> leverage git sigs. However, I'd argue that with our current trust |
| 33 |
> model the entire history is only as good as the last dev's commit |
| 34 |
> anyway. Maybe if devs had a more limited scope of authority that a |
| 35 |
> verification tool could take into account you'd get more from looking |
| 36 |
> backwards in time (it would reject a commit to openrc by an X11 dev, |
| 37 |
> as an example). |
| 38 |
|
| 39 |
I think you assessment of the situation here is incorrect. It's not |
| 40 |
necessary to trust a developer for the entire state of the tree. You |
| 41 |
only need to trust (or distrust) a developer for the files he's |
| 42 |
changed. |
Archives