Gentoo Archives: gentoo-kernel

From: Mike Pagano <mpagano@g.o>
To: gentoo-kernel@l.g.o
Subject: Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions
Date: Fri, 21 Jun 2013 19:36:19
Message-Id: 20130621193612.GA4005@woodpecker.gentoo.org
In Reply to: Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions by Greg KH
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

Replies