> So what's wrong in keeping them public? > If they are false alarms, why not keep > them public and show all other people who think they found > serious security related bugs that they are wrong? > If it's opensource KEEP it open. There can't be any closed > 'groups' which get some info in this kind of projects. > If there are, it's no longer opensource..IMO.
Two issues: 1. A private correspondence channel was requested. You are saying there cannot be private communications in open source? Believe me there is plenty of private communications going on in all the various open source projects and it doesn't make them any less open source. Telling someone that they are not allowed to communicate with members of the PHP development team in a private manner makes no sense. Perhaps we need a [EMAIL PROTECTED] private mailing list for this instead where only people with php-dev cvs accounts can subscribe and either not archive or at least delay the archiving of messages to the list by a couple of weeks. 2. If this is indeed a big security hole we have to treat it in a responsible manner. We need to communicate the problem as quickly as possible *along with the fix*. It is common practice, bugtraq and elsewhere, to not publically announce security issues without an accompanying fix so that you aren't giving the black hats a big window of time to exploit the security hole. That doesn't mean we can just sit on a security issue, we have to address it in a timely manner, but I see nothing wrong with limiting the distribution list and certainly not immediately injecting an exploit into every search engine in the world. -Rasmus -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
