| 1 |
On Fri, Jun 21, 2013 at 03:36:12PM -0400, Mike Pagano wrote: |
| 2 |
> > > This should be written down and if it's not that's probably on me as I |
| 3 |
> > > am the only kernel person (i think) that was involved in the decision |
| 4 |
> > > and is still around. |
| 5 |
> > |
| 6 |
> > But every single stable kernel release I make fixes bugs that some might |
| 7 |
> > consider "security" issues. So that means that every single stable |
| 8 |
> > release should be marked stable, right? |
| 9 |
> |
| 10 |
> This policy was put in place for the really "serious" security issues. |
| 11 |
|
| 12 |
Who is making the judgement call about "serious"? And how do you know |
| 13 |
that problems aren't being fixed that aren't "serious"? |
| 14 |
|
| 15 |
> It was expected that the person from the kernel team can make the call |
| 16 |
> on whether auto stablizing is the way to go for a particular |
| 17 |
> vulnerability. |
| 18 |
|
| 19 |
Trying to track vunerabilities across kernel versions is going to be |
| 20 |
hard, especially for ones that are not public yet :) |
| 21 |
|
| 22 |
> We were trying to make us more agile when responding to serious root |
| 23 |
> exploits and not look like the distro that is not on top of these |
| 24 |
> things. |
| 25 |
|
| 26 |
I understand, and I think the work done on the "normal" kernel ebuilds |
| 27 |
are great this way. This is just for the vanilla kernels, they should |
| 28 |
track the upstream releases directly, no need for any Gentoo developer |
| 29 |
to make a judgement call on when something is "stable" or not, as again, |
| 30 |
there's nothing they can do about it. |
| 31 |
|
| 32 |
> > As we can't do anything to these releases to fix problems or "make them |
| 33 |
> > more stable", they should either always be unstable, or always be |
| 34 |
> > stable, there is no difference. |
| 35 |
> |
| 36 |
> I am not against either. And I think this is the way to go. (always |
| 37 |
> unstable). |
| 38 |
> |
| 39 |
> Let the user know that we always provide the latest kernel we can and |
| 40 |
> they need to always upgrade as you always suggest during upstream |
| 41 |
> releases. |
| 42 |
|
| 43 |
Great. |
| 44 |
|
| 45 |
> Users have a certain level of expectation and since no kernel version |
| 46 |
> can be considered vulnerability free for long maybe we do them a |
| 47 |
> disservice by giving them a false impression that a kernel version is |
| 48 |
> safe and stable. |
| 49 |
|
| 50 |
I totally agree. |
| 51 |
|
| 52 |
> I would ask others's on the team (or not on the team) to consider this idea. |
| 53 |
> |
| 54 |
> At some point we can pull straws and bring this to -dev. |
| 55 |
|
| 56 |
I can do this if no one else wants to, as I know a bit about how |
| 57 |
upstream works in this area :) |
| 58 |
|
| 59 |
thanks, |
| 60 |
|
| 61 |
greg k-h |
Archives