Recent Features
| |||||||||||||
Handling kernel security problemsHandling kernel security problemsPosted Jul 16, 2008 22:38 UTC (Wed) by pr1268 (subscriber, #24648)In reply to: Handling kernel security problems by nix Parent article: Handling kernel security problems
> and then graduated to l-k later on I suppose Pax Team finally got the message Greg K-H was trying to make. Of course, Pax Team still kept on during the LWN 2.6.25.11 release announcement. While I agree with Pax Team's philosophy that software bugs should be categorized on their severity (in order to help sysadmins, distro developers, and end-users prioritize updates), I feel that it's more important that the kernel developers not be bothered with having to do this taxonomy. As Linus said recently, "A bug is a bug." There are other groups, organizations, enterprise-level software distributors, and such whose task is to assess the severity impact of software bugs. (Disclosure: I've also asked on LWN about the recent rash of bugfix releases to 2.6.25 and requested clarification of the "strongly encouraged" verbiage I keep hearing in Greg's announcements.) I think Pax Team has heard the best answer he's going to get from the kernel devs. If he keeps up the flamewar, then likely it's because he hasn't heard an answer that he likes.
(Log in to post comments)
Handling kernel security problems Posted Jul 16, 2008 23:24 UTC (Wed) by PaXTeam (subscriber, #24616) [Link] > I think Pax Team has heard the best answer he's going to get from the > kernel devs. If he keeps up the flamewar, then likely it's because he > hasn't heard an answer that he likes. actually i don't think it was much of a flamewar at all. all that happened was that i tried to figure out what kernel devs actually think about security bugs, and why they think that. i got answers to both and that's about it. as time permits, i'll continue to point out security problems that they cover up because there is an apparent need for it.
Not much of a flamewar at all Posted Jul 17, 2008 0:01 UTC (Thu) by pr1268 (subscriber, #24648) [Link] Thanks for the reply and clarification. My use of the term "flamewar" was meant in the broadest sense of the word. My bottom paragraph describes how I perceived why you continued to post replies to the LKML even after many of the senior kernel devs had already pitched in on why they do things the way they do.
You're certainly welcome to you opinion that "there's an apparent need for [security problems being covered up]", and I partially agree with you in this matter, but continued discussions and debates on the LKML
Not much of a flamewar at all Posted Jul 17, 2008 0:45 UTC (Thu) by PaXTeam (subscriber, #24616) [Link] oh, i think i know what you were thinking of as 'flamewar' then. basically, the program was this: ask the kernel devs how they handle security bugs (what goes into the commits, what gets announced, etc). once that was clear (essentially, not full-disclosure but non-disclosure, or coverup), i got interested in why they decided that that was the best way for them. note i did *not* want to change their minds per se, but as having some background and experience in security, i thought maybe they based their decision on flawed assumptions (that i've seen so many times) and if explained/corrected, they may rethink their position - or i would learn something new. so i asked further about the justification for not including security info in commits/announcements/etc and got all kinds of silly reasons that were easy to explain. that it didn't have any effect and we ended up with 'we do it just because' is not my fault, nor do i consider it a success to learn about their motives. so that's about it, we'll continue to go different ways.
|
|||||||||||||