Gentoo Archives: gentoo-dev

From: Dylan Carlson <absinthe@×××××.com>
To: Evan Powers <powers.161@×××.edu>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] Re: [gentoo-security] Verifying portage is from Gentoo
Date: Mon, 13 Jan 2003 18:38:15
Message-Id: 200301131334.31875.absinthe@pobox.com
In Reply to: Re: [gentoo-dev] Re: [gentoo-security] Verifying portage is from Gentoo by Evan Powers
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

Replies

Subject Author
Re: [gentoo-dev] Re: [gentoo-security] Verifying portage is from Gentoo Sven Vermeulen <sven.vermeulen@××××××.be>