| |||||||||||||
|
| |||||||||||||
Bad Maintainance!Bad Maintainance!Posted Dec 3, 2003 0:26 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Bad Maintainance! by LogicG8 Parent article: The brk() vulnerability you see it as a good thing to discourage people from useing the vanilla tree and instead have everyone use a tree patched with some arbatrary set of patches? (last I heard Suse and Redhat both have >200 patches in their trees) if every distro does this how in the world can anyone track down a bug report? I agree that the way the 2.4 kernel releases have been done tends to encourage this, but I see this as a bad thing as it further fragments the testing base. If a security hole is found and itentified as such (which I agree this was not) then the proper procedure is to apply the fix to the last released kernel, release a new kernel, and then take all the work that was done in the meantime and apply it to this new kernel and pick up where you left off (you can even keep the same preX number if you want) the use of source control systems makes this fairly trivial to do. counting on people to be paying enough attention to every patch that is released to know that it's a security patch and then apply it themselves (or wait for a distro to do so) becouse you have a fixed 'release procedure' is being lazy
(Log in to post comments)
Bad Maintainance! Posted Dec 4, 2003 5:22 UTC (Thu) by iabervon (subscriber, #722) [Link] For vanilla kernels, I think the best idea is really a patch that appliesto all of the affected versions. Releasing 2.4.23 with that as the only change is fine for x86 users with standard hardware, but if you're running on a SA-1110 with a CS integrated NIC that requires a patch that applies cleanly only to 2.4.8, a patched kernel which is very similar to 2.4.2x isn't going to be very useful. Furthermore, this sort of security fix is generally only a line or two in a part of the kernel that doesn't change very much. What I think should happen in this situation is really that Marcelo should bless a particular patch as the correct fix for the problem for each 2.4 release, and kernel.org should distribute it, and it should get into the next release. Fixing this sort of security problem should really be orthogonal to the regular kernel development process.
|
|
||||||||||||