On Jul 28, 2011, at 4:23 PM, Rob Weir wrote: > On Thu, Jul 28, 2011 at 6:59 PM, Wolf Halton <[email protected]> wrote: >> One of the things I think proprietary projects are wrong about is treating >> bugs, including security bugs, as secret private things. The best security >> solution we have is the number of eyes we allow to see the problems. I think >> emulating the paranoia is a mistake. Security-related bugs should go to the >> bug squashing system all bugs go to. Triage and fixes can then follow, and >> the more security-skilled coders can take it from there. >> >> Just my .02¢ >> > > Two kinds of vulnerabilities: > > 1) Those that are newly discovered by this project itself, or by a > responsible third party that has reported it to us. The vulnerability > may be serious, but the threat is still latent because the bad guys > don't know about it yet. But there is some urgency to fix the issue, > because the bad guys will find out soon eventually. > > 2) Those vulnerabilities that come to our attention only after they > are actively being used in an attack, the so called zero-day exploit. > > I think in case #2, there is no great reason to keep it a secret. The > "cat is out of the bag" already. But in case #1, and that is the most > common case, I think it is absolutely critical to keep the > vulnerability from becoming public information until the project has > published a patch. At that time there are standards for reporting the > vulnerability so customers have a fair shot at hearing about the > problem and patching their systems before the bad guys have time to > deploy an exploit based on the vulnerability. Once the information is > public, it is a race, between users/admins and the bad guys. Our job, > in an open source project, is to do whatever we can to make sure the > users/admins have a chance to win. > > I would agree with you that security related code should be public and > discussed in public. That is one advantage that open source has. We > can have many eyes review our code. But when you have a report of an > exploitable vulnerability, that is something else. At that point a > race has started. Will we patch the issue before someone exploits it? > Or will the black hats win?
Have a look at the Apache Tomcat Security page: http://tomcat.apache.org/security.html Here is what is said about their security mail list in boldface type. > Please note that the security mailing list should only be used for reporting > undisclosed security vulnerabilities in Apache Tomcat and managing the > process of fixing such vulnerabilities. We cannot accept regular bug reports > or other queries at this address. All mail sent to this address that does not > relate to an undisclosed security problem in the Apache Tomcat source code > will be ignored. It is interesting to see the type of information about each CVE and the fixes on three different Tomcat versions. Regards, Dave
