[gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

Hi all,

I bumped the vanilla-kernel sources yesterday, and deleted some
obsolete, and known-insecure versions at the same time (i.e. the 3.7 and
3.8 ebuilds.)  They were added back because they were the last releases
marked "stable" for some arches.

In thinking about this, that's totally wrong.  Either all of these
ebuilds are marked stable, or none are.  And we should really NEVER have
known buggy ebuilds marked stable for the vanilla kernels, as that's
just dangerous on many different levels.

So, should I just mark these always stable, or never stable?  I don't
think we should mix the two, as the previous versions are always known
buggy, and have problems, and shouldn't be used.

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Mike Pagano]

On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote:
> Hi all,
> 
> I bumped the vanilla-kernel sources yesterday, and deleted some
> obsolete, and known-insecure versions at the same time (i.e. the 3.7 and
> 3.8 ebuilds.)  They were added back because they were the last releases
> marked "stable" for some arches.
> 
> In thinking about this, that's totally wrong.  Either all of these
> ebuilds are marked stable, or none are.  And we should really NEVER have
> known buggy ebuilds marked stable for the vanilla kernels, as that's
> just dangerous on many different levels.
> 
> So, should I just mark these always stable, or never stable?  I don't
> think we should mix the two, as the previous versions are always known
> buggy, and have problems, and shouldn't be used.
> 
> thanks,
> 
> greg k-h
> 


Hi, Greg,

We hammered out a policy sometime in the past that if you add a new
version for the reasons you did and remove the stable ones (that have
security issues) you can do an auto stable.

I have not gone through the commit log to see what happened but here is
an easy example.

You know the stable version 3.8.4 has a sec bug.
You have a minor point release that fixes this.

You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a
stable keyword for 3.8.4.

This should be written down and if it's not that's probably on me as I
am the only kernel person (i think) that was involved in the decision
and is still around.

Mike

P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick
"emergency" stabilization effort by the arch teams.

Let me know if that is clear as mud.

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
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

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/21/2013 11:30 AM, Mike Pagano wrote:
> This should be written down and if it's not that's probably on me as I
> am the only kernel person (i think) that was involved in the decision
> and is still around.

Nope, I was there.  It was the IA32 on amd64 syscall local root exploit 
that got us "blogged" about ... remember that :)

Anyhow, no brainer here.  The kernel is not like the other software we 
stabilize.  Somewhere in its configuration space and in the hardware 
space in which it will be run, there are bugs.  Minor version bumps to 
address security issues followed by auto stabilization are the correct 
thing to do.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 11:30:56AM -0400, Mike Pagano wrote:
> On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote:
> > Hi all,
> > 
> > I bumped the vanilla-kernel sources yesterday, and deleted some
> > obsolete, and known-insecure versions at the same time (i.e. the 3.7 and
> > 3.8 ebuilds.)  They were added back because they were the last releases
> > marked "stable" for some arches.
> > 
> > In thinking about this, that's totally wrong.  Either all of these
> > ebuilds are marked stable, or none are.  And we should really NEVER have
> > known buggy ebuilds marked stable for the vanilla kernels, as that's
> > just dangerous on many different levels.
> > 
> > So, should I just mark these always stable, or never stable?  I don't
> > think we should mix the two, as the previous versions are always known
> > buggy, and have problems, and shouldn't be used.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> 
> Hi, Greg,
> 
> We hammered out a policy sometime in the past that if you add a new
> version for the reasons you did and remove the stable ones (that have
> security issues) you can do an auto stable.

Where was that hammered out?  On this list?

> I have not gone through the commit log to see what happened but here is
> an easy example.
> 
> You know the stable version 3.8.4 has a sec bug.
> You have a minor point release that fixes this.
> 
> You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a
> stable keyword for 3.8.4.
> 
> This should be written down and if it's not that's probably on me as I
> am the only kernel person (i think) that was involved in the decision
> and is still around.

But every single stable kernel release I make fixes bugs that some might
consider "security" issues.  So that means that every single stable
release should be marked stable, right?

We should _never_ have an end-of-life kernel marked stable, that's just
asking for trouble.

> P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick
> "emergency" stabilization effort by the arch teams.
> 
> Let me know if that is clear as mud.

It's clear, but I feel incorrect :)

As we can't do anything to these releases to fix problems or "make them
more stable", they should either always be unstable, or always be
stable, there is no difference.

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 11:46:32AM -0400, Anthony G. Basile wrote:
> On 06/21/2013 11:30 AM, Mike Pagano wrote:
> >This should be written down and if it's not that's probably on me as I
> >am the only kernel person (i think) that was involved in the decision
> >and is still around.
> 
> Nope, I was there.  It was the IA32 on amd64 syscall local root
> exploit that got us "blogged" about ... remember that :)
> 
> Anyhow, no brainer here.  The kernel is not like the other software
> we stabilize.  Somewhere in its configuration space and in the
> hardware space in which it will be run, there are bugs.  Minor
> version bumps to address security issues followed by auto
> stabilization are the correct thing to do.

So that means every single stable release should be marked stable then,
right?

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Eric F. GARIOUD]

On Friday 21 June 2013 18:48:41 Greg KH wrote:

> We should _never_ have an end-of-life kernel marked stable, that's just
> asking for trouble.

What about keeping the stable mark and add a package mask?

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 07:20:23PM +0200, Eric F. GARIOUD wrote:
> On Friday 21 June 2013 18:48:41 Greg KH wrote:
> 
> > We should _never_ have an end-of-life kernel marked stable, that's just
> > asking for trouble.
> 
> What about keeping the stable mark and add a package mask?

And when does that mask get changed?

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Mike Pagano]

On Fri, Jun 21, 2013 at 09:48:41AM -0700, Greg KH wrote:
> On Fri, Jun 21, 2013 at 11:30:56AM -0400, Mike Pagano wrote:
> > On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote:
> > > Hi all,
> > > 
> > > I bumped the vanilla-kernel sources yesterday, and deleted some
> > > obsolete, and known-insecure versions at the same time (i.e. the 3.7 and
> > > 3.8 ebuilds.)  They were added back because they were the last releases
> > > marked "stable" for some arches.
> > > 
> > > In thinking about this, that's totally wrong.  Either all of these
> > > ebuilds are marked stable, or none are.  And we should really NEVER have
> > > known buggy ebuilds marked stable for the vanilla kernels, as that's
> > > just dangerous on many different levels.
> > > 
> > > So, should I just mark these always stable, or never stable?  I don't
> > > think we should mix the two, as the previous versions are always known
> > > buggy, and have problems, and shouldn't be used.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > 
> > 
> > 
> > Hi, Greg,
> > 
> > We hammered out a policy sometime in the past that if you add a new
> > version for the reasons you did and remove the stable ones (that have
> > security issues) you can do an auto stable.
> 
> Where was that hammered out?  On this list?

