grsecurity 2.1.0 and kernel vulnerabilities
Posted Jan 8, 2005 18:02 UTC (Sat) by bluefoxicy
In reply to: grsecurity 2.1.0 and kernel vulnerabilities
Parent article: grsecurity 2.1.0 and kernel vulnerabilities
I've been hoping they'd split 2.7 out and go with a 6-9 month release cycle. I think the 2.6 development model is great for the odd number branches; but we need a strict bugfix stable branch that's semi-recent (hence, not 2.4 for today).
In this blog entry I talk about the problems with the 2.6 development model being used for a 'stable' tree, opening up by discussing PaX finally catching up on all the VM changes like it shouldn't have to until 2.8.
I then took a page out of whatever book the Ubuntu guys are going for and structured a low-maintenance, long support cycle release mechanism around the 2.6 development model, simply by shifting the model to the odd number branches (2.7) and using the even branches for bugfixes only (security holes are bugs).
Driver backporting can be invasive, and is more work than just bugfixes. Drivers requiring invasive changes (Reiser4 hacked up the FS core a lot) would be forbidden for "Stable" in my design. Drivers that are just drop-in and modify a Makefile and Kconfig slightly are ok, but remember that somebody has to maintain that.
My goal is a release cycle that produces long-term support for stable kernels and timely releases, without stacking too many stable releases on maintainers at once or too much maintenance on a stable release. Maintaining a stable kernel should take about 10-15 minutes of your time per day in net. That means that an hour or two spent on your weekends to merge in a backported security patch is the target.
Unfortunately it seems that I didn't produce a model that would make everybody happy. At the very least I have no support; but that's ok, because I have no experience designing development models, so I'm probably way out of line.
Still, get the damn ball rolling and come up with something.
to post comments)