1 |
On Mon, 30 Mar 2009 15:38:22 +0200 |
2 |
Arne Babenhauserheide <arne_bab@×××.de> wrote: |
3 |
|
4 |
> Am Montag 30 März 2009 13:38:23 schrieb Philipp Riegger: |
5 |
> > There is no p2p stuff in here since I don't believe in it. I see 1 |
6 |
> > way to make this work: Create a p2p network of only gentoo |
7 |
> > developers (ok, maybe arch testers), make them sign the packages |
8 |
> > using gpg. Other people can only mirror packages, not add new ones. |
9 |
> |
10 |
> Or add another group of trusted builders, who sign their packages |
11 |
> with GnuPG. |
12 |
|
13 |
And how will you find and identify trustworthy people? |
14 |
|
15 |
> You need trustworthy people, but the level of required ability is far |
16 |
> lower than for testers or developers, since people just need to be |
17 |
> trustworthy not to tamper with their binpackages - and those get |
18 |
> built automatically by portage. |
19 |
|
20 |
I agree, ability is not so important here. But what should stop me from |
21 |
creating a binary package of openssh and add a master passwort into the |
22 |
binary, as a backdoor from the system? Now you can save checksums of |
23 |
source packages, if you like, but you can never make it impossible for |
24 |
me not to fake everything. That's why you cannot trust my signature. |
25 |
But how will you know that? |
26 |
|
27 |
> For convenience it would be great, if people could tellportage their |
28 |
> builder- ID and have portage upload generated packages automatically. |
29 |
|
30 |
Are you crazy? That would lead to hundreds od users uploading the same |
31 |
package with a different signature, because no one can trust the |
32 |
other. |
33 |
|
34 |
> That way we'd avoid building any package with teh same configuration |
35 |
> twice. |
36 |
|
37 |
So if my package with the backdoor gets uploaded first, I win? |
38 |
|
39 |
> With USE Hash and Host SLOT (and a way to identify binary compatible |
40 |
> versions) all requirements for possible p2p distribution would be |
41 |
> fulfilled. |
42 |
|
43 |
This is totally unimportant. Sure, technically it can be done, but you |
44 |
can never make it secure without really checking who is allowed to |
45 |
upload packages or using centrally managed servers. And in the first |
46 |
case you get much too much overhead. |
47 |
|
48 |
> Besides: One advantage of the Hash over all active USE flags as |
49 |
> opposed to a bitvector of all USE flags is that this Hash will be the |
50 |
> same for all packages with the same active USE flags, so there will |
51 |
> be a lower number of distinct USE hashes. That way they can more |
52 |
> easily be used to query for packages (that's a possible optimization |
53 |
> for p2p: search by package name + version + USE hash + Host SLOT). |
54 |
|
55 |
That is wrong. The function creating the packed binary vector is |
56 |
nothing but a reversible hash function. You take the activated |
57 |
USE-flags and the package name and version and get the "hash", you take |
58 |
package name and version and the "hash and get the activated |
59 |
USE-flags. Just because it does not have a fixed length and is not |
60 |
called CRC32, md5 or whatever does not stop it from beeing a hash. |
61 |
|
62 |
There is exactly one problem I know of with my approach, which I |
63 |
already mentioned but no one seems to be interested in: It needs a |
64 |
fixed set of USE-flags per package name and version, or it needs to be |
65 |
extended/it can become ambiguous. But this is just a policy that can be |
66 |
enforced if people see the benefit. |
67 |
|
68 |
Philipp |