Mitchell Stoltz wrote: > A determined cracker can find the exploit himself. The source code is > open, after all. We can't prevent that. What we can prevent is script > kiddies searching Bugzilla for ways to wreak havoc. That is our main > goal. Yes, they could subscribe to your mailing list, but fewer people > will think to look there than Mozilla, and the information they find on > your mailing list will not be sufficient to reproduce the bug. That's > two levels of protection.
You can't be serious. "They won't think to look on your mailing list" is a level of protection? I think that giving a description of the vulnerability (of the user, not of the software -- "your Mozilla configuration data could be read by a hostile web-site operator" for something that exposed addressbook or prefs, for example) is a reasonable thing for an (indirect) provider of consumer software to do. Some might argue (I have) that it's the only responsible thing to do when we know that someone's data or privacy is at risk. I don't think _anyone_ is proposing that we publish exploit recipes widely and early, so debate about arming "script kiddies" seems less than germane. >> If I may issue vage warnings (but a bit more concrete than what Frank >> described) and workarounds at any time > > again, the criteria is "vague enough so that an attacker cannot > reproduce the exploit from your description." That's a great criterion, I think. Given that criterion, can we not post issues to a security.announce list as we find them, and/or mention significant security fixes in release notes? > There's a difference between 'publicly' and 'with your own customers.' I > believe this is a real difference. What happens for a group like Galeon, whose customers are everyone who downloads the software? Can they put a notice on their web site? At that point, we have people seeing that there's a Mozilla security defect on the Galeon web site, and wondering why mozilla.org didn't want to tell people. Speaking of bad PR... I'm having a hard time finding any significant open source project that doesn't talk about security bugs pretty much as soon as they're fixed, and instead relies on the downstream distributors and vendors to provide such notice. Apache, BIND, sendmail, XFree86 -- all of them seem to give public notice when there's a new release to cope with a security bug, if only with an appropriately-conspicuous entry in the release notes. So what I still don't get is why those examples[*] aren't suitable for us to follow. Can someone explain that to me? (I don't really like the "mozilla.org doesn't guarantee your safety, so it can't talk about it" argument, given that Netscape's own EULA disclaims any such warranty or guarantee, in big lawyerly letters.) [*] Examples of the kinds of notice that they give, demonstrating quite nicely the spectrum of provided detail: Apache: http://httpd.apache.org/info/security_bulletin_1.2.5.html BIND: http://www.isc.org/products/BIND/bind-security.html sendmail: http://www.sendmail.org/8.12.1.html XFree86: http://www.xfree86.org/security/ Mike
