vanilla-sources new stablization policy

STrRedWolf · n00b Joined: 02 Sep 2002 Posts: 72

For those who don't know, this was in the gentoo repository news:

jimmij · Tux's lil' helper Joined: 02 Dec 2008 Posts: 139

It is already marked longterm on official site
https://www.kernel.org/category/releases.html

ps. BTW, newest 3.10.5 is still terrible buggy so far and freezes very frequently.
_________________
Vanitas vanitatum et omnia vanitas.
Libera temet ex inferis.

asturm · Developer Joined: 05 Apr 2007 Posts: 8935

@STrRedWolf: Upstream stable does not equal downstream stable.

It means it makes no sense to apply the usual stable policy to vanilla-sources when by the time one version is stabilised in Gentoo it is already two or three versions behind latest upstream bump. It will remain ~arch now, but anyone is free to put e.g. =vanilla-sources-3.10* into package.keywords.

@jimmij: Seems your trouble is related to one driver. Others won't be troubled by that at all.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21607

OP: the Greg-KH statement you linked indicates that he plans to support it for longer than he supports normal stable trees, not that it is any more or less reliable than a regular stable tree. As genstorm hinted, and the Gentoo announcement states, no stabilization bugs are needed or wanted. Gentoo lacks the manpower to keyword vanilla versions fast enough to keep up with Greg's releases.

To me, this calls into question the support of the gentoo-sources packages, since they are vanilla-sources plus some Gentoo-specific patches. If vanilla is moving too fast, then either gentoo-sources will cease to track GregKH stable kernel releases (and users will have the problems described in the announcement) or it will track GregKH stable kernels and the only benefit of this change is that for each new release, testers need only work on gentoo-sources-N, rather than gentoo-sources-N and vanilla-sources-N. The announcement says gentoo-sources will continue to be a tested and supported kernel, but it is not clear whether it will continue to be released fast enough to roll out the same security fixes that GregKH is pushing, particularly since upstream Linux developers (not just Greg), have a bad habit of not clearly marking which changes are security related.

hadrons123 · Posted: Sat Aug 10, 2013 3:27 pm Post subject:

I understand that If a package is called vanilla, then there is not too many patches from the downstream. So people should already know what they are getting into when they choose vanilla-sources. But a documentation or wiki info regardging this should help new people before they dive-in.
_________________
LENOVO Y580 FHD Intel® Core™ i7-3630QM CPU @ 2.40GHz × 8 |660M GTX NVIDIA | 16GB SanDisk SSD

TomWij · Retired Dev Joined: 04 Jul 2012 Posts: 1553

Greetings, as a member of the Gentoo Kernel Project I am going to try to clarify any questions or doubts that arrive; answers are from our perspective, such that you know what our intents are and why we make certain decisions. As a disclaimer, not everything I say is necessarily blessed by the rest of the Gentoo Kernel Project or the Gentoo Project; but, I intend to match their thoughts as much as possible.

hadrons123 · Posted: Sat Aug 10, 2013 4:55 pm Post subject:

@Tomwij
Big thank you for your post and clarification of the situation.
_________________
LENOVO Y580 FHD Intel® Core™ i7-3630QM CPU @ 2.40GHz × 8 |660M GTX NVIDIA | 16GB SanDisk SSD

Hu · Moderator Joined: 06 Mar 2007 Posts: 21607

Tom,

I did not mean to imply that you would delay publishing a kernel when you knew it had a security problem. Rather, as you discovered in the thread with Greg, upstream is reluctant to call out even obvious security problems on the (IMO ill-founded) belief that by calling out known security problems, it encourages users to assume all security problems are known. Given that upstream does not highlight security problems, it falls to downstream consumers (whether individual users of vanilla sources or the Gentoo kernel team) to examine the changes and try to determine whether a change fixes an exploitable bug, and how readily the bug can be exploited (remote privilege escalation, local privilege escalation on any system, local privilege escalation if a certain configuration (e.g. CONFIG_USER_NS) is in effect, etc.).

As I understand the referenced thread and others like it from prior discussions, upstream works with the premises that "all fixes could be security fixes" and "all security bugs could be exploited in some way, therefore all security fixes are critical." The latter is disingenuous in my opinion, because a security fix is only critical if it can be exploited by an unauthorized user. If the machine operator believes (hopefully correctly) that he has closed off all avenues by which an attacker could trigger the security bug, then the fix is not critical to the machine. This is especially relevant when the mitigation is simple, such as "unload module Z and remove the corresponding .ko so it cannot be loaded."

TomWij · Retired Dev Joined: 04 Jul 2012 Posts: 1553

Every new feature, refactoring and even fix can possibly introduce another security hole as well; so, if you do not go for the first releases of a new branch and backport known security fixes then you avoid introducing new security holes, basically introducing more security. It doesn't help to choose for a new branch release like 3.10.0 for security fixes if it introduces another set of security holes at the same time. That's yet another reason why we prefer the later releases of a branch.

In my personal opinion there are two ways to give an attacker the chance to attack you; one way is to give him more time, the other way is to give him a bigger set of attack vectors. What we try to do is minimize both to a great extent; by backporting fixes in a reasonable amount of time we do not buy them extra time, and by not taking in new commits that are not stability or security fixes we do not enlarge the attack vector set. What upstream does with its stable releases is not give the attacker any time, yet by introducing a lot of new commits that pertain to new features and refactoring they enlarge the attack vector set. They do the opposite with their LTS releases.

You can not fully minimize both, you must make a choice here: 1) Minimize time. (This is what upstream does with its Stable releases) 2) Minimize the size of the attack vector set. (This is what upstream does with its LTS releases) 3) Try to minimize part of the time and part of the size of the attack vector set, effectively trying to have the best of both worlds; such that neither the delay in time or the size of the attack vector set is a vulnerability. (This is what we do, or at least what I want us to see do; try to stay between Stable and LTS)