Re: [gentoo-dev] why is the security team running around p.masking packages

[Aaron Bauman]

On Tuesday, July 5, 2016 6:09:38 AM JST, Rich Freeman wrote:
> On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko <bircoph@g.o> wrote:
>> The same applies for the tree-cleaners team. While their job is
>> very important, sometimes they are too hasty, like in commit
>> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
>> works fine, have no critical bugs opened, the sheer fact that
>> upstream as inactive and package has no maintainer is no valid to ...
>
> ++
>
> To treeclean a package it should be both unmaintained and have a
> significant QA issue of some kind.  Simply having open bugs shouldn't
> be sufficient, and of course if it works fine there is no reason to
> boot it.  Now, if the package is a blocker on some EAPI retirement or
> other tree-wide operation, that would be a great reason to treeclean
> it if it is unmaintained.
>
> Security issues should warrant masking fairly easily, but only if the
> maintainer is unresponsive or the package is unmaintained (or we're
> talking an end-of-the-world security issue).  If the maintainer is
> about to commit a fix or disputes that the issue applies in the
> package, it is best to just work with them.  Otherwise users will just
> end up putting entries in package.unmask that could cause them issues
> later.
>

That is exactly what happened here.  We worked with Anthony following the 
p.mask, and we have always done so with all packages that resulted in a 
mask.  Often, it simply highlights to the maintainer that a security issue 
is outstanding and needs attention.  It also protects the user regardless 
of the vulnerabilities severity.  Sometimes this a failure on upstream, 
which also raises additional concerns if multiple vulnerabilities exist.  
In this particular case the issues were outstanding for years.

Most developers coordinate very well with us regarding their packages.  
Sometimes that involves relocation of sources upstream, reversioning 
upstream, etc.  While we try to resolve it on our own, the expertise of the 
developer on that package is a tremendous asset in ensuring the package is 
no longer vulnerable.  We even patch or verify source code changes 
ourselves to resolve bugs.

In regards to the media-video/motion mask, you can follow up with the bug 
and see the continued efforts.  Users have responded with relocated sources 
that have a fix for the package.  Something that only familiarity or 
endless digging would bear fruit on.  We are actively working to mitigate 
the vulnerability and get the package unmasked for the community.  We are 
not just trying to kill things to kill them.

The subject of this particular mailing list post is a little alarming and 
over reactive. We are not running around p.masking everyone's packages, but 
issues that have been outstanding for years often result in such courses of 
action.  I personally told Anthony I should have requested his assistance 
initially on the matter, and I do apologize for that.  He is an active 
developer who would respond in a timely manner.  So once again, I do 
apologize.

Finally, that does not dissolve the developer of providing usable, 
substantiated, and verifiable information regarding the vulnerabilities.  
The idea that a developer gets to choose whether or not they do so should 
not be considered.  Anthony's verbiage on Freenode was very frank, in that 
if he chose to do so he would.  We ask for all developers to assist and 
work together with us to fix these issues.  You can see the fruits of such 
information from the developer following Alex Legler's comments on the bug 
and my follow up actions.

-Aaron