On Dec 4, Roman Drahtmueller
The strategy is clear: Get that stuff out as soon as possible, and make sure under all circumstances that the customer's machines will boot after the update. Right. But are the 3 other major distributors not having such a good QA? In my opinion, you are putting more fixes into the kernel than necessary for this particular bug. And this is costing time. (Of course my postings are also costing your time, but I'm trying to be constructive!) We surely don't want to update our kernels every other week, but everyone of us has critical systems that need to be protected. If I can't rely on the distribution kernel and have to do it myself, it is wasted time for you to put so much effort in it! I've also heard, that the ulimit workaround "fixes" only one of three cases of possible break-in, so it is not a solution.
It's just that you can't make sure that the QA for such an update happens momentarily, even though all resources are working on it. I assume that your ressources are overloaded, and people can't assume the fastest service for buying a 90 EUR box product. But even the debian people made it, although they had this horrible break-in.
PS: I've seen that the update kernel on 9.0 contains stack overflow protection - I've been waiting for that for Years! But at least it is there now :-)) If you guys are running rsync servers, you should disable these until our update packages are out. It is available over YOU - is there something wrong with that one?
kind regards, Markus -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \