1 |
This may seem quite simple, but i completely agree with you. |
2 |
|
3 |
I find unless the system were built completely transparent, it would be more trouble for not much more security... |
4 |
|
5 |
|
6 |
On 18 Feb 2002 00:13:33 -0500 |
7 |
"Bruce A. Locke" <blocke@××××××.org> wrote: |
8 |
|
9 |
> On Sun, 2002-02-17 at 22:56, Nils Ohlmeier wrote: |
10 |
> |
11 |
> > Maybe the developers are more busy with other things, but its never to early |
12 |
> > to think about security. |
13 |
> |
14 |
> If this matter is important to you then please feel free to work on |
15 |
> adding such functionality to portage. I would like to see a prototype |
16 |
> of said system. :) |
17 |
> |
18 |
> Just a tip though: any such system should be easy to use for the |
19 |
> developer and end user, and happen pretty much automatically for |
20 |
> developers. I'm personally not going to be very friendly towards any |
21 |
> system that requires me to do gnupg commands manually and worry about |
22 |
> keys every time I want to check in a package, etc. And only the most |
23 |
> paranoid users are going to go through the trouble of manually verifying |
24 |
> each package (meaning it wouldn't be used by most users). |
25 |
> |
26 |
> It may sound lazy but considering upstream packages are not signed, most |
27 |
> developers don't even know each other in real life, and you are |
28 |
> implicitly trusting anyone who has the key and cvs access (any true |
29 |
> paranoid would see what I'm talking about). Unless the system is simple |
30 |
> and transparent for developers and end users its (disclaimer: in my view |
31 |
> and my view alone) a pain that gives people a false sense of security |
32 |
> about software they are downloading from the internet. |
33 |
> |
34 |
> There is also the issue of keys... who holds them, etc. The signing of |
35 |
> packages could create political side effects and formalities. We have |
36 |
> quite a few developers with CVS access. This means we are going to be |
37 |
> sharing keys on multiple machines or have to go through a pain in the |
38 |
> arse every time we want to check a package in. |
39 |
> |
40 |
> Such a system may force the solid formation of "teams" and encourage a |
41 |
> more unfriendly BSD-style core development model. As a gentoo developer |
42 |
> I like being able to work many different aspects of gentoo whenever I |
43 |
> feel like it. And if a find an annoying bug I wish to fix, I like being |
44 |
> able to fix it, rather then spending time asking whichever "team" is in |
45 |
> charge of said package and having to ask for permission or whatever. |
46 |
> (ok, I'm exagurating, but I've heard too many horror stories from the |
47 |
> history of the *BSDs) |
48 |
> |
49 |
> If we decide to avoid a team based structure, then we are going to have |
50 |
> to worry about individual keys. Most packages, although sometimes |
51 |
> marked as having a maintainer, do not really have maintainers set in |
52 |
> stone. Most of the packages are freely modified by any developer who |
53 |
> has a real reason to make changes to said packages. Although there are |
54 |
> exceptions, portage does have maintainers due to its importance and the |
55 |
> fact its a gentoo creation (we are the upstream maintainers). Also if |
56 |
> you as a developer are aware that someone is working on a package or has |
57 |
> a pet project, its considered good etiquite to ask them first (chances |
58 |
> are they are already working on the issue anyways). So that means we |
59 |
> would either have to assign maintainers with keys to specific packages |
60 |
> and have changes cleared through them, or have the system check every |
61 |
> possible key against the package to see if the package has a valid |
62 |
> signature from 1 of 30 or so developers (I'm guessing about that |
63 |
> number). |
64 |
> |
65 |
> Another alternative is a global key. One key shared among all |
66 |
> developers... IMHO, there isn't much point of signing after that... if |
67 |
> the key is leaked (accounts hacked, etc) we'd have to get in touch with |
68 |
> all developers, reissue keys, and resign all packages after verifying |
69 |
> them all. |
70 |
> |
71 |
> Just my two cents on the issue, feel free to flame or just call me |
72 |
> paranoid, crazy, etc ;) Personally, I liked the open (more carefree?) |
73 |
> attitude towards the beginning of the project and I'd hate to see that |
74 |
> go away because of its increased popularity :) |
75 |
> |
76 |
> -- |
77 |
> |
78 |
> Bruce A. Locke |
79 |
> blocke@××××××.org |
80 |
> |
81 |
> "Those that would give up a necessary freedom for temporary |
82 |
> safety deserve neither freedom nor safety." |
83 |
> -- Ben Franklin |
84 |
> |
85 |
> |
86 |
> _______________________________________________ |
87 |
> gentoo-dev mailing list |
88 |
> gentoo-dev@g.o |
89 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |