Re: Policy for posting security bug reports?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 27 Jun 2012, Carlos O'Donell wrote:

> Is there anything preventing us from getting https support?

Who is going to pay for the SSL certificate (and keep paying for it each 
time it needs renewing)?  Will separate certificates and IP addresses be 
needed for sourceware.org and gcc.gnu.org?

> Can't we just turn that on in apache and it just works?

No.

Although https is a good idea on general principles, I don't think having 
hidden bug reports in Bugzilla is a good idea; it seems far too likely to 
me that they wouldn't go to the people most likely to be able to help 
resolve them (any list of people who should get them would get out of 
date), would languish unresolved because of not being visible when most 
people search for bugs and not being visible to people following bugs on 
glibc-bugs and if they were genuine security issues would not get opened 
up at the appropriate point after being fixed.

* If you have a single named security bug contact (at most two), getting 
reports via email, who knows they are responsible for seeking help from 
subject area experts and triaging bug reports, *within a few days*, to 
determine validity and impact, then at least you avoid diffusion of 
responsibility from a bug being visible to an opaque set of people that 
Bugzilla might once have been configured to send security bug reports to.

* I think it's more important for people actually to be auditing the glibc 
code for security issues (especially likely types of problems such as 
integer overflows and bad use of alloca, and critical areas such as the 
dynamic linker), and reporting bugs and chasing up to make sure they get 
fixed, than to have some mechanism for bug reports to be secret.

* We don't have enough people fixing bugs as-is to get the bug fixing rate 
significantly above the rate at which bugs are reported, and I don't see 
any reason to think things would be better for security bugs, even if you 
make them public rather than restricting further the number of people who 
can fix them.  For much of the period of active development for 2.16 I was 
trying to do an average of at least one patch a day - a mixture of bug 
fixes, cleanups and cross-compilation improvements.  Will some more people 
join me in trying to do at least one patch a day, with a reasonable 
proportion of bug fixes, for the duration of 2.17 development?  Given that 
there is a large chance that while fixing a bug you discover other related 
bugs, which then need filing for subsequent fixing, and given the general 
background rate at which bugs are filed, we probably need several bug 
fixes a day to make reasonable inroads into the number of open bugs.

-- 
Joseph S. Myers
joseph@codesourcery.com