1 |
On Fri, Jun 21, 2013 at 09:48:41AM -0700, Greg KH wrote: |
2 |
> On Fri, Jun 21, 2013 at 11:30:56AM -0400, Mike Pagano wrote: |
3 |
> > On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote: |
4 |
> > > Hi all, |
5 |
> > > |
6 |
> > > I bumped the vanilla-kernel sources yesterday, and deleted some |
7 |
> > > obsolete, and known-insecure versions at the same time (i.e. the 3.7 and |
8 |
> > > 3.8 ebuilds.) They were added back because they were the last releases |
9 |
> > > marked "stable" for some arches. |
10 |
> > > |
11 |
> > > In thinking about this, that's totally wrong. Either all of these |
12 |
> > > ebuilds are marked stable, or none are. And we should really NEVER have |
13 |
> > > known buggy ebuilds marked stable for the vanilla kernels, as that's |
14 |
> > > just dangerous on many different levels. |
15 |
> > > |
16 |
> > > So, should I just mark these always stable, or never stable? I don't |
17 |
> > > think we should mix the two, as the previous versions are always known |
18 |
> > > buggy, and have problems, and shouldn't be used. |
19 |
> > > |
20 |
> > > thanks, |
21 |
> > > |
22 |
> > > greg k-h |
23 |
> > > |
24 |
> > |
25 |
> > |
26 |
> > Hi, Greg, |
27 |
> > |
28 |
> > We hammered out a policy sometime in the past that if you add a new |
29 |
> > version for the reasons you did and remove the stable ones (that have |
30 |
> > security issues) you can do an auto stable. |
31 |
> |
32 |
> Where was that hammered out? On this list? |
33 |
|
34 |
In bugzilla, and I will locate the bug after I get home from work or |
35 |
tomorrow. |
36 |
> |
37 |
> > I have not gone through the commit log to see what happened but here is |
38 |
> > an easy example. |
39 |
> > |
40 |
> > You know the stable version 3.8.4 has a sec bug. |
41 |
> > You have a minor point release that fixes this. |
42 |
> > |
43 |
> > You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a |
44 |
> > stable keyword for 3.8.4. |
45 |
> > |
46 |
> > This should be written down and if it's not that's probably on me as I |
47 |
> > am the only kernel person (i think) that was involved in the decision |
48 |
> > and is still around. |
49 |
> |
50 |
> But every single stable kernel release I make fixes bugs that some might |
51 |
> consider "security" issues. So that means that every single stable |
52 |
> release should be marked stable, right? |
53 |
|
54 |
This policy was put in place for the really "serious" security issues. |
55 |
It was expected that the person from the kernel team can make the call |
56 |
on whether auto stablizing is the way to go for a particular |
57 |
vulnerability. We were trying to make us more agile when responding to |
58 |
serious root exploits and not look like the distro that is not on top of |
59 |
these things. |
60 |
|
61 |
> |
62 |
> We should _never_ have an end-of-life kernel marked stable, that's just |
63 |
> asking for trouble. |
64 |
|
65 |
|
66 |
> > P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick |
67 |
> > "emergency" stabilization effort by the arch teams. |
68 |
> > |
69 |
> > Let me know if that is clear as mud. |
70 |
> |
71 |
> It's clear, but I feel incorrect :) |
72 |
> |
73 |
> As we can't do anything to these releases to fix problems or "make them |
74 |
> more stable", they should either always be unstable, or always be |
75 |
> stable, there is no difference. |
76 |
|
77 |
I am not against either. And I think this is the way to go. (always |
78 |
unstable). |
79 |
|
80 |
Let the user know that we always provide the latest kernel we can and |
81 |
they need to always upgrade as you always suggest during upstream |
82 |
releases. |
83 |
|
84 |
Users have a certain level of expectation and since no kernel version |
85 |
can be considered vulnerability free for long maybe we do them a |
86 |
disservice by giving them a false impression that a kernel version is safe and stable. |
87 |
|
88 |
I would ask others's on the team (or not on the team) to consider this idea. |
89 |
|
90 |
At some point we can pull straws and bring this to -dev. |
91 |
|
92 |
> |
93 |
> thanks, |
94 |
> |
95 |
> greg k-h |
96 |
> |
97 |
|
98 |
|
99 |
-- |
100 |
Mike Pagano |
101 |
Gentoo Developer - Kernel Project |
102 |
Gentoo Sources - Lead |
103 |
E-Mail : mpagano@g.o |
104 |
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 |
105 |
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index |