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 : [email protected] 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
