This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus: Security Hall of Fame, Security issue attributions, NEWS, and Contribution Checklist.


On 10/21/2015 04:28 PM, Joseph Myers wrote:
> On Wed, 21 Oct 2015, Carlos O'Donell wrote:
> 
>> I have suggested that we add an attribution section to the NEWS
>> for each release to thank those people who report bugs via the
>> security process and for which those bugs are fixed in the release.
>> This suggestion is now in the Committers checklist[4].
> 
> To be clear: "via the security process" includes the normal case of 
> non-critical bugs that are reported in Bugzilla, with the security nature 
> of the issue being noted in the bug filed (as opposed to reporting 
> somewhere outside Bugzilla, or not mentioning that the bug could be a 
> security issue when reporting in Bugzilla)?  We don't want to encourage 
> unnecessary private reporting.

Yes it does include public bugzilla fillings.

I have called this out specifically by adding a symmetric section called
"Reporting public security bugs"

https://sourceware.org/glibc/wiki/Security%20Process#Reporting_public_security_bugs
~~~
As mentioned under reporting private security bugs we expect that critical security 
bugs are rare, and that most security bugs can be reported in Bugzilla, thus 
making them public immediately. When reporting public security bugs the reporter 
should provide rationale for their choice of public disclosure. 
~~~

> Rather than the suggested NEWS section I'd rather say that each bug with a 
> CVE gets its own entry in the NEWS file (in addition to the general list 
> of fixed bugs) and that those entries credit the reporter.

Would you be OK if we expanded this to all security+ bugs get their own
NEWS entry and that those entries credit the reporter?

While we would like all security+ bugs to have a CVE it isn't a hard and
fast requirement right now, and in some cases we might not get a CVE for
certain bugs, but might still want to mark them security+ and mention
them as security bugs in the release NEWS.

OK with that change?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]