IAS wrote: > I got a little bit curious about why finding bugs relevant to security > and fixing them should be not open. I don't doubt that there are both > merit and demerit of discussing those critical issues with full > disclosure. Absolutely there may be some peril that some (bad) people > can misuse the opened information purely exposed to help tomcat > community to collaborate against security problems. Regardless of such > understanding, I feel sorry about loss of the potential that more > openness can give more people chances to figure out the shared troubles > and remind them of importance of security at an early stage.
The problem is when the bad people find out about the security problems before they are fixed. I'm not saying that anyone subscribe to tomcat-dev is 'bad', but the list is archived and google searchable and has a lot of subscribers. All information will become public - it's just that I think it is better ( at least for the bugs we discover ) to first have a fix. You probably noticed most of the announcements on security issues from apache and many other organizations include a fix or at least workaround. It is a common practice to have the security issues forwarded first to some commiters, and then made public. And I think this should be true not only for bugs found from outside, but also from inside. > There was also some comment about "other special issues", which has not > been clear to me yet. It's not clear to me either :-) Maybe short notices like "I want to propose X as a commiter, does anyone has any objection ?" - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. > Basically, I hope every discussion among Apache Jakarta Project > developers would be as open and transparent as possible. Same for me. My main goal was to get all active commiters involved in future security issues. We are all equally responsible. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
