Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 03:55 AM, Rich Freeman wrote:
> On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand <k_f@g.o> wrote:
>> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>>>
>>> My point is that users must be informed about security problem, but
>>> they still should have a choice. So it should be either a rule
>>> "mask without removal" or clear guidelines when to remove a
>>> package and when to not.
>>
>> At some point, of a package does not belong in the main tree due to
>> security vulnerabilities, they can still be kept in an overlay by a
>> respective project without it impacting other users. I'm not convinced
>> that impacts the overall user experience of other Gentoo users.
>>
>
> Is there any reason that this can't be left to maintainer discretion?
> The package is masked and clearly advertises its security issue.  The
> user can make an informed choice.  Do we really need to force the
> issue further?  What is the benefit to Gentoo in doing so?
>

In most cases lack of maintainer participation is likely the issue to
begin with. The primary issue with a package mask of this nature is that
it is more permanent than temporary in nature. To what extent would
other package maintainers need to take it into consideration e.g wrt
depgraph breakages (say this is a lower slotted version or last version
that supports a specific arch).

Granted that isn't much of an issue from the security point of view, but
goes more over on QA - the primary reason it isn't explicit in the draft
GLEP is that specific rules are difficult to write to cover all
situations and as such needs either a lot of preparation to write or
will cause issues down the line. The accountability aspects of things is
therefore more important than the rules themselves.

Quite frankly I thought I left enough of maintainer discretion when
stating:
* The Security Project does not want to override the maintainer's
autonomy, but
  if inactive might be required to fix a security vulnerability by means of
  version bump or application of a patch in a revision bump.
* If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer
  it might require a package mask. Such mask should never break the
stable dependency tree.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3