Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items
Date: Thu, 08 Jan 2015 15:05:39
Message-Id: 20150108150533.GA14817@linux1
In Reply to: Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items by Andrew Savchenko
1 On Thu, Jan 08, 2015 at 12:21:18AM +0300, Andrew Savchenko wrote:
2 > Hello,
3 >
4 > On Wed, 7 Jan 2015 13:35:17 -0600 William Hubbs wrote:
5 > > If we want to keep proprietary packages with security issues in the
6 > > tree, they should be marked as proprietary in package.mask so it is
7 > > obvious that they will never be fixed.
8 > >
9 > > If there is an upstream security issue with a non-proprietary
10 > > package:
11 > >
12 > > When a version or revision with the fix is available, it should be
13 > > fast stabled. Once that is done, all older versions should be removed
14 > > if possible. if this is not possible right away, the older versions
15 > > should go in p.mask with a removal date.
16 > >
17 > > Thoughts?
18 >
19 > What about open source packages with no fixes or where doesn't
20 > consider bug as a security issue? Good example is
21 > games-roguelike/nethack, bug 125902, where upstream doesn't
22 > consider issue as a security problem and for many setups (e.g.
23 > personal device with single user is the games group) this is not a
24 > problem at all?
25
26 I just read through this bug, and I see it the same way most people who
27 posted to the bug see it. It is a major flaw in how our games policies
28 were designed. Since it is known that we are moving toward getting rid
29 of games.eclass, and this is a popular game, whoever takes over
30 maintenance should make fixing this a high priority.
31
32 If I were taking over this game, I would immediately look into rewriting
33 the ebuild to not use games.eclass.
34
35 > IMO packages (not specific versions, but whole packages) should not
36 > be removed if they work. Maybe masked, but no more.
37
38 The problem is that defining "work" is too vague. I would rather not see
39 something like this statement made into a distro-wide policy.
40
41 William

Attachments

File name MIME type
signature.asc application/pgp-signature