1 |
On Tuesday, July 5, 2016 6:09:38 AM JST, Rich Freeman wrote: |
2 |
> On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko <bircoph@g.o> wrote: |
3 |
>> The same applies for the tree-cleaners team. While their job is |
4 |
>> very important, sometimes they are too hasty, like in commit |
5 |
>> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and |
6 |
>> works fine, have no critical bugs opened, the sheer fact that |
7 |
>> upstream as inactive and package has no maintainer is no valid to ... |
8 |
> |
9 |
> ++ |
10 |
> |
11 |
> To treeclean a package it should be both unmaintained and have a |
12 |
> significant QA issue of some kind. Simply having open bugs shouldn't |
13 |
> be sufficient, and of course if it works fine there is no reason to |
14 |
> boot it. Now, if the package is a blocker on some EAPI retirement or |
15 |
> other tree-wide operation, that would be a great reason to treeclean |
16 |
> it if it is unmaintained. |
17 |
> |
18 |
> Security issues should warrant masking fairly easily, but only if the |
19 |
> maintainer is unresponsive or the package is unmaintained (or we're |
20 |
> talking an end-of-the-world security issue). If the maintainer is |
21 |
> about to commit a fix or disputes that the issue applies in the |
22 |
> package, it is best to just work with them. Otherwise users will just |
23 |
> end up putting entries in package.unmask that could cause them issues |
24 |
> later. |
25 |
> |
26 |
|
27 |
That is exactly what happened here. We worked with Anthony following the |
28 |
p.mask, and we have always done so with all packages that resulted in a |
29 |
mask. Often, it simply highlights to the maintainer that a security issue |
30 |
is outstanding and needs attention. It also protects the user regardless |
31 |
of the vulnerabilities severity. Sometimes this a failure on upstream, |
32 |
which also raises additional concerns if multiple vulnerabilities exist. |
33 |
In this particular case the issues were outstanding for years. |
34 |
|
35 |
Most developers coordinate very well with us regarding their packages. |
36 |
Sometimes that involves relocation of sources upstream, reversioning |
37 |
upstream, etc. While we try to resolve it on our own, the expertise of the |
38 |
developer on that package is a tremendous asset in ensuring the package is |
39 |
no longer vulnerable. We even patch or verify source code changes |
40 |
ourselves to resolve bugs. |
41 |
|
42 |
In regards to the media-video/motion mask, you can follow up with the bug |
43 |
and see the continued efforts. Users have responded with relocated sources |
44 |
that have a fix for the package. Something that only familiarity or |
45 |
endless digging would bear fruit on. We are actively working to mitigate |
46 |
the vulnerability and get the package unmasked for the community. We are |
47 |
not just trying to kill things to kill them. |
48 |
|
49 |
The subject of this particular mailing list post is a little alarming and |
50 |
over reactive. We are not running around p.masking everyone's packages, but |
51 |
issues that have been outstanding for years often result in such courses of |
52 |
action. I personally told Anthony I should have requested his assistance |
53 |
initially on the matter, and I do apologize for that. He is an active |
54 |
developer who would respond in a timely manner. So once again, I do |
55 |
apologize. |
56 |
|
57 |
Finally, that does not dissolve the developer of providing usable, |
58 |
substantiated, and verifiable information regarding the vulnerabilities. |
59 |
The idea that a developer gets to choose whether or not they do so should |
60 |
not be considered. Anthony's verbiage on Freenode was very frank, in that |
61 |
if he chose to do so he would. We ask for all developers to assist and |
62 |
work together with us to fix these issues. You can see the fruits of such |
63 |
information from the developer following Alex Legler's comments on the bug |
64 |
and my follow up actions. |
65 |
|
66 |
-Aaron |