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, ins
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 is free to
> > cleanup old vulnerable versio
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 directly touching pack
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 who
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 pr
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
> Maintainers to take an act
> 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 members on old bugs for
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" .
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 suggest
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
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 the same goal(s) in s
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 lead in most cases to c
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
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 membe
On 2017-03-12 00:54, Kristian Fiskerstrand wrote:
>> 1. From this proposal it looks like the Security Project Lead
>> obtains a lot of power and a lot of responsibility, maybe too much
>> for a single person to handle.
>>
>> While the Deputy may be assigned, this still gives all power to
>> single
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 that
> > it is more
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 de
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 po
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 see is the "Securit
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 benefi
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
> other package m
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 m
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 should be either
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 draf
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 ac
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 :)
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 in order to en
- 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 li
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 clear guidelines
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 G
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 in
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 accountability (c.f GLEP 48
for QA and still non-produced GLEP f
32 matches
Mail list logo