In bugzilla, and I will locate the bug after I get home from work or
tomorrow.
> 
> > I have not gone through the commit log to see what happened but here is
> > an easy example.
> > 
> > You know the stable version 3.8.4 has a sec bug.
> > You have a minor point release that fixes this.
> > 
> > You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a
> > stable keyword for 3.8.4.
> > 
> > This should be written down and if it's not that's probably on me as I
> > am the only kernel person (i think) that was involved in the decision
> > and is still around.
> 
> But every single stable kernel release I make fixes bugs that some might
> consider "security" issues.  So that means that every single stable
> release should be marked stable, right?

This policy was put in place for the really "serious" security issues.
It was expected that the person from the kernel team can make the call
on whether auto stablizing is the way to go for a particular
vulnerability.  We were trying to make us more agile when responding to
serious root exploits and not look like the distro that is not on top of
these things.

> 
> We should _never_ have an end-of-life kernel marked stable, that's just
> asking for trouble.


> > P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick
> > "emergency" stabilization effort by the arch teams.
> > 
> > Let me know if that is clear as mud.
> 
> It's clear, but I feel incorrect :)
> 
> As we can't do anything to these releases to fix problems or "make them
> more stable", they should either always be unstable, or always be
> stable, there is no difference.

I am not against either.  And I think this is the way to go.  (always
unstable).

Let the user know that we always provide the latest kernel we can and
they need to always upgrade as you always suggest during upstream
releases.

Users have a certain level of expectation and since no kernel version 
can be considered vulnerability free for long maybe we do them a 
disservice by giving them a false impression that a kernel version is safe and stable.

I would ask others's on the team (or not on the team) to consider this idea.

At some point we can pull straws and bring this to -dev.

> 
> thanks,
> 
> greg k-h
> 


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
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

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Eric F. GARIOUD]

On Friday 21 June 2013 19:50:54 Greg KH wrote:
> On Fri, Jun 21, 2013 at 07:20:23PM +0200, Eric F. GARIOUD wrote:
> > On Friday 21 June 2013 18:48:41 Greg KH wrote:
> > > We should _never_ have an end-of-life kernel marked stable, that's just
> > > asking for trouble.
> > 
> > What about keeping the stable mark and add a package mask?
> 
> And when does that mask get changed?

Never!
The next step being to drop the ebuild.

After all, that is what is currently being done with, as an example,  
avidemux-2.5.6-r2

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 09:51:53PM +0200, Eric F. GARIOUD wrote:
> On Friday 21 June 2013 19:50:54 Greg KH wrote:
> > On Fri, Jun 21, 2013 at 07:20:23PM +0200, Eric F. GARIOUD wrote:
> > > On Friday 21 June 2013 18:48:41 Greg KH wrote:
> > > > We should _never_ have an end-of-life kernel marked stable, that's just
> > > > asking for trouble.
> > > 
> > > What about keeping the stable mark and add a package mask?
> > 
> > And when does that mask get changed?
> 
> Never!
> The next step being to drop the ebuild.
> 
> After all, that is what is currently being done with, as an example,  
> avidemux-2.5.6-r2

I'm confused, exactly what are you proposing?

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 03:36:12PM -0400, Mike Pagano wrote:
> > > This should be written down and if it's not that's probably on me as I
> > > am the only kernel person (i think) that was involved in the decision
> > > and is still around.
> > 
> > But every single stable kernel release I make fixes bugs that some might
> > consider "security" issues.  So that means that every single stable
> > release should be marked stable, right?
> 
> This policy was put in place for the really "serious" security issues.

Who is making the judgement call about "serious"?  And how do you know
that problems aren't being fixed that aren't "serious"?

> It was expected that the person from the kernel team can make the call
> on whether auto stablizing is the way to go for a particular
> vulnerability.

Trying to track vunerabilities across kernel versions is going to be
hard, especially for ones that are not public yet :)

> We were trying to make us more agile when responding to serious root
> exploits and not look like the distro that is not on top of these
> things.

I understand, and I think the work done on the "normal" kernel ebuilds
are great this way.  This is just for the vanilla kernels, they should
track the upstream releases directly, no need for any Gentoo developer
to make a judgement call on when something is "stable" or not, as again,
there's nothing they can do about it.

> > As we can't do anything to these releases to fix problems or "make them
> > more stable", they should either always be unstable, or always be
> > stable, there is no difference.
> 
> I am not against either.  And I think this is the way to go.  (always
> unstable).
> 
> Let the user know that we always provide the latest kernel we can and
> they need to always upgrade as you always suggest during upstream
> releases.

Great.

> Users have a certain level of expectation and since no kernel version
> can be considered vulnerability free for long maybe we do them a
> disservice by giving them a false impression that a kernel version is
> safe and stable.

I totally agree.

> I would ask others's on the team (or not on the team) to consider this idea.
> 
> At some point we can pull straws and bring this to -dev.

I can do this if no one else wants to, as I know a bit about how
upstream works in this area :)

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

On Fri, 21 Jun 2013 07:58:01 -0700
Greg KH <gregkh@gentoo.org> wrote:

> I bumped the vanilla-kernel sources yesterday, and deleted some
> obsolete, and known-insecure versions at the same time (i.e. the 3.7
> and 3.8 ebuilds.)

Thank you for keeping an eye on them; I got into a habit of only
bumping gentoo-sources, so I don't always remind the to do vanilla,
I'll do my best to add it to the habbit in the future.

> They were added back because they were the last releases marked
> "stable" for some arches.

Yes, this is actively being checked to avoid that there is no stable
kernel present; if you don't want that to happen then you should make
an individual arrangement with the arch teams, such that they are aware
that the stabilization of this package is individually arranged.

Since ago does stabilizations for multiple arches, is involved in
security bugs and did the restore on this particular package; I have
added him to CC so he is aware of this discussion going on.

http://thread.gmane.org/gmane.linux.gentoo.kernel/697

