1 |
Hi to all! |
2 |
|
3 |
I've recently seen the outbreak of "violence" concerning signing packages or |
4 |
rather files in the Gentoo portage system. I am currently working on a system |
5 |
which does exactly this signing process with an addon library I've written |
6 |
myself (so, no need for gpg, just Python + module). I've devised quite an |
7 |
intricate scheme of checks and balances, which amounts to the following: |
8 |
|
9 |
1. have a master "Gentoo" key, which is kept by the Gentoo RelEng, which only |
10 |
signs other keys and a list of keys removed from circulation, no ebuilds. |
11 |
2. have each developer create a keypair for themselves, send their public key |
12 |
to the RelEng via some form of _safe_ channel (this is important), and have |
13 |
the RelEng send back the signed key to the developer. |
14 |
3. have each developer sign his/her packages with their own key. |
15 |
|
16 |
Keys are distributed via a P2P network with large-scale replication, just as |
17 |
are files from the portage tree. As there is large-scale replication (not |
18 |
just some hundred servers, but rather thousands of them), and each user can |
19 |
check whether the file he/she receives is valid (by verifying the signature |
20 |
on the key which was found to have a correct signature on the corresponding |
21 |
file), there'll be no corruption of the data on the network (at least it'll |
22 |
be very hard to achieve), as invalid data sent to a remote host for |
23 |
caching/processing is simply discarded. And, to have control over the system |
24 |
(well, rather to DOS it), an attacker would have to inject lots of machines |
25 |
under his control into the system (so that he could forge certain areas of |
26 |
the distributed hash table address space). But this is near impossible for a |
27 |
large scale network. |
28 |
|
29 |
The only key which needs to be distributed in a safe form is the Gentoo master |
30 |
key, which is used to sign all other keys. This is similar to distributing a |
31 |
CA key, and should be easy to implement (for example, if you don't trust your |
32 |
network connection, order the one single key on CD via snail-mail). |
33 |
|
34 |
Anyway, if anybody is interested in working on this with me, mail me. I don't |
35 |
have much time at the moment, and I've been working on this about half a year |
36 |
now, but I guess as the end of year draws nearer, I might actually be getting |
37 |
somewhere near a working implementation of this sometime soon, and should be |
38 |
there even faster if someone else is interested in making it work with me. |
39 |
|
40 |
Concerning security: read up on Kademlia, and its near indestructibility when |
41 |
many hosts are attached and the large attack base needed to DOS it (and I |
42 |
guess that many Gentoo users who have a permanent/near permanent internet |
43 |
connection will gladly offer up a little bandwith to create a large |
44 |
distributed hash table, at least I would). |
45 |
|
46 |
And on another note: this makes overlays unnecessary. At least in my theory |
47 |
everybody may inject ebuilds signed with his key into the system (each host |
48 |
accepts a certain amount of "non-Gentoo" ebuilds), and each user may decide |
49 |
that he trusts a certain non-Gentoo ebuild writer so much that he wants these |
50 |
ebuilds integrated into the main portage tree (so that they are not discarded |
51 |
when being downloaded). This is pretty much like an overlay, but invisible to |
52 |
the user, and more transparent. |
53 |
|
54 |
Anyway, my english is bad tonight, I'm tired from being at university the |
55 |
whole day, and I have two exams this week, but anyway, if you're interested |
56 |
in this, just mail me, and I'll gladly send you the sources I have ready, |
57 |
they're written using Twisted and Sophie |
58 |
(http://www.heim-d.de/~heikowu/Crypto), both Python modules which are pretty |
59 |
lightweight to install additionally to Python itself. |
60 |
|
61 |
Heiko. |
62 |
|
63 |
-- |
64 |
gentoo-security@g.o mailing list |