This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Policy for posting security bug reports?
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