> In thinking about this, that's totally wrong.  Either all of these
> ebuilds are marked stable, or none are.  And we should really NEVER
> have known buggy ebuilds marked stable for the vanilla kernels, as
> that's just dangerous on many different levels.
> 
> So, should I just mark these always stable, or never stable?  I don't
> think we should mix the two, as the previous versions are always known
> buggy, and have problems, and shouldn't be used.

I think it may be a nice idea to have vanilla-sources reflect upstream;
that is, always stable and drop versions which are not.

If possible we could script it to keep the package unstable the first X
days it is in Portage to keep the stabilization effect in place; that
way Gentoo users are unaffected if something goes wrong the day after
you push a patch, I assume not, but you never know.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 02:02:59AM +0200, Tom Wijsman wrote:
> On Fri, 21 Jun 2013 07:58:01 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > I bumped the vanilla-kernel sources yesterday, and deleted some
> > obsolete, and known-insecure versions at the same time (i.e. the 3.7
> > and 3.8 ebuilds.)
> 
> Thank you for keeping an eye on them; I got into a habit of only
> bumping gentoo-sources, so I don't always remind the to do vanilla,
> I'll do my best to add it to the habbit in the future.
> 
> > They were added back because they were the last releases marked
> > "stable" for some arches.
> 
> Yes, this is actively being checked to avoid that there is no stable
> kernel present; if you don't want that to happen then you should make
> an individual arrangement with the arch teams, such that they are aware
> that the stabilization of this package is individually arranged.
> 
> Since ago does stabilizations for multiple arches, is involved in
> security bugs and did the restore on this particular package; I have
> added him to CC so he is aware of this discussion going on.
> 
> http://thread.gmane.org/gmane.linux.gentoo.kernel/697
> 
> > In thinking about this, that's totally wrong.  Either all of these
> > ebuilds are marked stable, or none are.  And we should really NEVER
> > have known buggy ebuilds marked stable for the vanilla kernels, as
> > that's just dangerous on many different levels.
> > 
> > So, should I just mark these always stable, or never stable?  I don't
> > think we should mix the two, as the previous versions are always known
> > buggy, and have problems, and shouldn't be used.
> 
> I think it may be a nice idea to have vanilla-sources reflect upstream;
> that is, always stable and drop versions which are not.

Great!  But as only the latest version released is "stable", that's all
that should stick around, right?

> If possible we could script it to keep the package unstable the first X
> days it is in Portage to keep the stabilization effect in place; that
> way Gentoo users are unaffected if something goes wrong the day after
> you push a patch, I assume not, but you never know.

If something goes "wrong" the day after I push a update, I push a new
one fixing the problem, so this shouldn't be an issue, right?

And as these are coming out about 1-2 a week, the timeout before the
arch teams could get around to marking things stable seems like a lot of
work, for something that isn't really needed at all.

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 02:02:59AM +0200, Tom Wijsman wrote:
> On Fri, 21 Jun 2013 07:58:01 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > I bumped the vanilla-kernel sources yesterday, and deleted some
> > obsolete, and known-insecure versions at the same time (i.e. the 3.7
> > and 3.8 ebuilds.)
> 
> Thank you for keeping an eye on them; I got into a habit of only
> bumping gentoo-sources, so I don't always remind the to do vanilla,
> I'll do my best to add it to the habbit in the future.
> 
> > They were added back because they were the last releases marked
> > "stable" for some arches.
> 
> Yes, this is actively being checked to avoid that there is no stable
> kernel present; if you don't want that to happen then you should make
> an individual arrangement with the arch teams, such that they are aware
> that the stabilization of this package is individually arranged.
> 
> Since ago does stabilizations for multiple arches, is involved in
> security bugs and did the restore on this particular package; I have
> added him to CC so he is aware of this discussion going on.
> 
> http://thread.gmane.org/gmane.linux.gentoo.kernel/697
> 
> > In thinking about this, that's totally wrong.  Either all of these
> > ebuilds are marked stable, or none are.  And we should really NEVER
> > have known buggy ebuilds marked stable for the vanilla kernels, as
> > that's just dangerous on many different levels.
> > 
> > So, should I just mark these always stable, or never stable?  I don't
> > think we should mix the two, as the previous versions are always known
> > buggy, and have problems, and shouldn't be used.
> 
> I think it may be a nice idea to have vanilla-sources reflect upstream;
> that is, always stable and drop versions which are not.

Great!  But as only the latest version released is "stable", that's all
that should stick around, right?

> If possible we could script it to keep the package unstable the first X
> days it is in Portage to keep the stabilization effect in place; that
> way Gentoo users are unaffected if something goes wrong the day after
> you push a patch, I assume not, but you never know.

If something goes "wrong" the day after I push a update, I push a new
one fixing the problem, so this shouldn't be an issue, right?

And as these are coming out about 1-2 a week, the timeout before the
arch teams could get around to marking things stable seems like a lot of
work, for something that isn't really needed at all.

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

On Fri, 21 Jun 2013 11:30:56 -0400
Mike Pagano <mpagano@gentoo.org> wrote:

> We hammered out a policy sometime in the past that if you add a new
> version for the reasons you did and remove the stable ones (that have
> security issues) you can do an auto stable.
> 
> I have not gone through the commit log to see what happened but here
> is an easy example.
> 
> You know the stable version 3.8.4 has a sec bug.
> You have a minor point release that fixes this.
> 
> You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a
> stable keyword for 3.8.4.

I know this thread is about vanilla-sources. But in the context of
gentoo-sources this would mean we could do a revision bump with
the security patch and auto stable it? That makes a lot of sense.

Haven't thought about that, I'm going to do that right now to cover the
minor arches that do not have a newer major release stabilized yet.

> This should be written down and if it's not that's probably on me as I
> am the only kernel person (i think) that was involved in the decision
> and is still around.

Yes, I was unaware of this approach, discussion and decision; I'm not
sure if any other kernel person is still active.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

On Fri, 21 Jun 2013 17:13:03 -0700
Greg KH <gregkh@gentoo.org> wrote:

> Great!  But as only the latest version released is "stable", that's
> all that should stick around, right?

Tricky decision to make. Do we really want to force people's kernel
sources to unmerge every single time you push a new version? Which on
its own turn, forces them to build and install the new kernel.

> > If possible we could script it to keep the package unstable the
> > first X days it is in Portage to keep the stabilization effect in
> > place; that way Gentoo users are unaffected if something goes wrong
> > the day after you push a patch, I assume not, but you never know.
> 
> If something goes "wrong" the day after I push a update, I push a new
> one fixing the problem, so this shouldn't be an issue, right?

