Gentoo and Security Updates
While it pains me a bit to say this, and I don’t have a great deal of time to type this, I wanted to at least try to get some kind of word out to our user community that the high-profile kernel regression announced a few weeks ago (and fixed a few weeks ago in almost every other distro), remains a vulnerability in Gentoo with no clear timeline for resolution.
Gentoo bug 337654 is tracking this issue.
Users can emerge a more recent version of gentoo-sources to get the patch, and I’d recommend doing so if local root exploits are something that concern you.
I’d like to dwell a bit longer on solutions, but I don’t really have time to do so right now. Clearly the kernel team could use help with security issues. The security team probably could use help as well in staying on top of these kinds of issues. I don’t want to kick people when they are down – Gentoo is an all-volunteer effort. However, situations like this really don’t do much to improve the reputation of the distro, and at the very least we need to inform users when problems like this arise.
Rich0's Gentoo Blog 
We have a stable request for 2.6.32-r18 in bug #338317.
Arch teams will not stabilize 2.6.35 for reasons described in the bug #334341 and described on a blog post of mine: http://www.mpagano.com/blog/?p=140. I worked very hard to get a baselayout-1 patch so we can get past the issue and request a stable BL after 30 days.
We should have had one for 2.6.34, which I just opened. Instead of being “pained” and blogging about our incompetence, just open a stable request yourself, or send me an email. I always respond.
“so the kernel maintainers would probably prefer that you not complain to them”
Probably? Are you guessing here?
You are completely *wrong* that we don’t want user’s complaints when using gentoo-sources. What have I been doing here for the last two years? Please correct that line in a subsequent post. It does nothing for our reputation if we state erroneous information that serves nothing except for falsely making us look bad.
I am very disappointed reading this.
mpagano
October 5, 2010 at 9:37 am
A bug already is open – the one I referenced in my post. I’ve tried to ping it a few times – and security@ and kernel@ are both on the CC list.
There have also been posts to the gentoo-security mailing list.
As far as maintainer concerns with users using unstable packages goes – the general dialog on that bug suggested that the kernel team wasn’t yet ready to call it stable, and I did want users to avoid blaming them if the new version did not work. That was not in any way intended as a slight to the team’s attitude.
I do have concerns with the delays in stabilizing the security bug. However, being that it isn’t stable I don’t expect the team to support the unstable versions. If that came across in an way that was not intended please do accept my apologies. However, the delay in addressing a security vulnerability (targeted for 3 days in the security policy) doesn’t reflect well on Gentoo. I’m not really interested in figuring out whose fault that is, but perhaps there is something we can do in the future to make the process work better.
rich0
October 5, 2010 at 6:21 pm
This post stinks as this is all out of date 😉
The (very) hot discussion about kernel update strategy has emerged several times, last time somewhere about this:
https://bugs.gentoo.org/show_bug.cgi?id=278122
Look at mailing lists during these times, it was said many times that unmasking just because of upstream bug is wrong. Let the kernel team do their job right.
Stefan
October 5, 2010 at 10:04 am
Well, if a package has a bug we have a few options:
1. Stabilize a newer version containing the fix.
2. Backport the fix to the currently stable version, and stabilize that.
3. Mask the package as being insecure.
#3 clearly is not a good option for gentoo-sources. So, we have to do #1 or #2. I didn’t in any way suggest that #1 was the best solution.
In any case, critical security issues really need to be fixed in three days. That’s just Gentoo policy – and really it isn’t asking a whole lot for an issue of this magnitude. If it dragged out to five days with arch teams/etc, that would be one thing. However, in this case we are going on three weeks, with not even a timeline for completion.
If it wasn’t my intention to let the kernel team do their job I’d have just keyworded it stable myself. Clearly that isn’t the right solution, and so I am not doing this. However, the process clearly has broken down somewhere…
rich0
October 5, 2010 at 6:26 pm
“so the kernel maintainers would probably prefer that you not complain to them if your system doesn’t boot/etc”
This is false. I’m maintaining the hardened-sources and this does not reflect my attitude, nor of any of the kernel maintainers I know, like mpagano above.
I spent two days testing out the fixed hardened-sources kernel on every hardware I had, from tiny netbooks to my HP DL 385’s with grub and lilo boot loaders. I then broke QA rules [1] and stabilized way ahead of time. I then asked the community to please report any problems asap [2].
Please do your research before making claims like that.
[1] http://bugs.gentoo.org/show_bug.cgi?id=338273
[2] http://archives.gentoo.org/gentoo-hardened/msg_c39b2fd4501fd83f1ae3bc4e52d3dc7f.xml
blueness
October 7, 2010 at 9:22 am
My intent was not to speak for the kernel team one way or another. I didn’t want to imply that if a user followed my advice to run a newer kernel that the kernel team would support them since the new versions were not stable. I figured that if they were considered suitable for production use that they would be keyworded as such.
I’ll go ahead and remove that sentence since there seems to be a consensus that the kernel team is willing to support the newer revisions.
Again, no malice was intended by that statement.
rich0
October 7, 2010 at 9:36 am