[gentoo-dev] manifests & gpg

[David Masover]

I have no idea where to post this, so I'll start here.  Tell me where
this belongs.

I see these "manifest" files showing up, which look like checksums for
the checksums, or checksums for the metadata, or something.  I think the
idea is, they help with two goals:

1.)  Make it faster to generate/manage the metadata.
2.)  Make the system more secure.

If an rsync mirror were to be compromised, or someone just felt like
setting up an intentionally compromised one and somehow got it on the
list of "official" mirrors, with Portage as it was when I last checked,
all you'd have to do is add a new ebuild that was a "critical update" to
something like ssh.  It's true that it runs as user "portage", but the
package eventually has to merge to the filesystem, making it all too
easy to install a rootkit on hundreds of systems without really trying.

There's also the fact that rsync itself isn't too secure, so I'm sure
there's the possibility of a man-in-the-middle attack.

It was mentioned on IRC that the manifests, which have checksums for all
the valid ebuilds and files, would be gpg-signed, and that the private
key would be held by project leaders, while the public key would be
installed once -- off the install cd.

That's the state if this issue last I checked.  A few things that I have
no idea of right now are:

What about a manifest for all the manifests?  It'd be easy enough for a
malicious rsync mirror to leave off critical security updates and build
a list of people who now don't have those updates, or who have been
downgraded to old, broken versions.  In order to prevent someone from
just brute-forcing it by having an rsync mirror several months out of
date in its entirety (not just in one package), the manifests should
have dates in them.

In order to prevent evil people from just creating their own manifests,
you sign them, of course.  Aside from the annoyance of making gpg (or
maybe virtual/pgp, or something) a base package, this is a good thing. 
The problem is, how many people have the key?  I think there should be,
say, a master key, held by, say, drobbins, and following the new
management system, each project manager has their own key, and signs the
keys of their subordinates.

This makes the business of signing a particular manifest the
responsibility of whoever is responsible for that package.  It should
also be possible to, within portage, restrict a key to only certain
packages or categories.

How it would work is, say I create my own package, app-toys/foobar
(appologies if something like this already exists).  I manage it and a
few things it depends on, sys-libs/foo and sys-libs/bar.  My direct
supervisor (for simplicity's sake let's say it's drobbins) signs a list
of packages and categories I'm allowed to edit, things like maybe a
lang-baz category, for the special scripting language used by
app-toys/foobar.

This is all a bit much for me, so I create and sign my own list,
delegating sys-libs/foo to my bro.  He can update foo, but so far, only
I can update foobar.  If I delegate lang-baz/documentation to my mom,
she can't change any of the actual software, and my bro (who sucks at
writing) can't change any of the documentation.  I can still micromanage
them if I want, but I probably wouldn't.

This cuts down the points of attack from anyone with an rsync mirror to
a few rsa keys.  Unless someone steals the Master Key from drobbins,
it's always possible to do things like rotate everyone else's keys if
they get stolen.  The only other possibility is someone downloads a
tainted iso with the wrong public key.  True security freaks can handle
this by ordering cds via mail, checking them against downloaded md5sums,
and requesting fingerprints over mail.  The rest of us can just update
when it's ready -- this gives evil people only one shot at thwarting
this scheme.

Awaiting comments,
SanityInAnarchy