It's not so much about fixing the problem, but rather about the
severity of the issue. If this involves a corruption that corrupts a
large amount of data on well known hardware which the patches were not
tested on, users with such hardware would be affected; if we however
delay our Gentoo users, they wouldn't become affected due to an
upstream problem, unless they intentionally use the  ~  keyword

> And as these are coming out about 1-2 a week, the timeout before the
> arch teams could get around to marking things stable seems like a lot
> of work, for something that isn't really needed at all.

What I meant was to not involve arch teams at all, as per the original
proposal but just have a cron job running somewhere to stabilize the
new versions, as well as to drop older versions.

The delayed stabilization and delayed dropping from the tree are merely
ideas that I think are in favor of the users; I may be wrong about this
but would like to at least see this discussed, unless everyone agrees
we should completely reflect the current state as listed on kernel.org.

As you probably know, there are different groups of users where some
run personal laptops or desktops whereas other run a (professional)
server. I think an approach that what would make sense for people
running a secure and stable server might not necessarily make sense for
people running their own laptop or desktop. Not all exploits target
both servers and desktops (eg. they can't get behind router).

On the other hand, the vanilla-sources ebuilds set
K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the
(professional) server people at all and therefore perhaps only the
laptop and desktop users. Or at least, that's how Gentoo Security and
that variable would make it look like; I agree though that it is
inconsistent with how upstream would look at these versions, I
therofore think it should be a good idea to reevaluate said variable if
we are going to change the way we stabilize and drop vanilla-sources.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

The bug where this was discussed is

https://bugs.gentoo.org/show_bug.cgi?id=338739

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> On Fri, 21 Jun 2013 17:13:03 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > Great!  But as only the latest version released is "stable", that's
> > all that should stick around, right?
> 
> Tricky decision to make. Do we really want to force people's kernel
> sources to unmerge every single time you push a new version? Which on
> its own turn, forces them to build and install the new kernel.

If they are following the vanilla kernels, isn't that what people
expect?  The latest stable-kernel-of-the-week, as that's what I'm
releasing.  They don't have to do an update if they don't want to :)

> > > If possible we could script it to keep the package unstable the
> > > first X days it is in Portage to keep the stabilization effect in
> > > place; that way Gentoo users are unaffected if something goes wrong
> > > the day after you push a patch, I assume not, but you never know.
> > 
> > If something goes "wrong" the day after I push a update, I push a new
> > one fixing the problem, so this shouldn't be an issue, right?
> 
> It's not so much about fixing the problem, but rather about the
> severity of the issue. If this involves a corruption that corrupts a
> large amount of data on well known hardware which the patches were not
> tested on, users with such hardware would be affected; if we however
> delay our Gentoo users, they wouldn't become affected due to an
> upstream problem, unless they intentionally use the  ~  keyword

And how would you find out about these types of issues, unless they get
tested on those systems?  It's a chicken-and-egg issue.  People who want
more "stable" releases, follow the gentoo kernels.  If you want to track
upstream directly, use the vanilla kernels, that's what they are there
for.

> > And as these are coming out about 1-2 a week, the timeout before the
> > arch teams could get around to marking things stable seems like a lot
> > of work, for something that isn't really needed at all.
> 
> What I meant was to not involve arch teams at all, as per the original
> proposal but just have a cron job running somewhere to stabilize the
> new versions, as well as to drop older versions.

A cron job doesn't mean anything (how to stop it?), so you might as well
just always either mark them stable or not, as no one is testing them
for "stability".

> The delayed stabilization and delayed dropping from the tree are merely
> ideas that I think are in favor of the users; I may be wrong about this
> but would like to at least see this discussed, unless everyone agrees
> we should completely reflect the current state as listed on kernel.org.
> 
> As you probably know, there are different groups of users where some
> run personal laptops or desktops whereas other run a (professional)
> server. I think an approach that what would make sense for people
> running a secure and stable server might not necessarily make sense for
> people running their own laptop or desktop. Not all exploits target
> both servers and desktops (eg. they can't get behind router).

I agree, that's why we have so many different kernel packages.

> On the other hand, the vanilla-sources ebuilds set
> K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the
> (professional) server people at all and therefore perhaps only the
> laptop and desktop users. Or at least, that's how Gentoo Security and
> that variable would make it look like; I agree though that it is
> inconsistent with how upstream would look at these versions, I
> therofore think it should be a good idea to reevaluate said variable if
> we are going to change the way we stabilize and drop vanilla-sources.

I'll leave that alone, as I don't know what that flag means or does,
sorry.

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
> The bug where this was discussed is
> 
> https://bugs.gentoo.org/show_bug.cgi?id=338739

Thanks for the link, unfortunatly, things have changed since then, with
stable kernel releases happening much more frequently now (instead of
about ever 2-3 weeks, it's now, 1-2 releases a week.

So the chance for an arch team to mark anything is going to be tough.

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]

On Fri, 21 Jun 2013 20:42:44 -0700
Greg KH <greg@kroah.com> wrote:

> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> > On Fri, 21 Jun 2013 17:13:03 -0700
> > Greg KH <gregkh@gentoo.org> wrote:
> > 
> > > Great!  But as only the latest version released is "stable",
> > > that's all that should stick around, right?
> > 
> > Tricky decision to make. Do we really want to force people's kernel
> > sources to unmerge every single time you push a new version? Which
> > on its own turn, forces them to build and install the new kernel.
> 
> If they are following the vanilla kernels, isn't that what people
> expect?  The latest stable-kernel-of-the-week, as that's what I'm
> releasing.  They don't have to do an update if they don't want to :)

If we don't keep around other ebuilds their sources will unexpectedly
unmerge upon a dependency clean; they can only stop it if they see it
in the list of packages that will be unmerged, and do something to
specifically keep them.

Feel free to experiment with this happening in your Portage tree.
 
> > > > If possible we could script it to keep the package unstable the
> > > > first X days it is in Portage to keep the stabilization effect
> > > > in place; that way Gentoo users are unaffected if something
> > > > goes wrong the day after you push a patch, I assume not, but
> > > > you never know.
> > > 
> > > If something goes "wrong" the day after I push a update, I push a
> > > new one fixing the problem, so this shouldn't be an issue, right?
> > 
> > It's not so much about fixing the problem, but rather about the
> > severity of the issue. If this involves a corruption that corrupts a
> > large amount of data on well known hardware which the patches were
> > not tested on, users with such hardware would be affected; if we
> > however delay our Gentoo users, they wouldn't become affected due
> > to an upstream problem, unless they intentionally use the  ~
> > keyword
> 
> And how would you find out about these types of issues, unless they
> get tested on those systems?  It's a chicken-and-egg issue.  People
> who want more "stable" releases, follow the gentoo kernels.  If you
> want to track upstream directly, use the vanilla kernels, that's what
> they are there for.

