Date: Wed, 6 Mar 2013 03:27:39 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: handling of Linux kernel vulnerabilities Noel - On Wed, Mar 06, 2013 at 08:48:57AM +1000, Noel Butler wrote: > I kinda agree with Kurt, this thread is like flogging a dead horse, so > much so Im starting to skip most posts in this thread, Apparently, your skipping got to the point where you don't realize what's being discussed, as evidenced by some of the confusion below in your posting. ;-) I'll try to explain (below). > cause if I want to put to sleep Ill go outside and watch the grass grow :) Thank you for sharing your opinion. The reason why I felt I needed to comment on Kurt's posting was that it (inadvertently) sounded like a list moderator's, whereas it was not, and that it said that oss-security was not the right venue, which was not true (again, this error on Kurt's part was not intentional, as he explained to me off-list). > current way of doing things has worked for a long time, and, if it aint > broke, dont break it. We've just had several examples of the current way of handling Linux kernel vulnerabilities not working as well as many of us would have liked it to, and, as many of us think, as it could work. This is precisely what prompted the discussion. > apart from that, it reads to me that some here just want to increase > their own importance and inflate their own egos, sorry, but that is > EXACTLY how I see things, like your insistence that Greg et al, post > notices about commits here days before publishing them. I never insisted that Greg et al. "post notices about commits here days before publishing them". (How would that even be possible? Posting in here is publishing.) I said that I wished (not insisted) that Greg et al. posted notices about commits in here on the commit day (not "before", but at about the same time with commits - even a few hours later is OK, just on same day). I also said that I had little hope they would, as they said so before, so I did not argue about that (others had done plenty of it). Thus, in my posting I focused on what we should do given that Greg et al. won't be notifying oss-security, but would only be notifying linux-distros. This was not a repeat of any past discussion, as far as I'm aware, although the general and fundamental issues involved are very old indeed. I am referring to this posting: http://www.openwall.com/lists/oss-security/2013/03/04/1 As you can see, I made this posting in response to a specific question from Petr. The question was directly addressed to me and thus required a response, and a public one. I also asked Greg a practically relevant question, and got his response: namely, that linux-distros "can notify the world when they decide to do so". Before that point, it was unclear to me (and apparently to Petr as well) whether linux-distros would be required to keep the info private (despite of the public commits...) for at least a certain minimum time period. This will have impact on how we proceed. It's not just blabbering. > the net's got enough ego tripsters now, thanks, I left other security > lists because of people with inflated heads, sorry if thats not your > intention, but, that is how it comes across, and you know what they say, > never does just one person think something. I think your impression is in part a result of you not paying attention to what's actually being discussed. Perhaps you saw some "trigger words" and some familiar rhetoric in some of the postings, and stopped paying attention at that point. And yes, I'm sure some others reading this thread have similar impression. Besides the likely pointless arguing (as it is unlikely anyone's opinion will change), we're discussing very practical issues that will affect how and to whom information on Linux kernel vulnerabilities is communicated and with what delays. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