Re: [gentoo-dev] Re: [gentoo-security] Verifying portage is from Gentoo

[Evan Powers <powers.161@osu.edu>]

On Monday 13 January 2003 01:34 pm, Dylan Carlson wrote:
> Having the developer sign each ebuild before a commit will minimize these
> risks.  If a dev's box is rooted -- the hacker can commit as many hacks as
> they want to the Gentoo CVS tree, but the ebuilds will not be signed, and
> consequently will be ignored on the Gentoo clients.

I'm going to draw upon Sven Vermeulen's well-reasoned comments (Tuesday 14 
January 2003 04:22 am, same email subject) here.

Let's assume the developers are using CVS-over-ssh and that they're using 
public keys (with good passphrases) to authenticate.

From the developer's perspective, having to sign ebuilds is redundant. By 
logging in with his public key, he's already proven his identity to the 
server. The CVS server can't gain any additional security from a signature. 
It's already 100% certain the developer is who he says he is, and the 
encrypted channel proves that the data is unaltered.

A hacker who roots the dev's machine can't do squat, because he doesn't know 
the passphrase. And if he can discover one passphrase, he can probably 
discover the one protecting the dev's signing key, so signing still won't get 
you anything.

Now, the question is how rigorously we want to pass on this information to the 
next link in the chain, a client or mirror connecting to the CVS server.

On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote:
> 2/ Implement the proposed timeframe. If a tree has not been updated for
> over x hours, warn so that the person can re-emerge with another mirror.
[...]
>    	Problems:
> 		- This assumes we trust the CVS- or FTP-server as we do with
> 		  www.kernel.org. Leave it this way. Users and developers
> 		  will soon see if there is something wrong, since the
> 		  Gentoo Development is very active.

I'm with Sven on this one. While having the dev's sign ebuilds allows the 
theoretical advantage of allowing the client or mirror to ascertain validity 
without trusting the CVS server, I think the practical advantages of this 
approach are very small.

1. It's a lot of work.
2. Signatures are unlikely to interact well with the various behind-the-scenes 
actions of CVS. (Such as keywords like $Version: $.)
3. Because commits of multiple files are not atomic with CVS, it'll be very 
difficult to associate a signature with the correct file version. There's 
nothing associating the two versions within their RCS files. Furthermore, it 
becomes possible for one user executing a CVS checkout to get a new file with 
the old signature, or vice versa. Since the CVS server has a lot of activity, 
I would expect such events to happen often enough to be quite annoying.

On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote:
> 3/ Have Portage individually register every removal of the Portage tree.

A better thing than a separate removal registry is to roll the functionality 
into the mtime and signature files that are already present. If a file isn't 
mentioned, it's presence is an error.

In the forum discussion at http://forums.gentoo.org/viewtopic.php?t=26137, I 
discuss a framework which describes how this could be done.

Comments anyone?

Evan Powers

--
gentoo-dev@gentoo.org mailing list