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

On 03/15/2017 08:12 AM, Alexis Ballier wrote: > On Tue, 14 Mar 2017 19:55:44 -0400 > > > Agreed, but I was under the impression that sometimes sec. team was > waiting for cleanup to close a bug. If you've just done the analysis > that it is the only thing left, just do it and close the bug,

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

On Tue, 14 Mar 2017 19:55:44 -0400 Yury German wrote: > > On Mar 12, 2017, at 4:14 AM, Alexis Ballier > > wrote: > > > > > > Also, it'd be nice to have something more formal for sec. cleanup: > > "After 30 days a sec. issue has been fixed, sec. team

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

Rick a very good message (and well thought out). On 3/13/17 4:33 PM, Rich Freeman wrote: > On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann wrote: > > The two areas that I see as possibly pushing security towards being a > special project are: > 1. Masking or otherwise

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

On 3/13/17 3:28 PM, Thomas Deutschmann wrote: > A lead is only needed if the team can't get a decision. > > Saying that the team could call for re-election if they don't like > lead's decision is ridiculous from my view: Like said it isn't the lead > who controls the direction. It is the lead

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

On 3/13/17 3:10 PM, Thomas Deutschmann wrote: > I completely disagree with that. > > The whole powerful lead/deputy thing is going in the wrong direction. > > We don't need that. Security project is nothing special and doesn't need > a strong lead with such a power to rule the entire Gentoo

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

On Tue, Mar 14, 2017 at 7:55 PM, Yury German wrote: > > > The maintainer also knows the package, dependencies, other bugs filed, etc. > Removing things for your > packages might be simple, but it is not the same across all packages and that > is the reason we ask the >

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

> On Mar 12, 2017, at 4:14 AM, Alexis Ballier wrote: > > > Also, it'd be nice to have something more formal for sec. cleanup: > "After 30 days a sec. issue has been fixed, sec. team is free to > cleanup old vulnerable versions.". I've seen too much pings by sec. > team

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

On 2017-03-13 22:47, Kristian Fiskerstrand wrote: > now I'm even more lost. Gentoo Developer quiz does not imply ebuild > repository access, we have current developers in the project without > tree access and they are doing an outstanding job, so depending on the > definition of "full membership"

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

On 2017-03-13 21:33, Rich Freeman wrote: > [...] > > And this is why I think you are talking past each other. Kristian is > thinking in terms of security being a special project, and Thomas is > thinking in terms of security being a normal project. Both are making > completely reasonable

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

On 03/13/2017 08:38 PM, Thomas Deutschmann wrote: > On 2017-03-12 19:35, Kristian Fiskerstrand wrote: >>> Why do Security Project members need to be ebuild devs? >>> Non ebuild developers can contribute by producing GLSAs, >>> for example. >> >> Where is that requirement stated? > > I agree with

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

On Monday, March 13, 2017 4:33:54 PM EDT Rich Freeman wrote: > On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann wrote: > > Looks like we are disagreeing about the role of a project lead. > > > > The primary goal of any Gentoo project is to group people working > > towards

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

On Mon, Mar 13, 2017 at 3:28 PM, Thomas Deutschmann wrote: > > Looks like we are disagreeing about the role of a project lead. > > The primary goal of any Gentoo project is to group people working > towards the same goal(s) in small, manageable groups. It shouldn't need > a

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

On 2017-03-12 19:35, Kristian Fiskerstrand wrote: >> Why do Security Project members need to be ebuild devs? >> Non ebuild developers can contribute by producing GLSAs, >> for example. > > Where is that requirement stated? I agree with Roy. That's also my reading of > * The applicant must have

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

On 2017-03-12 23:53, Kristian Fiskerstrand wrote: > On 03/11/2017 11:23 PM, Andrew Savchenko wrote: >> While the Deputy may be assigned, this still gives all power to >> single hands. Maybe it will be better to establish something like >> the Security Project Council (SPC)? E.g. three project

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

On Sun, Mar 12, 2017 at 02:54:22PM -0400, Rich Freeman wrote: > On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand > wrote: > > > > 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

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

On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > While the Deputy may be assigned, this still gives all power to > single hands. Maybe it will be better to establish something like > the Security Project Council (SPC)? E.g. three project members may > be elected to this SPC, so that all serious

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

On 03/12/2017 11:05 PM, Alexis Ballier wrote: >> The severity levels and timelines are already defined in the >> referenced vulnerability treatment policy. We might be able to >> incorporate this suggestion by stronger reference to that for >> timeline, but in the end that should be the internal

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

On Sun, 12 Mar 2017 19:59:11 +0100 Kristian Fiskerstrand wrote: > On 03/12/2017 09:14 AM, Alexis Ballier wrote: > > Most of it seems more appropriate for a project page to me and up to > > the sec. team, so I'll comment on the global parts only. > > > > The only global part I

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

On 03/12/2017 09:14 AM, Alexis Ballier wrote: > Most of it seems more appropriate for a project page to me and up to > the sec. team, so I'll comment on the global parts only. > > The only global part I see is the "Security package version/revision > bumps and package masks". This one would

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

On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand wrote: > > 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

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

On 03/12/2017 07:19 AM, Walter Dnes wrote: > - Typo... > Additional Security Project bugzilla notes > * The Security Project is except (should that read "exempt"?) Thanks, fixed > > > > - An intermediate level before masking might be issuing a warning if > some simple, specific remediation

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

On 03/12/2017 03:55 AM, Rich Freeman wrote: > On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand > 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

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

On 03/12/2017 07:11 PM, Roy Bamford wrote: > > Why do Security Project members need to be ebuild devs? > Non ebuild developers can contribute by producing GLSAs, > for example. Where is that requirement stated? > > Who manages the Security Project (from outside). It appears from > the

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

On 2017.03.11 20:50, Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for > reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper

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

On Sun, 12 Mar 2017 09:14:09 +0100 Alexis Ballier wrote: > My point here is to avoid having all the responsibility falling under > the lead In other words: If you want to avoid having bugs inactive for too long, don't introduce a bus factor of 1 through the project lead :)

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

On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for > reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide

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

- Typo... Additional Security Project bugzilla notes * The Security Project is except (should that read "exempt"?) - An intermediate level before masking might be issuing a warning if some simple, specific remediation measure can protect against a vulnerability. E.g. forcing cups to only

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

On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand 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

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

On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > Hi Kristian, > > On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: >> A draft of a Pre-GLEP for the Security project is available for reading >> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security >> >> The GLEP follows a line of

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

Hi Kristian, On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access