Costin Manolache wrote:
>
> 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.
Except, this is exactly the kind of thing I think should stay on this
list. A slippery slope indeed.
Maybe all tomcat-dev traffic should be vetted through this other
list first and posted here at a 1 to 2 week delay, just in case
something is mentioned that might turn out with analysis to be a
security risk. The more security through obscurity the better,
right? ;)
The nice thing about your current way of dicussing security issues
(CC e-mail threads) is that it's a real pain in the butt. In other
words, likely only to be used in the cases of necessity.
I think the only way you can keep the new list from feeling like a
double secret exclusive club is to forward _all_ traffic at some
delay and keep that traffic to a minimum. Otherwise, it's going to
start feeling an awful lot like some of you felt when working for
Sun were having extended offline discussions that eventually just
popped up here as a pre-resolved proposal/issue. Wish I could
site a specific case, but it was a while ago. It will be as
frustrating as waiting for a JSR public draft.
Sorry, I didn't mean to go on so long originally. There's just
something about all this that worries me a bit. Perhaps because
noone else seems particularly concerned.
Oh well, what do I know.
-Paul
>
> > 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
