1 |
On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: |
2 |
> > I know that when I spoke of security, I was not only talking about the |
3 |
> > security of letting non-developers commit to an overlay that is, by |
4 |
> > design, for end users, but also of the implications of ensuring that any |
5 |
> > packages in these overlays are not vulnerable to exploits. |
6 |
> |
7 |
> You're right here, there is a chance that your system gets vulnerable. |
8 |
> But this isn't limited to this one overlay. All overlays are affected here. |
9 |
|
10 |
Not like you think that they are. Let me try to make this clearer. |
11 |
|
12 |
The php overlay is maintained by the php developers. They are |
13 |
intimately aware of the issues with their package, and are probably |
14 |
aware of any security bugs before the rest of us. |
15 |
|
16 |
You are talking about a random collection of ebuilds with absolutely no |
17 |
cohesiveness other than they were submitted to bugzilla. How are you |
18 |
going to maintain any form of security on this project? |
19 |
|
20 |
> >> 2) responsibility |
21 |
> >> |
22 |
> >> As already mentioned at 1), it is an overlay. The devs on sunrise do |
23 |
> >> keep an eye on it and all ebuilds do have to pass at least repoman and |
24 |
> >> some basic QA checks (currently done when porting them from bugs.g.o) so |
25 |
> >> that they don't do some rm -rf / thing. They should be improved by the |
26 |
> >> contributors then so that we have two things here: a) a contributor who |
27 |
> >> can contribute good-quality ebuils and b) a good ebuild to be picked up |
28 |
> >> by a dev and ported to the tree |
29 |
> > |
30 |
> > The problem is that you are only checking on the initial commit. Go |
31 |
> > back to point #1 (security). |
32 |
> |
33 |
> You just assume this, no real reason/example for it. |
34 |
|
35 |
No. It clearly says that you would be doing the basic QA checks and |
36 |
repoman checking on initial commit. You even said it right above where |
37 |
I commented! |
38 |
|
39 |
> > Honestly, having to break out a subversion client to check a fix |
40 |
> > immediately sounds like extra work. It is usually much easier to simply |
41 |
> > look at the attachment online and make a decision immediately. |
42 |
> |
43 |
> You don't need a subversion client, you perhaps notice the http in front |
44 |
> of the url.. just open it up in your browser and you get the source |
45 |
> immediately. |
46 |
|
47 |
Umm... so now I need to go and instead of clicking a nice link in |
48 |
bugzilla, trawl through the subversion repository and find what I'm |
49 |
looking for? How exactly is downloading things via http any different |
50 |
than downloading them from bugzilla, which is also http? |
51 |
|
52 |
Now, I know that you're not an idiot, so please don't treat me like one. |
53 |
|
54 |
> Or, if you want some history like sources.g.o, you can do so as well here: |
55 |
> http://overlays.gentoo.org/proj/sunrise/browser/ |
56 |
|
57 |
Excellent. So we're moving the history from being in a single location |
58 |
(the bug) to being in multiple locations. That will definitely improve |
59 |
the development process. Another thing that people tend to miss is that |
60 |
not all improved versions of ebuilds submitted to bugzilla are done byt |
61 |
he original authors. There are many cases where an initial ebuild is |
62 |
done, a developer makes comments on what needs to be changed, and |
63 |
*another* contributor gives a fixed ebuild. How exactly will this |
64 |
streamline that process? No offense, but everything I have seen looks |
65 |
as if it will add even *more* overhead to actually getting packages into |
66 |
the tree. The only thing this seems to provide is a half-baked |
67 |
repository for the users to get marginally-tested ebuilds for software |
68 |
that wasn't interesting enough for inclusion in the tree. |
69 |
|
70 |
> > Except that I can *look* at an ebuild without having to break out a |
71 |
> > subversion client currently. |
72 |
> See my answer in 3) |
73 |
|
74 |
See mine. ;] |
75 |
|
76 |
> > How exactly are they |
77 |
> > supposed to know that this user has pam_skey even *available* to them |
78 |
> > when all they see as an overlay is "sunrise" and not the |
79 |
> > project-specific overlays that overlays.gentoo.org was designed for? |
80 |
> |
81 |
> Well as the ebuilds in there already have open bugs, comments can be |
82 |
> attached there. |
83 |
|
84 |
This is a bug for an ebuild that the user does not think is related to |
85 |
the pam_skey. Go back and read what I wrote. |
86 |
|
87 |
> Secondly, the portage team already integrates a patch to show you a |
88 |
> bright warning in the error that you use an overlay... also, if you take |
89 |
> a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast |
90 |
> that in case you don't find the ebuild in tree that it doesn't belong |
91 |
> there. (We even get bugs originating at other overlay's ebuils...) |
92 |
|
93 |
Again, read what I wrote. I said that the developer would see "sunrise" |
94 |
in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated |
95 |
without considering. This is a login bug. At no point did they make |
96 |
mention of having installed pam_skey from this overlay. This means that |
97 |
I, as the developer getting this bug, am now responsible for looking at |
98 |
*every package* in the sunrise overlay to determine if *any* of them |
99 |
could *possibly* be affecting this package or causing this bug, then |
100 |
asking the user if they have any of them installed. |
101 |
|
102 |
Wouldn't this process be *infinitely* easier if instead of "sunrise" |
103 |
there was a "pam" overlay with *only* the pam stuff? |
104 |
|
105 |
That is *exactly* what we get with the other overlays like php and |
106 |
vmware. I *know* that if I'm looking at a glibc bug and the user has |
107 |
"php" as an overlay, that it isn't going to be a concern. |
108 |
|
109 |
> > All of the time wasted to determine that the user has done something |
110 |
> > unsupported to break their system is time that this developer could be |
111 |
> > working on a problem with a package that is actually in the portage |
112 |
> > tree, which is our primary product. |
113 |
> |
114 |
> bug wranglers already do this job currently... |
115 |
|
116 |
They do this in a very quick and cursory manner. They do a pretty good |
117 |
job of it, but there are countless bugs which they do not catch that are |
118 |
not assigned properly or end up being invalid due to user negligence. |
119 |
The bug wranglers cannot be *expected* to perform this level of service, |
120 |
lest they burn out and run away within a couple weeks. ;] |
121 |
|
122 |
> > You miss something. Things in this overlay still don't make it into the |
123 |
> > official tree unless a maintainer picks it up. Taking an ebuild from |
124 |
> > bugzilla and being responsible for it and taking an ebuild from an |
125 |
> > overlay and being responsible for it have the exact same cost on |
126 |
> > developer resources. Someone *still* has to maintain it. |
127 |
> |
128 |
> Yup, but the proxy maintainerships are much easier to track as they're |
129 |
> done on one central place... |
130 |
|
131 |
This is a prime example of totally glossing over any discussion to make |
132 |
it sound promising for you. How exactly is a proxy maintainer going to |
133 |
know that a new version of an ebuild has been committed? Either by |
134 |
watching the overlay like a hawk, or when the maintainer |
135 |
emails/pings/whatever and lets him know that there's a new version. How |
136 |
exactly is this easier to track? Even better, if I am the proxy |
137 |
maintainer for a particular set of ebuilds for one or more |
138 |
user/maintainers, why do I need it in your big, bloated, and completely |
139 |
inappropriately-named "sunshine" overlay versus a developer overlay of |
140 |
my own? After all, I am the *only* proxy maintainer. Why should there |
141 |
be the added *insecurity* of allowing any number of people that *I* |
142 |
might not trust complete access to the small number of packages where I |
143 |
am the proxy? |
144 |
|
145 |
-- |
146 |
Chris Gianelloni |
147 |
Release Engineering - Strategic Lead |
148 |
x86 Architecture Team |
149 |
Games - Developer |
150 |
Gentoo Linux |