Many people (like myself) currently uses vanilla kernels on production boxes. The problem with this choice is that right now security patches are not applied to the vanilla tree (and shouldn't be since it's meant to be original kernel.org kernel) and manually applying them from other trees is a pain. It is also worth to mention that we can't of course rely on kernel.org releases for security issues (unless putting a -rc on a production box :( ) So I think it would be really useful to have a new tree composed only by security patches applied to a vanilla tree (and maybe call this linux-sources ?). I've spoken to johnm about this and he's open to the idea, he suggested that an easier way to do this would be applying the upcoming genpatches-base to a vanilla tree, genpatches-base should only contains security stuff and important hardware fixes. I welcome the gentpatches-base idea as long as only security and critical hardware stuff is there, no new features and options. comments / suggestions ? Reproducible: Always Steps to Reproduce: 1. 2. 3.
If a security patch is part of the main tree, but just hasn't made it into an official release yet, I think it's fine to add it if it fixes a known vulnerability. I don't think we need to rename vanilla-sources and I *definitely* don't think we need to add yet another kernel source package to our tree. If anything, perhaps we can add a local use flag -- "security-patches" or something. If it's unset, it's pure vanilla. If it's set, it includes relevant security patches. My $.02.
A "security-patches" USE flag on vanilla-sources sounds good to me :) It might be also good enabling it by default.
I don't think we should have any problems with having this design-wise; we simply need a maintainer who we can CC on security bugs to patch and test vanilla-sources (with these security patches).
There is actually very little differences between vanilla-sources and gentoo-sources (think 2.6 here) However, I would like to holf this off till after the 2005.0 release. Once we have that out the way we can re-address this and see if it really is still relvant. Whats in g-d-s which you find bloatful on top of vanilla-sources? Bare in mind, that any feature patch is minimal foot-print (self-contained in many ways) and is going upstream anyways.
I don't know exactly the differences between g-d-s and vanilla-sources but having a USE flag or whatever to apply security patches against the vanilla tree seems a logical and useful step to me. Also it seems to me that the stable marking timing of vanilla sources could be very different than g-d-s one (I assume that since vanilla has no additional patches it's marked stable as soon as the new kernel is out). For many reasons it's could be very convenient to have the choice of using a "secured" vanilla kernel without reverting to g-d-s. I'm not saying that g-d-s is bloated, it just seems a logical thing to have. Also we don't know what might get included in gentoo-sources in the future so even if now there is no big differences this looks like a sensible approach in case of future changes/issues.
Several other packages in the tree uses USE=vanilla for this.
the -as kernel tree might satisfy this. "Andres Salomon announced a new kernel patchset focused on security and obvious bugfixes. He explained, "I'm announcing a new kernel tree; -as. The goal of this tree is to form a stable base for vendors/distributors to use for their kernels. In order to do this, I intend to include only security fixes and obvious bugfixes, from various sources. I do not intend to include driver updates, large subsystem fixes, cleanups, and so on. Basically, this is what I'd want 2.6.10.1 to contain." <http://kerneltrap.org/node/4545>
I'd say that gentoo-sources-2.6 fills this position. All the feature patches are optional and we control a few of them ourselves. The minimal-patchset model has been working very well. If gentoo-sources does get bloated in the future then perhaps this issue can be raised then. On another note, as-sources is now in the tree.