Okay, I was just thinking through the possible scenarios of going with
this approach; if nobody else reasonably objects we can do that.

> > > And as these are coming out about 1-2 a week, the timeout before
> > > the arch teams could get around to marking things stable seems
> > > like a lot of work, for something that isn't really needed at all.
> > 
> > What I meant was to not involve arch teams at all, as per the
> > original proposal but just have a cron job running somewhere to
> > stabilize the new versions, as well as to drop older versions.
> 
> A cron job doesn't mean anything (how to stop it?), so you might as
> well just always either mark them stable or not, as no one is testing
> them for "stability".

The cron job should not apply if the version is masked, had its
keywords removed or the ebuild itself removed; this should be trivial
to figure out through the Portage API.

We do have people testing them for stability, as some people run a
system with stable keywords whereas other people wan't to be more risky
and use the unstable / testing / ...  ~  keyword.

> > On the other hand, the vanilla-sources ebuilds set
> > K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the
> > (professional) server people at all and therefore perhaps only the
> > laptop and desktop users. Or at least, that's how Gentoo Security
> > and that variable would make it look like; I agree though that it is
> > inconsistent with how upstream would look at these versions, I
> > therofore think it should be a good idea to reevaluate said
> > variable if we are going to change the way we stabilize and drop
> > vanilla-sources.
> 
> I'll leave that alone, as I don't know what that flag means or does,
> sorry.

It prints out the following message, which becomes less the case if we
stabilize it more; as you said, the kernel is more often released these
days and therefore recent security issues are much faster dealt with.


${PN} is UNSUPPORTED by Gentoo Security.
This means that it is likely to be vulnerable to recent security issues.
For specific information on why this kernel is unsupported, please read:
http://www.gentoo.org/proj/en/security/kernel.xml


PS: On a perhaps irrelevant side note, what I find interesting in the
above URL is that it lists vanilla-sources as containing rc entries
(which would be marked with the  ~  keyword) and git-sources as
containing daily snapshots; it appears that the rc entries have moved
to git-sources and that git-sources no longer does daily snapshots.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/21/2013 11:47 PM, Greg KH wrote:
> On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
>> The bug where this was discussed is
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=338739
>
> Thanks for the link, unfortunatly, things have changed since then, with
> stable kernel releases happening much more frequently now (instead of
> about ever 2-3 weeks, it's now, 1-2 releases a week.
>
> So the chance for an arch team to mark anything is going to be tough.
>
> greg k-h
>

I've been following, but I can't say I've been following closely.  I'm 
on the stable{,-commits}@vger list and the rate at which this stuff is 
coming is too fast for human consumption.

We could just drop stabilization of vanilla-sources and have people 
follow ~arch.  That might be closer to the meaning of ~testing vs stable 
in other packages: other upstreams push out releases they consider 
stable, but we don't consider them stable within Gentoo until our QA 
team tests.

Another reason for dropping all vanilla-sources to ~arch is that we have 
some Gentoo specific needs that upstream will not and should not accept, 
eg we are making greater use of extended attributes in our package 
management, so we need end-to-end copying of xattrs.  This means 
preserving certain namespaces (beyond security.* and trusted.*) on tmpfs 
for emerge.  Gentoo users that use vanilla-sources will loose those 
xattr values making vanilla-sources ~ with respect to the rest of Gentoo.


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 04:56:39AM -0400, Anthony G. Basile wrote:
> On 06/21/2013 11:47 PM, Greg KH wrote:
> >On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
> >>The bug where this was discussed is
> >>
> >>https://bugs.gentoo.org/show_bug.cgi?id=338739
> >
> >Thanks for the link, unfortunatly, things have changed since then, with
> >stable kernel releases happening much more frequently now (instead of
> >about ever 2-3 weeks, it's now, 1-2 releases a week.
> >
> >So the chance for an arch team to mark anything is going to be tough.
> >
> >greg k-h
> >
> 
> I've been following, but I can't say I've been following closely.
> I'm on the stable{,-commits}@vger list and the rate at which this
> stuff is coming is too fast for human consumption.

So, as I am the one creating all of that "stuff", does that mean I'm
somehow not "human"?  :)

> We could just drop stabilization of vanilla-sources and have people
> follow ~arch.  That might be closer to the meaning of ~testing vs
> stable in other packages: other upstreams push out releases they
> consider stable, but we don't consider them stable within Gentoo
> until our QA team tests.

I agree.

> Another reason for dropping all vanilla-sources to ~arch is that we
> have some Gentoo specific needs that upstream will not and should
> not accept, eg we are making greater use of extended attributes in
> our package management, so we need end-to-end copying of xattrs.
> This means preserving certain namespaces (beyond security.* and
> trusted.*) on tmpfs for emerge.  Gentoo users that use
> vanilla-sources will loose those xattr values making vanilla-sources
> ~ with respect to the rest of Gentoo.

What?  So we are now relying on kernel patches that are not merged
upstream for proper operation of at Gentoo-based system?  That's news to
me, I've _never_ run a gentoo-based kernel on my boxes in all of my
years as a Gentoo developer, with no problems, and I don't think we want
to require this in the future, do you?

Also, why aren't these patches upstream?  Were they rejected?  Just not
ready?  No one submitted them?

Don't ever try to differentiate at the kernel level from other distros,
it's not worth it, and will cause problems in the end.  The other
distros have realized this, I thought we were smarter than that...

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/22/2013 10:43 AM, Greg KH wrote:
> On Sat, Jun 22, 2013 at 04:56:39AM -0400, Anthony G. Basile wrote:
>> On 06/21/2013 11:47 PM, Greg KH wrote:
>>> On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
>>>> The bug where this was discussed is
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=338739
>>> Thanks for the link, unfortunatly, things have changed since then, with
>>> stable kernel releases happening much more frequently now (instead of
>>> about ever 2-3 weeks, it's now, 1-2 releases a week.
>>>
>>> So the chance for an arch team to mark anything is going to be tough.
>>>
>>> greg k-h
>>>
>> I've been following, but I can't say I've been following closely.
>> I'm on the stable{,-commits}@vger list and the rate at which this
>> stuff is coming is too fast for human consumption.
> So, as I am the one creating all of that "stuff", does that mean I'm
> somehow not "human"?  :)

Yes, yes it does :)  I was one of your 40 elect when you needed minion, 
but I just can't with all my other duties.

