|
Message-ID: <20130227161547.GC21645@kroah.com> Date: Wed, 27 Feb 2013 08:15:47 -0800 From: Greg KH <greg@...ah.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request - Linux kernel: VFAT slab-based buffer overflow On Wed, Feb 27, 2013 at 07:08:58PM +0400, Solar Designer wrote: > On Wed, Feb 27, 2013 at 06:48:34AM -0800, Greg KH wrote: > > On Wed, Feb 27, 2013 at 07:31:30AM +0100, Petr Matousek wrote: > > > For starters, security@...nel.org submissions should be posted to > > > oss-security or any other security related public mailing list when the > > > patch is being committed. > > > > That's not going to happen, and you know that, to do so would be totally > > irresponsible of us and directly harm your users. > > Huh?! Maybe you misread what Petr wrote? Note: "when the patch is > being committed". At this point, the security issue is public, and it > just needs to be properly communicated to all those interested > (including distros, sysadmins, etc.), such as via oss-security. Not > doing this favors those few who spend time to review commits on their > own; some of them do it for purposes other than informing the public. We (the kernel team) well know this, and have been over this topic numerous times in the past. We have come to the conclusion that it is not good for us to be publicly stating "here look, here's how you exploit the kernel!" at the exact moment we commit the patch to the public tree because suddenly you now have shown how all systems in the world are exploitable, with no chance for anyone to have protected their systems ahead of time. Instead, we have no problem with groups like vendor-sec being notified of these issues, and allowing them to push out updates, before _they_ notify the world of the problem. And, for a long time, I thought vendor-sec was being notified of all of the issues that security@...nel.org knew about, if this has suddenly changed, please let me know and I will be glad to resolve it. Yes, this does seem to favor those who pay closer attention to the commits going into the tree than those who do not, but we do this to try to balance the needs of the larger majority of users. It's a tough problem, full of grey areas, like the real world requires, and I personally wrestle with it all the time. At the moment, I feel this is the best that we have come up with, and I know that others strongly disagree, which is fine, debate about stuff like this is good to have. thanks, greg k-h
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.