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

[Brian Dolbec]

On Sat, 07 Mar 2015 15:26:26 -0800
Zac Medico <zmedico@g.o> 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.

When we move from cvs to git, newer git makes it possible to git push
--sign.  That info is available on the recieving server and the
receiving server also runs gpg to verifiy the incoming data.

Only problem there is git does not store that data.  There is however a
hook that gathers the info and saves it in git's metadata for that
repo.  That makes it possible to run a verification on the repo at any
other time.  Not just during the recieve operation.

When we do move to a git tree.  My information is that pushes will not
contain a signed manifest like they are now for cvs.  Instead the
Manifest files will be generated for the rsync distribution tree and
signed with gentoo gpg key.  Replicating the existing tree structure.

I will likely have a patch for portage very soon which uses gkeys libs
to verify the Manifests.  gkeys-9999 is able to verify the Manifest
files now if the gentoo-devs keys are installed.

Main questions for now is.  Do we want to have a post sync hook that
checks the tree for invalid Manifest sigs?  Or do we just have it
verify the manifest for the pkg at build/merge time?  Or both?

-- 
Brian Dolbec <dolsen>