>
>> We could just drop stabilization of vanilla-sources and have people
>> follow ~arch.  That might be closer to the meaning of ~testing vs
>> stable in other packages: other upstreams push out releases they
>> consider stable, but we don't consider them stable within Gentoo
>> until our QA team tests.
> I agree.
>
>> Another reason for dropping all vanilla-sources to ~arch is that we
>> have some Gentoo specific needs that upstream will not and should
>> not accept, eg we are making greater use of extended attributes in
>> our package management, so we need end-to-end copying of xattrs.
>> This means preserving certain namespaces (beyond security.* and
>> trusted.*) on tmpfs for emerge.  Gentoo users that use
>> vanilla-sources will loose those xattr values making vanilla-sources
>> ~ with respect to the rest of Gentoo.
> What?  So we are now relying on kernel patches that are not merged
> upstream for proper operation of at Gentoo-based system?  That's news to
> me, I've _never_ run a gentoo-based kernel on my boxes in all of my
> years as a Gentoo developer, with no problems, and I don't think we want
> to require this in the future, do you?

Its related to PaX coming form the grsec/pax team.

>
> Also, why aren't these patches upstream?  Were they rejected?  Just not
> ready?  No one submitted them?

We need to maintain a special namespace on tmpfs beyond security.* and 
trusted.*  It is "user.pax.flags" and it is limited to 8 bytes. Without 
it, we will not have end-to-end xattr support for the namespaces we need 
in Gentoo.

As for why they are not upstream, I can try.  I'm like 99.9% certain it 
will be rejected but at the very least, if the rejection is "we don't 
need that crap" then I can safely ignore it, but if the rejection is 
"there's a gapping security whole" then we can at least address it even 
if in the end they pulled into vanilla.

>
> Don't ever try to differentiate at the kernel level from other distros,
> it's not worth it, and will cause problems in the end.  The other
> distros have realized this, I thought we were smarter than that...

Like the 50k line patch that Brad spews out every other day?  I 
understand your point but grsec/pax has a large enough user base and 
we've supported it for 10 years now.

As for not differentiating at the kernel level, our choice here was 
either that or differentiate at the toolchain level.  Try readelf -l on 
any Gentoo elf object and tell me what you see different than, oh say, 
OpenSuse.  A 5 line patch to mm/shmem.c in the kernel is a small price 
to pay for cleaning up the program headers of our elf objects 
userland-wide.  *That* will bring Genoo in line with other linux distros.

>
> thanks,
>
> greg k-h
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
> On Fri, 21 Jun 2013 20:42:44 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> > > On Fri, 21 Jun 2013 17:13:03 -0700
> > > Greg KH <gregkh@gentoo.org> wrote:
> > > 
> > > > Great!  But as only the latest version released is "stable",
> > > > that's all that should stick around, right?
> > > 
> > > Tricky decision to make. Do we really want to force people's kernel
> > > sources to unmerge every single time you push a new version? Which
> > > on its own turn, forces them to build and install the new kernel.
> > 
> > If they are following the vanilla kernels, isn't that what people
> > expect?  The latest stable-kernel-of-the-week, as that's what I'm
> > releasing.  They don't have to do an update if they don't want to :)
> 
> If we don't keep around other ebuilds their sources will unexpectedly
> unmerge upon a dependency clean; they can only stop it if they see it
> in the list of packages that will be unmerged, and do something to
> specifically keep them.

True, so we can keep around 3-4 older ebuilds if needed, per kernel
release.  But who really does a dependency clean these days, I've never
done one :)

So, what's the next step?  Should I announce the change to -dev?  Anyone
else really object to it?  Other thoughts?

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Sat, Jun 22, 2013 at 12:46:01PM -0400, Anthony G. Basile wrote:
> >>Another reason for dropping all vanilla-sources to ~arch is that we
> >>have some Gentoo specific needs that upstream will not and should
> >>not accept, eg we are making greater use of extended attributes in
> >>our package management, so we need end-to-end copying of xattrs.
> >>This means preserving certain namespaces (beyond security.* and
> >>trusted.*) on tmpfs for emerge.  Gentoo users that use
> >>vanilla-sources will loose those xattr values making vanilla-sources
> >>~ with respect to the rest of Gentoo.
> >What?  So we are now relying on kernel patches that are not merged
> >upstream for proper operation of at Gentoo-based system?  That's news to
> >me, I've _never_ run a gentoo-based kernel on my boxes in all of my
> >years as a Gentoo developer, with no problems, and I don't think we want
> >to require this in the future, do you?
> 
> Its related to PaX coming form the grsec/pax team.

Ah, this is just the "hardened" stuff, not the "normal" gentoo kernels,
right?

> >Also, why aren't these patches upstream?  Were they rejected?  Just not
> >ready?  No one submitted them?
> 
> We need to maintain a special namespace on tmpfs beyond security.*
> and trusted.*  It is "user.pax.flags" and it is limited to 8 bytes.
> Without it, we will not have end-to-end xattr support for the
> namespaces we need in Gentoo.
> 
> As for why they are not upstream, I can try.  I'm like 99.9% certain
> it will be rejected but at the very least, if the rejection is "we
> don't need that crap" then I can safely ignore it, but if the
> rejection is "there's a gapping security whole" then we can at least
> address it even if in the end they pulled into vanilla.

Any pointers to the patch so that I can take a look at it?

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/24/2013 12:27 PM, Greg KH wrote:
> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
>> On Fri, 21 Jun 2013 20:42:44 -0700
>> Greg KH <greg@kroah.com> wrote:
>>
>>> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
>>>> On Fri, 21 Jun 2013 17:13:03 -0700
>>>> Greg KH <gregkh@gentoo.org> wrote:
>>>>
>>>>> Great!  But as only the latest version released is "stable",
>>>>> that's all that should stick around, right?
>>>>
>>>> Tricky decision to make. Do we really want to force people's kernel
>>>> sources to unmerge every single time you push a new version? Which
>>>> on its own turn, forces them to build and install the new kernel.
>>>
>>> If they are following the vanilla kernels, isn't that what people
>>> expect?  The latest stable-kernel-of-the-week, as that's what I'm
>>> releasing.  They don't have to do an update if they don't want to :)
>>
>> If we don't keep around other ebuilds their sources will unexpectedly
>> unmerge upon a dependency clean; they can only stop it if they see it
>> in the list of packages that will be unmerged, and do something to
>> specifically keep them.
>
> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> release.  But who really does a dependency clean these days, I've never
> done one :)
>
> So, what's the next step?  Should I announce the change to -dev?  Anyone
> else really object to it?  Other thoughts?
>
> thanks,
>
> greg k-h
>

