On Sat, 07 Mar 2015 15:26:26 -0800 Zac Medico <[email protected]> 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>
