1 |
Chris Gianelloni wrote: |
2 |
> On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: |
3 |
>>> I know that when I spoke of security, I was not only talking about the |
4 |
>>> security of letting non-developers commit to an overlay that is, by |
5 |
>>> design, for end users, but also of the implications of ensuring that any |
6 |
>>> packages in these overlays are not vulnerable to exploits. |
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 |
|
21 |
The approach is to get them maintained... But there is a chance that |
22 |
there'll be security bugs in it, I admit that. Once we know about it, we |
23 |
p.mask it as we have support for it in the overlay. I'm following most |
24 |
common vuln lists and run some automated scripts already on installed |
25 |
packages, should be easy to adapt them to search one other dir as well. |
26 |
|
27 |
>>>> 2) responsibility |
28 |
>>>> |
29 |
> |
30 |
> No. It clearly says that you would be doing the basic QA checks and |
31 |
> repoman checking on initial commit. You even said it right above where |
32 |
> I commented! |
33 |
|
34 |
You're doing some witch hunting here... I said we keep an eye on |
35 |
non-devs commits. |
36 |
|
37 |
> |
38 |
>>> Honestly, having to break out a subversion client to check a fix |
39 |
>>> immediately sounds like extra work. It is usually much easier to simply |
40 |
>>> look at the attachment online and make a decision immediately. |
41 |
>> You don't need a subversion client, you perhaps notice the http in front |
42 |
>> of the url.. just open it up in your browser and you get the source |
43 |
>> immediately. |
44 |
> |
45 |
> Umm... so now I need to go and instead of clicking a nice link in |
46 |
> bugzilla, trawl through the subversion repository and find what I'm |
47 |
> looking for? How exactly is downloading things via http any different |
48 |
> than downloading them from bugzilla, which is also http? |
49 |
|
50 |
the key difference is that you only need one wget command to get a |
51 |
completely prepared dir to work on, no ebuild renaming manual files/ |
52 |
population needed. |
53 |
|
54 |
> Now, I know that you're not an idiot, so please don't treat me like one. |
55 |
|
56 |
Was really not the intention.. You keeped the svn requirement which is |
57 |
simply wrong. Needed to make that clear. |
58 |
|
59 |
>> Or, if you want some history like sources.g.o, you can do so as well here: |
60 |
>> http://overlays.gentoo.org/proj/sunrise/browser/ |
61 |
> |
62 |
> Excellent. So we're moving the history from being in a single location |
63 |
> (the bug) to being in multiple locations. That will definitely improve |
64 |
> the development process. Another thing that people tend to miss is that |
65 |
> not all improved versions of ebuilds submitted to bugzilla are done byt |
66 |
> he original authors. There are many cases where an initial ebuild is |
67 |
> done, a developer makes comments on what needs to be changed, and |
68 |
> *another* contributor gives a fixed ebuild. How exactly will this |
69 |
> streamline that process? No offense, but everything I have seen looks |
70 |
> as if it will add even *more* overhead to actually getting packages into |
71 |
> the tree. The only thing this seems to provide is a half-baked |
72 |
> repository for the users to get marginally-tested ebuilds for software |
73 |
> that wasn't interesting enough for inclusion in the tree. |
74 |
|
75 |
we want to encourage users to contribute and if they do good |
76 |
contributions in bugzilla they get commit access to the overlay. and |
77 |
then the workload is drastically reduced... |
78 |
|
79 |
>>> How exactly are they |
80 |
>>> supposed to know that this user has pam_skey even *available* to them |
81 |
>>> when all they see as an overlay is "sunrise" and not the |
82 |
>>> project-specific overlays that overlays.gentoo.org was designed for? |
83 |
>> Well as the ebuilds in there already have open bugs, comments can be |
84 |
>> attached there. |
85 |
> |
86 |
> This is a bug for an ebuild that the user does not think is related to |
87 |
> the pam_skey. Go back and read what I wrote. |
88 |
> |
89 |
|
90 |
it was agreed upon that we don't keep extra bugzilla or whatever for all |
91 |
things on o.g.o but keep track of all issues within bugs.g.o. and btw, |
92 |
most work on "new" bugs is done by bug wranglers and not the common |
93 |
devs. So if they say the workload from it is too high, I'll take it as |
94 |
valid reason as they have to handle it. |
95 |
|
96 |
>> Secondly, the portage team already integrates a patch to show you a |
97 |
>> bright warning in the error that you use an overlay... also, if you take |
98 |
>> a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast |
99 |
>> that in case you don't find the ebuild in tree that it doesn't belong |
100 |
>> there. (We even get bugs originating at other overlay's ebuils...) |
101 |
> |
102 |
> Again, read what I wrote. I said that the developer would see "sunrise" |
103 |
> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated |
104 |
> without considering. This is a login bug. At no point did they make |
105 |
> mention of having installed pam_skey from this overlay. This means that |
106 |
> I, as the developer getting this bug, am now responsible for looking at |
107 |
> *every package* in the sunrise overlay to determine if *any* of them |
108 |
> could *possibly* be affecting this package or causing this bug, then |
109 |
> asking the user if they have any of them installed. |
110 |
|
111 |
why would a pam dev get this bug? as far as I know bug wranglers work, a |
112 |
check whether the ebuild is in tree is one of the first ones... So the |
113 |
chance that it really hits the pam dev is damn small... |
114 |
We're not the first large overlay project, there are other ones out |
115 |
there already and these "wrong" bugs aren't a new thing arising here... |
116 |
|
117 |
> Wouldn't this process be *infinitely* easier if instead of "sunrise" |
118 |
> there was a "pam" overlay with *only* the pam stuff? |
119 |
|
120 |
Then the pam devs are responsible for all the things with it. As it |
121 |
would surely be hosted on o.g.o then, we'll notice it and either shift |
122 |
all ebuilds we have in the sunrise tree over or do whatever is fine with |
123 |
pam devs. If they really dislike the m-w bugs out of their control, then |
124 |
a friendly note on irc, a friendly mail or whatever is enough and we |
125 |
won't touch things of them then... |
126 |
|
127 |
> That is *exactly* what we get with the other overlays like php and |
128 |
> vmware. I *know* that if I'm looking at a glibc bug and the user has |
129 |
> "php" as an overlay, that it isn't going to be a concern. |
130 |
|
131 |
Well we don't keep ebuilds in there which have a maintainer in contrast |
132 |
to the php overlay. they may even keep newer versions of in-tree |
133 |
packages in their overlays. |
134 |
|
135 |
>>> All of the time wasted to determine that the user has done something |
136 |
>>> unsupported to break their system is time that this developer could be |
137 |
>>> working on a problem with a package that is actually in the portage |
138 |
>>> tree, which is our primary product. |
139 |
>> bug wranglers already do this job currently... |
140 |
> |
141 |
> They do this in a very quick and cursory manner. They do a pretty good |
142 |
> job of it, but there are countless bugs which they do not catch that are |
143 |
> not assigned properly or end up being invalid due to user negligence. |
144 |
> The bug wranglers cannot be *expected* to perform this level of service, |
145 |
> lest they burn out and run away within a couple weeks. ;] |
146 |
|
147 |
Well a simple grep for "sunrise" in there will show the needed thing... |
148 |
|
149 |
And, sorry, if one or another bug slips through. Wranglers are humans as |
150 |
well and humans make mistakes. Also you can't expect them to know about |
151 |
all issues. But that is a bit off-topic here. |
152 |
Just a last note on it: the main bug wrangler is helping us as well as |
153 |
commiting so I guess he notices the problems with sunrise... |
154 |
|
155 |
>>> You miss something. Things in this overlay still don't make it into the |
156 |
>>> official tree unless a maintainer picks it up. Taking an ebuild from |
157 |
>>> bugzilla and being responsible for it and taking an ebuild from an |
158 |
>>> overlay and being responsible for it have the exact same cost on |
159 |
>>> developer resources. Someone *still* has to maintain it. |
160 |
>> Yup, but the proxy maintainerships are much easier to track as they're |
161 |
>> done on one central place... |
162 |
> |
163 |
> This is a prime example of totally glossing over any discussion to make |
164 |
> it sound promising for you. How exactly is a proxy maintainer going to |
165 |
> know that a new version of an ebuild has been committed? Either by |
166 |
> watching the overlay like a hawk, or when the maintainer |
167 |
> emails/pings/whatever and lets him know that there's a new version. How |
168 |
> exactly is this easier to track? Even better, if I am the proxy |
169 |
> maintainer for a particular set of ebuilds for one or more |
170 |
> user/maintainers, why do I need it in your big, bloated, and completely |
171 |
> inappropriately-named "sunshine" overlay versus a developer overlay of |
172 |
> my own? After all, I am the *only* proxy maintainer. Why should there |
173 |
> be the added *insecurity* of allowing any number of people that *I* |
174 |
> might not trust complete access to the small number of packages where I |
175 |
> am the proxy? |
176 |
|
177 |
Tracking: |
178 |
First we want people to get used to it. Adding some random features like |
179 |
automated email upon a special commit can be added easily with just two |
180 |
lines in the post-commit hook... |
181 |
|
182 |
Dev-Overlay: |
183 |
Well you're free to use the dev overlay for it. But if you keep it on |
184 |
the sunrise overlay, it (hopefully) gets more tested. |
185 |
|
186 |
Greetz, |
187 |
Jokey |