1 |
On Monday 13 January 2003 01:34 pm, Dylan Carlson wrote: |
2 |
> Having the developer sign each ebuild before a commit will minimize these |
3 |
> risks. If a dev's box is rooted -- the hacker can commit as many hacks as |
4 |
> they want to the Gentoo CVS tree, but the ebuilds will not be signed, and |
5 |
> consequently will be ignored on the Gentoo clients. |
6 |
|
7 |
I'm going to draw upon Sven Vermeulen's well-reasoned comments (Tuesday 14 |
8 |
January 2003 04:22 am, same email subject) here. |
9 |
|
10 |
Let's assume the developers are using CVS-over-ssh and that they're using |
11 |
public keys (with good passphrases) to authenticate. |
12 |
|
13 |
From the developer's perspective, having to sign ebuilds is redundant. By |
14 |
logging in with his public key, he's already proven his identity to the |
15 |
server. The CVS server can't gain any additional security from a signature. |
16 |
It's already 100% certain the developer is who he says he is, and the |
17 |
encrypted channel proves that the data is unaltered. |
18 |
|
19 |
A hacker who roots the dev's machine can't do squat, because he doesn't know |
20 |
the passphrase. And if he can discover one passphrase, he can probably |
21 |
discover the one protecting the dev's signing key, so signing still won't get |
22 |
you anything. |
23 |
|
24 |
Now, the question is how rigorously we want to pass on this information to the |
25 |
next link in the chain, a client or mirror connecting to the CVS server. |
26 |
|
27 |
On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote: |
28 |
> 2/ Implement the proposed timeframe. If a tree has not been updated for |
29 |
> over x hours, warn so that the person can re-emerge with another mirror. |
30 |
[...] |
31 |
> Problems: |
32 |
> - This assumes we trust the CVS- or FTP-server as we do with |
33 |
> www.kernel.org. Leave it this way. Users and developers |
34 |
> will soon see if there is something wrong, since the |
35 |
> Gentoo Development is very active. |
36 |
|
37 |
I'm with Sven on this one. While having the dev's sign ebuilds allows the |
38 |
theoretical advantage of allowing the client or mirror to ascertain validity |
39 |
without trusting the CVS server, I think the practical advantages of this |
40 |
approach are very small. |
41 |
|
42 |
1. It's a lot of work. |
43 |
2. Signatures are unlikely to interact well with the various behind-the-scenes |
44 |
actions of CVS. (Such as keywords like $Version: $.) |
45 |
3. Because commits of multiple files are not atomic with CVS, it'll be very |
46 |
difficult to associate a signature with the correct file version. There's |
47 |
nothing associating the two versions within their RCS files. Furthermore, it |
48 |
becomes possible for one user executing a CVS checkout to get a new file with |
49 |
the old signature, or vice versa. Since the CVS server has a lot of activity, |
50 |
I would expect such events to happen often enough to be quite annoying. |
51 |
|
52 |
On Tuesday 14 January 2003 04:22 am, Sven Vermeulen wrote: |
53 |
> 3/ Have Portage individually register every removal of the Portage tree. |
54 |
|
55 |
A better thing than a separate removal registry is to roll the functionality |
56 |
into the mtime and signature files that are already present. If a file isn't |
57 |
mentioned, it's presence is an error. |
58 |
|
59 |
In the forum discussion at http://forums.gentoo.org/viewtopic.php?t=26137, I |
60 |
discuss a framework which describes how this could be done. |
61 |
|
62 |
Comments anyone? |
63 |
|
64 |
Evan Powers |
65 |
|
66 |
-- |
67 |
gentoo-dev@g.o mailing list |