Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers

[Zac Medico <zmedico@gentoo.org>]

On 03/07/2015 05:24 PM, Brian Dolbec wrote:
> On Sat, 07 Mar 2015 15:26:26 -0800
> Zac Medico <zmedico@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