Policy for posting security bug reports?

[Mike Frysinger]

On Thursday 28 June 2012 08:08:18 Joseph S. Myers wrote:
> 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?

get one free via CACert.org.  apache can do vhosting over https, so you don't 
need multiple ip addresses.

(note: i don't think we need to bother with hiding reports, whether it be via 
locked bugzilla components or hidden in specific people's e-mail inboxes)

> 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 really don't see the logic behind these points.  how is adding a security 
component to bugzilla and having it default to a list of people any different 
from creating a security e-mail alias and having people be listed on that ?  
things will languish just as much if people aren't reading their e-mails, as 
will the list of people who are behind the alias.

glibc doesn't have a dedicated hostname, so there isn't an e-mail address they 
can automatically assume like "security@glibc.org" that people can guess, so 
updating the glibc homepage and/or wiki with a link to bugzilla that 
automatically selects the right components (glibc/security/etc...) is just as 
effective as a mailto link.

http://www.gnu.org/software/libc/development.html:
<h1>Security Reports</h1>
<p>
Please see <a href="http://www.gnu.org/software/libc/bugs.html#security">this 
page</a> for how to report security bugs.
</p>

http://www.gnu.org/software/libc/bugs.html:
<h1><a name="security">Security Reports</a></h1>
<p>
Please report security issues via bugzilla under the glibc product and 
security component.  <a 
href="http://sourceware.org/bugzilla/enter_bug.cgi?product=glibc&component=security">This 
link</a> should take you to the right place.
</p>

> * 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.

sure, and bugzilla is already good at keeping track of unaddressed issues vs 
people's inbox.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120802/8faf6ee5/attachment.sig>