Re: [gentoo-project] Re: [gentoo-dev-announce] call for agenda items, council meeting 8/13

[Mike Pagano]

On Thu, Aug 03, 2017 at 02:18:42PM +0200, Michał Górny wrote:
> Dnia 3 sierpnia 2017 13:18:57 CEST, Mike Pagano <mpagano@g.o> napisał(a):
> >Hello,
> >
> >On 08/03/2017 03:06 AM, Michał Górny wrote:
> >> On pon, 2017-07-31 at 18:13 -0400, Mike Pagano wrote:
> >>> On 07/31/2017 10:15 AM, William Hubbs wrote:> All,
> >>>>
> >>>> The next Gentoo Council meeting is on Sunday, aug 13 at 18:00 UTC
> >in the
> >>>> #gentoo-council channel on freenode.
> >>>>
> >>>> Please reply to this message with any items you would like us to
> >discuss
> >>>> or vote on.
> >>>
> >>> <snip>
> >>>
> >>> I would like to submit the following for the council to discuss and
> >vote
> >>> upon.
> >>>
> >>> At the moment, we have a capacity problem around kernel
> >stabilization.
> >>> Upstream kernels are released at an extremely high rate and the
> >Gentoo
> >>> Kernel Maintainers do their best to release them shortly thereafter.
> >>>
> >>> Sometimes, arch teams are not able to respond to stablereqs in a
> >timely
> >>> manner. This is not a complaint on their efforts, just a description
> >of
> >>> what happens often for arch teams that are stressed to capacity.
> >>>
> >>> When the motivation for a STABLEREQ is a high severity security bug
> >>> (e.g. root exploit), this delay in stabilization results in us
> >having to
> >>> keep exploitable kernels in the tree in order not to drop the latest
> >>> stable for a specific architecture.
> >>>
> >>> The procedure outlined below allows for auto-stabilization of minor
> >>> bumps by the Gentoo kernel team for any previously stabled major
> >version
> >>> kernel.[1]
> >>>
> >>> I welcome discussion, better ideas or anything else that makes
> >>> everyone's lives easier and user's systems more secure.
> >>>
> >>
> >> I'm not sure if this is really something for the Council to discuss.
> >> Sounds like a regular problem that's best dealt either with arch
> >teams
> >> directly or on gentoo-dev.
> >
> >This is really something I would like the Council to discuss and vote
> >upon.  I've tried to do this through arch teams and the result is root
> >exploitable kernels sitting in the tree (which is the state right now
> >as
> >I write this).  Certain architectures will not perform stabilization no
> >matter how much I ask. Or how many bugs I submit. Or how many times I
> >pop into IRC and ask.  And I only do this when I am forced to keep root
> >exploits in the tree.
> >
> >
> >> <private hat>
> >>
> >> I don't mind stabilizing new minor releases automatically but I'd
> >prefer
> >> if they were at least build-tested with the default config once.
> >> However, I doubt anybody's going to shoot you if you take
> >> the responsibility for your actions and don't break anything
> >important
> >> in the process.
> >>
> >> </private hat>
> >>
> >
> >You're preference would result in the status quo.  Exploitable kernels
> >sitting in the tree.  I don't have the hardware to build and boot test
> >on every architecture.
>
> Well, I meant making the hardware available to you here. This is sth infra and/or arch testers should be able to do.

Sorry, my misunderstanding. 

I would love that. I would need to be able to just install / build and
boot.  If anyone cares, I have amd64 and x86 at this momment in time.
 
> >
> >By only auto stabilizing minor version bumps for which a major bump was
> >previously arch tested and stabled, we reduce the risk of breakage.
>
>
> --
> Best regards,
> Michał Górny (by phone)
>

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail     : mpagano@g.o
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index