Hi Paul, Thanks for the answer!
> Le 30 août 2020 à 19:19, Paul Eggert <[email protected]> a écrit : > > I stopped worrying about CVEs like those long ago. They're not important and > anybody who knows security knows they're not important. I do not understand the point of submitting such CVEs. I find disturbing that there are no authors. > We could say something like the following, I suppose. Or maybe you'd want to > tone it down a bit. > > "This release of Bison fixes all known bugs reported for Bison in MITRE's > Common Vulnerabilities and Exposures (CVE) system. Although these bugs are > typically irrelevant to how Bison is used, they are worth fixing if only to > give users peace of mind." Tone down? I find your wording extremely toned down already :) I was really aiming at making clear that these entries are worthless. A pure waste of time for everybody. Here's a mixture of your words with mine. WDYT? commit a6e71b4f92f2d9d74d9212f575d9e3bd27689c84 Author: Akim Demaille <[email protected]> Date: Sun Aug 30 16:15:39 2020 +0200 doc: updates * NEWS, TODO: here. diff --git a/NEWS b/NEWS index a5c59f0d..7f4e72c3 100644 --- a/NEWS +++ b/NEWS @@ -2,9 +2,29 @@ GNU Bison NEWS * Noteworthy changes in release ?.? (????-??-??) [?] + This release of Bison fixes all known bugs reported for Bison in MITRE's + Common Vulnerabilities and Exposures (CVE) system. + + These "vulnerabilities" are only about bison-the-program itself, not the + generated code. Users should not worry about them: the worst that can + happen is bison crashing on invalid input. This is very much like an + Internal Compiler Error (ICE), and of course there is no reason to create + a CVE for every single ICE. + + Although these bugs are typically irrelevant to how Bison is used, they + are worth fixing if only to give users peace of mind. + + There is no known vulnerability in the generated parsers. + ** Bug fixes - Push parsers use YYMALLOC/YYFREE instead of direct calls to malloc/free. + Push parsers always use YYMALLOC/YYFREE (no direct calls to malloc/free). + + Portability issues of the test suite, and of bison itself. + + Some unlikely crashes found by fuzzing have been fixed. This is only + about bison itself, not the generated parsers. + * Noteworthy changes in release 3.7.1 (2020-08-02) [stable] @@ -560,7 +580,8 @@ GNU Bison NEWS \005) with incorrect styling. Fixes for similar issues with unexpectedly short lines (e.g., the file was changed between parsing and diagnosing). - Several unlikely crashes found by fuzzing have been fixed. + Some unlikely crashes found by fuzzing have been fixed. This is only + about bison itself, not the generated parsers. * Noteworthy changes in release 3.5.2 (2020-02-13) [stable] diff --git a/TODO b/TODO index b8b2befb..e9874678 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,12 @@ -* Bison 3.7 +* Soon +** gnulib +Bruno notes: + +> I haven't looked deeply, but it strikes me that gnulib/lib/bitset/array.c +> does not make use of the 'ffsl' function, nor or the 'integer_length_l' +> function. Maybe because in Bison, all bitsets are so dense that it does +> not give a performance advantage? + ** Cex *** Improve gnulib Don't do this (counterexample.c):
