1 |
On Wed, Jan 07, 2015 at 03:10:13PM +0200, Alan McKinnon wrote: |
2 |
> On 07/01/2015 14:56, Rich Freeman wrote: |
3 |
> > On Tue, Jan 6, 2015 at 6:47 PM, William Hubbs <williamh@g.o> wrote: |
4 |
> >> |
5 |
> >> I am particularly concerned about packages with known security |
6 |
> >> vulnerabilities staying in the main tree masked. If people want to keep |
7 |
> >> using those packages, I don't want to stop them, but packages like this |
8 |
> >> should not be in the main tree. |
9 |
> >> |
10 |
> > |
11 |
> > Is this policy documented anywhere? If not, I'd be interested in what |
12 |
> > the general sense of the community is here, and this might be an |
13 |
> > appropriate topic for the next Council meeting. |
14 |
> > |
15 |
> > I guess my question is what harm does it cause to have masked packages |
16 |
> > in the main tree, where they at least benefit from other forms of QA |
17 |
> > (eclass fixes, etc)? The mask messages clearly point out the security |
18 |
> > issues, so anybody who unmasks them is making an informed decision. |
19 |
> > If they just move to some overlay most likely they won't have any |
20 |
> > warnings and people will just figure that they're one of 10k other |
21 |
> > packages that someone doesn't want to bother getting into the tree. |
22 |
> > |
23 |
> > I'll go ahead and reply to the council agenda thread with this, and |
24 |
> > I'd be interested in what the general sense of the rest of the |
25 |
> > community is here. |
26 |
> |
27 |
> |
28 |
> I always thought the (informal, ad-hoc) policy for buildable, working |
29 |
> packages with security bugs was to p.mask them and let the user decide. |
30 |
> For all the reasons you cite. |
31 |
> |
32 |
> And that packages are only removed from the tree when they don't build, |
33 |
> don't work, upstream is gone and took their sources with them, etc, etc. |
34 |
|
35 |
My understanding of p.mask is it is never permanent. Things go in |
36 |
there until they get fixed or eventually removed. |
37 |
|
38 |
p.masked packages do not directly benefit from any forms of qa (eclass |
39 |
fixes, etc). |
40 |
|
41 |
I don't think, for example, we test eclass changes to see if they |
42 |
break masked packages. |
43 |
|
44 |
Also, as far as I know, we don't use p.masked packages as a |
45 |
way to keep eclasses in the tree do we -- for example, (I haven't looked |
46 |
at the code), but I'm guessing that a number of these packages use |
47 |
games.eclass which is on the way out. If we say we can't get rid of |
48 |
these packages, we may not be able to get rid of games.eclass. |
49 |
|
50 |
It is unlikely as well that masked packages are actively maintained at |
51 |
all, especially those that have been setting in the tree masked for |
52 |
multiple years. You are basically asking that we keep bitrotting broken |
53 |
packages in the tree. |
54 |
|
55 |
William |