diff mbox

Fix nan functions handling of payload strings (bug 16961, bug 16962)

Message ID 5661EB3B.2060507@redhat.com
State New
Headers show

Commit Message

Carlos O'Donell Dec. 4, 2015, 7:36 p.m. UTC 
On 12/01/2015 07:50 PM, Joseph Myers wrote:
> On Mon, 30 Nov 2015, Florian Weimer wrote:
> 
>> On 11/27/2015 01:26 AM, Joseph Myers wrote:
>>
>>> Carlos, the NEWS entry is a consequence of what you said in
>>> <https://sourceware.org/ml/libc-alpha/2015-10/msg00776.html> about
>>> security+ bugs (such as this one, involving an unbounded stack
>>> allocation from what could theoretically be untrusted input) getting
>>> such entries.  Does it seem right to you?  Once the NEWS entry is
>>> resolved, I intend to commit this patch.
>>
>>> +* The nan, nanf and nanl functions no longer have unbounded stack usage
>>> +  depending on the length of the string passed as an argument to the
>>> +  functions.  Reported by Joseph Myers.
>>> +
>>
>> I think reporters of security bugs want their bugs marked as security
>> bugs.  This could be achieve by putting them into a separate section, or
>> adding a “SECURITY: ” prefix or something like that.
> 
> Any other comments on the NEWS entry, supposing such a prefix to be added?

The NEWS entry looks good to me.

However, I agree with Florian that we need to call out the security related
changes in a distinct section e.g. "Security related changes:", though I'm
open to suggestions for how to name it or if it comes first or last in the
list of changes.

Additionally I think it would be nice to put security+ bugs in their own
bug list, which involves enhancing or running a different script with query
to get the list of those bugs.

e.g.

---



Cheers,
Carlos.

Comments

Joseph Myers Dec. 4, 2015, 8:44 p.m. UTC | #1 
On Fri, 4 Dec 2015, Carlos O'Donell wrote:

> The NEWS entry looks good to me.
> 
> However, I agree with Florian that we need to call out the security related
> changes in a distinct section e.g. "Security related changes:", though I'm
> open to suggestions for how to name it or if it comes first or last in the
> list of changes.

I've committed the patch with the entry in such a section.

> Additionally I think it would be nice to put security+ bugs in their own
> bug list, which involves enhancing or running a different script with query
> to get the list of those bugs.

If we want to add such an option to list-fixed-bugs.py, we should first 
review <https://sourceware.org/ml/libc-alpha/2015-11/msg00191.html> which 
makes it use argparse.  Then, you can add 
&f1=flagtypes.name&o1=substring&v1=security%2B to the URL to get security+ 
bugs (currently three such bugs are listed, 16962, 18240, and 18928, so a 
NEWS entry needs adding for 18240 and that for 18928 (LD_POINTER_GUARD) 
needs moving into the new section and updating to list the reporter.

However, if we're giving each such bug its own NEWS item I don't see the 
use in also having the abbreviated list of such bugs (making the script 
generate it may be helpful, however, in that the release instructions can 
say "make sure each bug listed by list-fixed-bugs.py -s <version> has its 
own NEWS item in that section, naming the reporter and giving the CVE 
identifier").  We can put bug numbers and CVE identifiers in the bugs' own 
NEWS items if we wish.
diff mbox

Patch

diff --git a/NEWS b/NEWS
index cb61a3a..295d747 100644
--- a/NEWS
+++ b/NEWS
@@ -60,6 +60,17 @@  Version 2.23
   C Library is GCC 4.7.  Older GCC versions, and non-GNU compilers, can
   still be used to compile programs using the GNU C Library.
 
+Security related changes:
+
+* The nan, nanf and nanl functions no longer have unbounded stack usage
+  depending on the length of the string passed as an argument to the
+  functions.  Reported by Joseph Myers.
+
+* The following security bugs are resolved with this release:
+
+  [Some other script which generates the list of security+ bugs
+   resolved in this release.]
+
 * The following bugs are resolved with this release:
 
   [The release manager will add the list generated by