On Wed, Jan 07, 2015 at 03:10:13PM +0200, Alan McKinnon wrote: > On 07/01/2015 14:56, Rich Freeman wrote: > > On Tue, Jan 6, 2015 at 6:47 PM, William Hubbs <willi...@gentoo.org> wrote: > >> > >> I am particularly concerned about packages with known security > >> vulnerabilities staying in the main tree masked. If people want to keep > >> using those packages, I don't want to stop them, but packages like this > >> should not be in the main tree. > >> > > > > Is this policy documented anywhere? If not, I'd be interested in what > > the general sense of the community is here, and this might be an > > appropriate topic for the next Council meeting. > > > > I guess my question is what harm does it cause to have masked packages > > in the main tree, where they at least benefit from other forms of QA > > (eclass fixes, etc)? The mask messages clearly point out the security > > issues, so anybody who unmasks them is making an informed decision. > > If they just move to some overlay most likely they won't have any > > warnings and people will just figure that they're one of 10k other > > packages that someone doesn't want to bother getting into the tree. > > > > I'll go ahead and reply to the council agenda thread with this, and > > I'd be interested in what the general sense of the rest of the > > community is here. > > > I always thought the (informal, ad-hoc) policy for buildable, working > packages with security bugs was to p.mask them and let the user decide. > For all the reasons you cite. > > And that packages are only removed from the tree when they don't build, > don't work, upstream is gone and took their sources with them, etc, etc.
My understanding of p.mask is it is never permanent. Things go in there until they get fixed or eventually removed. p.masked packages do not directly benefit from any forms of qa (eclass fixes, etc). I don't think, for example, we test eclass changes to see if they break masked packages. Also, as far as I know, we don't use p.masked packages as a way to keep eclasses in the tree do we -- for example, (I haven't looked at the code), but I'm guessing that a number of these packages use games.eclass which is on the way out. If we say we can't get rid of these packages, we may not be able to get rid of games.eclass. It is unlikely as well that masked packages are actively maintained at all, especially those that have been setting in the tree masked for multiple years. You are basically asking that we keep bitrotting broken packages in the tree. William
signature.asc
Description: Digital signature