Greg,

This sounds okay to me, but let's see what the lead says.  You're best 
suited to decide which versions to keep or toss, so as far as I'm 
concerned, just do what you've been doing as I see from the ChangeLog.

There is, however, some disagreement about whether we should still 
continue stabilizing vanilla-sources, but we can debate that on -dev.

--Tony

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Mon, 24 Jun 2013 09:27:10 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> release.  But who really does a dependency clean these days, I've
> never done one :)

Depends a bit on your workflow; in my case, I ...

1) Update my system on a daily basis.
2) Test many packages I don't actively use, typical on some herds.
3) Test many kernels, each having their own slot; leaving stuff behind.
4) Randomly emerge interesting software to try it; I usually do this
   with -1 so I don't forget to unmerge them, supposing I dep clean.

Especially those cases where there are dependency changes (whether
the dependency is no longer used or the slot changed) a lot of
dependencies (and some packages) can be left behind.

So, I do have to run it now and then or it will clog my system; not to
forget about the many other non Portage creep that could fill up.

> So, what's the next step? Should I announce the change to -dev?

I wonder if a news item is in place for this change, because we will
be dropping all stable keywords. If I remember correctly news items
have to pass the -dev ML. On the other hand, I don't really have an
idea of how important this issue is to be considered; though it may be
handy to err on the side of being more transparent towards our users.

> Anyone else really object to it?  Other thoughts?

I thought the idea of not stabilizing worked out the best, dropping
insecure and EOL versions and keeping the versions from the last month
of each branch around or so (we do this very last thing on g-s too).

No objections from me.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Dale]

Greg KH wrote:
> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> release. But who really does a dependency clean these days, I've never
> done one :) So, what's the next step? Should I announce the change to
> -dev? Anyone else really object to it? Other thoughts? thanks, greg k-h 

If you are referring to --depclean, I do that pretty regular here.  I
see it being recommended on -user and forums and have even seen it after
a emerge more than once. 

If you are referring to something else, disregard.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Douglas Dunn]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

A users perspective about vanilla-kernel, but why not just mirror whats
available on kernel.org. keep it simple with the versions they offer there,
with their longterm stable and slowly remove their EOL, maybe give a
warning there till its gone from kernel and then make it gone from the tree.


On Mon, Jun 24, 2013 at 11:09 PM, Dale <rdalek1967@gmail.com> wrote:

> Greg KH wrote:
> > True, so we can keep around 3-4 older ebuilds if needed, per kernel
> > release. But who really does a dependency clean these days, I've never
> > done one :) So, what's the next step? Should I announce the change to
> > -dev? Anyone else really object to it? Other thoughts? thanks, greg k-h
>
> If you are referring to --depclean, I do that pretty regular here.  I
> see it being recommended on -user and forums and have even seen it after
> a emerge more than once.
>
> If you are referring to something else, disregard.
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or
> how you interpreted my words!
>
>
>

[-- Attachment #2: Type: text/html, Size: 1551 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Am Dienstag, 25. Juni 2013, 01:37:56 schrieb Tom Wijsman:
> 
> I wonder if a news item is in place for this change, because we will
> be dropping all stable keywords. If I remember correctly news items
> have to pass the -dev ML. On the other hand, I don't really have an
> idea of how important this issue is to be considered; though it may be
> handy to err on the side of being more transparent towards our users.
> 

I think this is worth a news item because stable users using vanilla-sources 
will rely on new stable kernels to appear for them. They should be informed 
about the fact that they now have to accept the ~ keyword in order to get 
updated kernel versions.

-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Tue, Jun 25, 2013 at 02:18:12AM -0400, Douglas Dunn wrote:
> A users perspective about vanilla-kernel, but why not just mirror whats
> available on kernel.org. keep it simple with the versions they offer there,
> with their longterm stable and slowly remove their EOL, maybe give a warning
> there till its gone from kernel and then make it gone from the tree.

That's exactly what I am proposing, but keeping everything marked
"unstable" as there's no time to mark them stable before the next
release comes out with fixes that should be applied.

thanks,

greg k-h

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Mike Pagano]

On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote:
> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
> > On Fri, 21 Jun 2013 20:42:44 -0700
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> > > > On Fri, 21 Jun 2013 17:13:03 -0700
> > > > Greg KH <gregkh@gentoo.org> wrote:
> > > > 
> > > > > Great!  But as only the latest version released is "stable",
> > > > > that's all that should stick around, right?
> > > > 
> > > > Tricky decision to make. Do we really want to force people's kernel
> > > > sources to unmerge every single time you push a new version? Which
> > > > on its own turn, forces them to build and install the new kernel.
> > > 
> > > If they are following the vanilla kernels, isn't that what people
> > > expect?  The latest stable-kernel-of-the-week, as that's what I'm
> > > releasing.  They don't have to do an update if they don't want to :)
> > 
> > If we don't keep around other ebuilds their sources will unexpectedly
> > unmerge upon a dependency clean; they can only stop it if they see it
> > in the list of packages that will be unmerged, and do something to
> > specifically keep them.
> 
> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> release.  But who really does a dependency clean these days, I've never
> done one :)
> 
> So, what's the next step?  Should I announce the change to -dev?  Anyone
> else really object to it?  Other thoughts?
> 
> thanks,
> 
> greg k-h
> 

Are we agreed on a few facts?

1. Upstream release rate is now a much higher 1-2 kernels a week.
2. Very frequently, these releases contain security fixes.
3. This rate of release puts arch teams in a difficult position, since
it is unsustainable to try to keep up tp date with stabilization
4. By continuing the policy of providing a stable kernel version, Gentoo
is giving a false sense of security to its users, since by the time the
kernel does get stabilized, a newer version more with more security
fixes is almost always already released.

Auto stabling keywords again will give that false impression of Gentoo
QA on a particular arch, so I don't think I would want that.

A downside is that a kernel could be released that wont build on an
arch. Does that imply failure of our QA process? Or is it acceptable, as
a fix almost always follows right after that kind of situation.







