Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Of course this particular flamewar started *here* and then graduated to
l-k later on.
Handling kernel security problems
Posted Jul 16, 2008 22:38 UTC (Wed) by pr1268 (subscriber, #24648)
> 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 184.108.40.206 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.
Posted Jul 16, 2008 23:24 UTC (Wed) by PaXTeam (subscriber, #24616)
> 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)
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 attempting to persuade insisting that the kernel devs change their ways may prove futile. Just my $0.02.
Posted Jul 17, 2008 0:45 UTC (Thu) by PaXTeam (subscriber, #24616)
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
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds