| |||||||||||||
2.6.32.9 Release notes2.6.32.9 Release notesPosted Feb 22, 2010 17:32 UTC (Mon) by vonbrand (subscriber, #4458)In reply to: 2.6.32.9 Release notes by spender Parent article: 2.6.32.9 Release notes
I'm sorry, but I've to side with the developers here. Just imagine you (as developer) get a bunch of (mostly incomplete, often conflicting) problem reports, and you are at the end able to track down what seems to be the cause. You fix it, and go your merry way chasing the next bug. Or you then sit down trying to organize the whole mess to create an intelligible commit message/impact assesment. Better skip the second part, as it slows down the fixing of bugs. Besides, your assesment could very well be dead wrong (see the oversights in the article for examples), or it might even be that while researching one problem you find (and fix) a completely unrelated issue. Is the poor developer then forced to search all over the reports to check if it fixes something else? This being open source, if somebody wants accurate bug impact assesments, they are more than welcome to contribute the required expertise and manpower to compile and publish them. That this hasn't shown up (only whining that it is not out for grabs) indicates that the need really isn't there... Bugs are bugs, they need to be fixed. Sure, we know by now that anything that could lead to following a bogus pointer (including NULL), or writing past allocated space, or sloppy locking, among others can lead to security problems, and such patches get priority going to stable. Other stuff can be handled with a more cavalier attitude, as long as it isn't shown that it causes (security) trouble. I just fail to see what could be gained by labeling some bugs as security-sensitive while others aren't. The labeling won't ever be correct, so your best bet is to apply all patches. If that isn't enough for your level of paranoia, you won't trust the labels anyway, and (re)do the checking. This is quite beside the fact that what would be a mild or nonexistent problem for one configuration might be lethal in another one.
(Log in to post comments)
2.6.32.9 Release notes Posted Feb 22, 2010 18:19 UTC (Mon) by spender (subscriber, #23067) [Link]
You should give your opinions some context, so that others can know if they should listen to anything you have to say.
1) What distro do you use?
It's obvious you don't do anything in security, and your arguments are nothing but arguing with scenarios you imagined up to suit your own apologist view.
I'd appreciate your answers to the questions above so I can get some perspective on users who share your view (as there seem to be a couple like you on this site).
-Brad
2.6.32.9 Release notes Posted Feb 22, 2010 19:35 UTC (Mon) by nix (subscriber, #2304) [Link]
Why should he? We don't know anything of the kind about you lot
(especially not PaXTeam). Nor should we need to.
For a security person you seem to be asking for an appalling amount of
2.6.32.9 Release notes Posted Feb 22, 2010 20:45 UTC (Mon) by chad.netzer (guest, #4257) [Link]
Wow, Brad. How bogus of you. vonbrand's commentary stands on it's own,
and hardly needs to be vetted. If you disagree with any particular points, you are free to respond to them, or ignore them. People disagree with you on this, deal with it (or be more convincing). Meanwhile, you simply reinforce the label that Linus put out there: "primadonna"
BTW, thanks to LWN for another great article.
2.6.32.9 Release notes Posted Feb 26, 2010 0:29 UTC (Fri) by malor (subscriber, #2973) [Link]
Labeling people is a very convenient way of ignoring true, but uncomfortable things.
2.6.32.9 Release notes Posted Feb 26, 2010 2:23 UTC (Fri) by chad.netzer (guest, #4257) [Link]
You are absolutely correct; an "ignore" label *would* be awfully convenient.
2.6.32.9 Release notes Posted Feb 23, 2010 11:59 UTC (Tue) by NAR (subscriber, #1313) [Link] You fix it, and go your merry way chasing the next bug. Or you then sit down trying to organize the whole mess to create an intelligible commit message/impact assesment. Better skip the second part, as it slows down the fixing of bugs.No, the job of the software developer is not only to fix bugs, but create useful commit messages, because somebody else might look at the same code a couple of years later and would like to know why that change was introduced.
2.6.32.9 Release notes Posted Feb 23, 2010 13:23 UTC (Tue) by hppnq (guest, #14462) [Link] No, the job of the software developer is not only to fix bugs, but create useful commit messages, because somebody else might look at the same code a couple of years later and would like to know why that change was introduced. There is a fundamental difference between a commit message that accurately describes what was fixed (which is not dependent on any other context than the code that was touched), and an assessment of the impact of that fix in what could be a huge range of contexts, most of which have little or nothing to do with the actual implementation.
Not knowing how and when to distinguish between these two is what makes these
|
|||||||||||||