tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Speed <psp...@progeeks.com>
Subject Re: Vote results + Security Audit redirection
Date Thu, 17 Oct 2002 14:14:59 GMT


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:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message