1 |
On Monday 13 January 2003 12:27pm, Evan Powers wrote: |
2 |
> On Monday 13 January 2003 05:24 am, Paul de Vrieze wrote: |
3 |
> > Maybe the easiest way would be that some/all rsync mirrors would offer |
4 |
> > rsync over ssl, so that the origin servers could be authenticated. |
5 |
> > This would also mean some changes for clients to be able to use it. |
6 |
> |
7 |
> I think something does have to be done about this. |
8 |
> |
9 |
|
10 |
I agree, but FWIW, the BSDs have had unsigned ports for a long time without |
11 |
any serious issues. How complex is this issue, really? |
12 |
|
13 |
* gnupg must be installed for every user, and special practices will have |
14 |
to go into place to protect gnupg from tampering. (achilles) |
15 |
|
16 |
* a publically available web of cross-signed public keys needs to be made |
17 |
available, with the keys also available on MIT's keyserver for sanity. |
18 |
|
19 |
* each dev signs the ebuild with his/her public key before it gets |
20 |
committed. |
21 |
|
22 |
> Secure rsync (via SSL or whatever) doesn't completely solve the |
23 |
> problem. |
24 |
|
25 |
cvsup and rsync can use SSL via stunnel. I would like to see Gentoo use |
26 |
cvsup for efficiency/bandwidth reasons instead of rsync. |
27 |
|
28 |
Traffic encryption is only useful to minimize risk of man-in-the-middle |
29 |
attacks/dns hacks/etc... which all said and done, is rare. IMO this |
30 |
should be the last priority. |
31 |
|
32 |
> |
33 |
> That said, there's many ways of signing the portage tree. I advocate |
34 |
> having the master rsync server automatically sign the tree as it checks |
35 |
> out the CVS tree. |
36 |
|
37 |
Single point of failure, I don't like this idea in the sense of |
38 |
server-->clients. That key would have to be updated constantly, and if |
39 |
it gets compromised, everything is compromised by way of assumption. |
40 |
|
41 |
However -- I see this as being valuable in replicating the master tree to |
42 |
other mirrors, though, where the pubkeys are known only to the master and |
43 |
its mirrors. That's if you're using rsync. |
44 |
|
45 |
cvsup uses authentication keys to mirror. |
46 |
|
47 |
> 2) CVS works against per-developer signing of ebuilds. Consider |
48 |
> "$Version: $", etc. |
49 |
|
50 |
We should take the CVS keywords out of the ebuilds. |
51 |
|
52 |
> 3) Ultimately we are forced to trust CVS, so we can't realize any |
53 |
> additional security from per-developer signatures. |
54 |
|
55 |
I'm not sure that the ultimate problem is CVS... it's human beings. If you |
56 |
don't have an account with the right keys on the CVS box, you're not doing |
57 |
updates. It's that simple. |
58 |
|
59 |
If people are using ssh keys without passphrases, someone can take over a |
60 |
dev's box and do all the nastiness they want to on Gentoo's CVS server. |
61 |
That's not the fault of CVS or SSH. |
62 |
|
63 |
[1] Dev's have to generate their keys properly, and keep their machines |
64 |
secure. |
65 |
[2] Gentoo project managers need to kill off inactive developers, and |
66 |
regularly hold key-signing parties. |
67 |
|
68 |
Having the developer sign each ebuild before a commit will minimize these |
69 |
risks. If a dev's box is rooted -- the hacker can commit as many hacks as |
70 |
they want to the Gentoo CVS tree, but the ebuilds will not be signed, and |
71 |
consequently will be ignored on the Gentoo clients. |
72 |
|
73 |
That is why I'm saying one key sign for the whole tree is a bad idea... |
74 |
|
75 |
This is some good conversation... |
76 |
|
77 |
Cheers, |
78 |
Dylan Carlson [absinthe@×××××.com] |
79 |
|
80 |
-- |
81 |
gentoo-dev@g.o mailing list |