1 |
Hi, |
2 |
|
3 |
I have read all 42 messages that deal with this problem. I have been a Gentoo |
4 |
since the very beginning of the distro, and quite a paranoid one too. |
5 |
However, if I understand what has been said here, even if we sign all ebuilds |
6 |
and source packages, an issue would still remain : trust. You will have to |
7 |
trust that the signature you have gotten is not compromised, and that the |
8 |
source code has not been compromised before it was signed. Moreover, you |
9 |
would have to trust that the person that signed the ebuild has both the |
10 |
skills and ethics necessary. |
11 |
|
12 |
What I'll say now, can be taken as a rather simplistic view of the problem. If |
13 |
I am wrong, I will stand corrected, but I would like an explanation : |
14 |
|
15 |
While I was reading those mails, I was drinking my favorite orange juice. It |
16 |
occurred to me then that I had absolutely no assurance that it was not |
17 |
poisonned. In effect, I have to trust the people that grew and collected the |
18 |
oranges (in our case the people that programmed the source package), the |
19 |
people that pressed the oranges and put the juice into a bottle (the devs who |
20 |
design the ebuild), the people who conveyed the bottle to my local |
21 |
supermarket (i.e people that manage the mirrors) not to have put poison in my |
22 |
orange juice. Moreover, I have to trust them to have stood guard to ensure |
23 |
that no third party had had access to my orange juice at any moment in the |
24 |
process to put poison in it. However, there I was, drinking it. And I would |
25 |
not for the life of me demand that my orange juice be signed digitally to |
26 |
ensure that it is safe to drink. |
27 |
|
28 |
The thing is, I trust the package's devs, I trust the Gentoo devs, I trust the |
29 |
mirror maintainers, I trust their ISP and mine. So I actually do not see the |
30 |
problem we have here. And just for the sake of the analogy, yes it is |
31 |
actually quite as easy to poison my orange juice as to compromise a package |
32 |
at any stage. |
33 |
|
34 |
Again, I do not know if this is relevant, but if it is not, I would really |
35 |
like to know why I am wrong to consider things this way. |
36 |
|
37 |
-- Jonathan |
38 |
|
39 |
Le Dimanche 7 Novembre 2004 18:52, Dan Margolis a écrit : |
40 |
> gpgkeys: WARNING: this is an *experimental* HKP interface! |
41 |
> gpgkeys: key B0CED9A149F69BF6 not found on keyserver |
42 |
> |
43 |
> Andreas Waschbuesch wrote: |
44 |
> > I could open some - as ist seems - "usefull" sourceforge-project and |
45 |
> > inject any "additional" code on gentoo systems, while submitting a |
46 |
> > perfectly "legal" ebuild, signed to "heavenly" trust. |
47 |
> |
48 |
> The point is that if we implement signing, a user can say, ``Well, I |
49 |
> distrust the authors of this sourceforge project'' if they wish. But if |
50 |
> we do not, they may trust the authors and yet still not be able to trust |
51 |
> the source. |
52 |
> |
53 |
> So the reasonable, expected behavior from portage is that the source |
54 |
> downloaded is the source it claims to be. If we do not trust the |
55 |
> original source, we needn't install the package, but if we do, we should |
56 |
> be able to trust the package implicity. Right now, we cannot trust the |
57 |
> package, even if we trust the original authors. Signing fixes this problem. |
58 |
> |
59 |
> Again, this is like saying that since we have not had the NSA conduct |
60 |
> background checks on each and every open source developer, we should not |
61 |
> trust their products. Well, fine, then don't install them. But if you |
62 |
> decide you trust the folks at kernel.org, or KDE, or GAIM, or whatever, |
63 |
> you should be able to trust the vanilla-sources ebuild, or the kde |
64 |
> ebuild, or the gaim ebuild. Right now, you cannot. So even when one does |
65 |
> choose to trust upstream, he cannot trust portage. That is broken. |
66 |
> |
67 |
> -- |
68 |
> Dan "KrispyKringle" Margolis |
69 |
> Security Coordinator/Audit Project, Gentoo Linux |
70 |
|
71 |
-- |
72 |
gentoo-security@g.o mailing list |