On 03/07/2015 05:24 PM, Brian Dolbec wrote: > On Sat, 07 Mar 2015 15:26:26 -0800 > Zac Medico <zmed...@gentoo.org> wrote: > >> On 03/06/2015 09:50 AM, Mark Kubacki wrote: >>> We're on the same side here. >>> >>> Do we have numbers showing the ratio "portage used with defaults" >>> vs. where "[webrsync-gpg] is described in many hardening guides for >>> gentoo and widely used among the security conscious" applies? >>> >>> DNS not being encrypted is just painting the whole picture. Point >>> is, the default is that "emerge --sync" results in a transfer using >>> RSYNC (or http). >>> >>> And by default you cannot compare the result with any authoritative >>> source. >>> >> >> Ideally, we can rely on security mechanisms built into git [1], >> possibly involving signed commits. >> >> [1] https://github.com/gentoo/gentoo-portage-rsync-mirror > > > Actually, git makes it nearly impossible to get the correct info > required to re-process the git commit signature. It is all embedded > into the commit itself, but not in a way for gpg to be able to > re-verify it. Git relies on the issuer's gpg verification status which > it records in it's data before the push. So, without some major > hacking on git data, it is not viable for routine verification purposes.
Maybe we can use the relatively recently added git verify-commit command [1]. If we run that command with --verbose, then we can use that to verify that that a commit was signed with a trusted key. Shouldn't verification of the HEAD commit be enough to vouch for the integrity of the entire tree? [1] https://github.com/git/git/commit/d07b00b7f31d0cb6675b4bdba269ce7f087ddd24 -- Thanks, Zac