-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
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

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/27/2013 03:45 PM, Mike Pagano wrote:
> On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote:
>> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
>>> On Fri, 21 Jun 2013 20:42:44 -0700
>>> Greg KH <greg@kroah.com> wrote:
>>>
>>>> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
>>>>> On Fri, 21 Jun 2013 17:13:03 -0700
>>>>> Greg KH <gregkh@gentoo.org> wrote:
>>>>>
>>>>>> Great!  But as only the latest version released is "stable",
>>>>>> that's all that should stick around, right?
>>>>> Tricky decision to make. Do we really want to force people's kernel
>>>>> sources to unmerge every single time you push a new version? Which
>>>>> on its own turn, forces them to build and install the new kernel.
>>>> If they are following the vanilla kernels, isn't that what people
>>>> expect?  The latest stable-kernel-of-the-week, as that's what I'm
>>>> releasing.  They don't have to do an update if they don't want to :)
>>> If we don't keep around other ebuilds their sources will unexpectedly
>>> unmerge upon a dependency clean; they can only stop it if they see it
>>> in the list of packages that will be unmerged, and do something to
>>> specifically keep them.
>> True, so we can keep around 3-4 older ebuilds if needed, per kernel
>> release.  But who really does a dependency clean these days, I've never
>> done one :)
>>
>> So, what's the next step?  Should I announce the change to -dev?  Anyone
>> else really object to it?  Other thoughts?
>>
>> thanks,
>>
>> greg k-h
>>
> Are we agreed on a few facts?
>
> 1. Upstream release rate is now a much higher 1-2 kernels a week.
> 2. Very frequently, these releases contain security fixes.
> 3. This rate of release puts arch teams in a difficult position, since
> it is unsustainable to try to keep up tp date with stabilization
> 4. By continuing the policy of providing a stable kernel version, Gentoo
> is giving a false sense of security to its users, since by the time the
> kernel does get stabilized, a newer version more with more security
> fixes is almost always already released.
>
> Auto stabling keywords again will give that false impression of Gentoo
> QA on a particular arch, so I don't think I would want that.
>
> A downside is that a kernel could be released that wont build on an
> arch. Does that imply failure of our QA process? Or is it acceptable, as
> a fix almost always follows right after that kind of situation.
>
This is fine.  Within the space of all arches and all possible 
configurations, kernels always have bugs.  On vanilla-sources, these 
reports should go directly upstream.  If we have fixes, we should pass 
them upstream.

We should do a news item to alert users to the new policy.  What is the 
migration path to dropping stable keywords?  Some users may sit on 
stable kernels thinking that's where we are drawing the line of 
stability, while we've actually dropped that distinction all together.

--Tony

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Mike Pagano]

On Thu, Jun 27, 2013 at 04:03:51PM -0400, Anthony G. Basile wrote:
> On 06/27/2013 03:45 PM, Mike Pagano wrote:
> > On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote:
> >> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
> >>> On Fri, 21 Jun 2013 20:42:44 -0700
> >>> Greg KH <greg@kroah.com> wrote:
> >>>
> >>>> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> >>>>> On Fri, 21 Jun 2013 17:13:03 -0700
> >>>>> Greg KH <gregkh@gentoo.org> wrote:
> >>>>>
> >>>>>> Great!  But as only the latest version released is "stable",
> >>>>>> that's all that should stick around, right?
> >>>>> Tricky decision to make. Do we really want to force people's kernel
> >>>>> sources to unmerge every single time you push a new version? Which
> >>>>> on its own turn, forces them to build and install the new kernel.
> >>>> If they are following the vanilla kernels, isn't that what people
> >>>> expect?  The latest stable-kernel-of-the-week, as that's what I'm
> >>>> releasing.  They don't have to do an update if they don't want to :)
> >>> If we don't keep around other ebuilds their sources will unexpectedly
> >>> unmerge upon a dependency clean; they can only stop it if they see it
> >>> in the list of packages that will be unmerged, and do something to
> >>> specifically keep them.
> >> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> >> release.  But who really does a dependency clean these days, I've never
> >> done one :)
> >>
> >> So, what's the next step?  Should I announce the change to -dev?  Anyone
> >> else really object to it?  Other thoughts?
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> > Are we agreed on a few facts?
> >
> > 1. Upstream release rate is now a much higher 1-2 kernels a week.
> > 2. Very frequently, these releases contain security fixes.
> > 3. This rate of release puts arch teams in a difficult position, since
> > it is unsustainable to try to keep up tp date with stabilization
> > 4. By continuing the policy of providing a stable kernel version, Gentoo
> > is giving a false sense of security to its users, since by the time the
> > kernel does get stabilized, a newer version more with more security
> > fixes is almost always already released.
> >
> > Auto stabling keywords again will give that false impression of Gentoo
> > QA on a particular arch, so I don't think I would want that.
> >
> > A downside is that a kernel could be released that wont build on an
> > arch. Does that imply failure of our QA process? Or is it acceptable, as
> > a fix almost always follows right after that kind of situation.
> >
> This is fine.  Within the space of all arches and all possible 
> configurations, kernels always have bugs.  On vanilla-sources, these 
> reports should go directly upstream.  If we have fixes, we should pass 
> them upstream.
> 
> We should do a news item to alert users to the new policy.  What is the 
> migration path to dropping stable keywords?  Some users may sit on 
> stable kernels thinking that's where we are drawing the line of 
> stability, while we've actually dropped that distinction all together.

You are 100% right on that. I've had users that refuse to upgrade
kernels because they were not stabilized. This is definitely news item
worthy.

> 
> --Tony
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail    : blueness@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
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

Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Greg KH]

On Thu, Jun 27, 2013 at 03:45:04PM -0400, Mike Pagano wrote:
> Are we agreed on a few facts?
> 
> 1. Upstream release rate is now a much higher 1-2 kernels a week.
> 2. Very frequently, these releases contain security fixes.
> 3. This rate of release puts arch teams in a difficult position, since
> it is unsustainable to try to keep up tp date with stabilization
> 4. By continuing the policy of providing a stable kernel version, Gentoo
> is giving a false sense of security to its users, since by the time the
> kernel does get stabilized, a newer version more with more security
> fixes is almost always already released.

I agree with all of this, so, who is going to create the news item?  I
think we should do this before 3.10.1 is out, just to start it all
during a new kernel release cycle, which should happen by the end of
next week, pending something causing me to delay it.

thanks,

greg k-h