RFC: maint: prepare NEWS

[Akim Demaille]

Hi Paul,

Rici Lake drew my attention to something new: people create CVEs about Bison:

- https://nvd.nist.gov/vuln/detail/CVE-2020-14150
  GNU Bison before 3.5.4 allows attackers to cause a denial of service 
(application crash).

- https://nvd.nist.gov/vuln/detail/CVE-2020-24240
  GNU Bison 3.7 has a use after free (UAF) vulnerability. A local attacker may 
execute bison with crafted input file containing a NULL byte, which could 
triggers UAF and thus cause system crash.

In both cases it's about bison itself crashing on carefully crafted junk (read, 
found by fuzzing).  These CVEs cast aspersion on Bison, possibly letting users 
fear that their application is compromised if they use Bison–which of course is 
not the case.

I need to understand how to challenge these CVEs and stop this madness upstream.

Meanwhile, I think we should clearly state where we stand.  As I'm preparing 
3.7.2, I was updating NEWS.  What do you think about it?

Thanks in advance!


commit ec3f6d00adb54b230528d02af70e799480a83607
Author: Akim Demaille <akim.demaille@gmail.com>
Date:   Sun Aug 30 16:15:39 2020 +0200

    doc: updates
    
    * NEWS, TODO: here.

diff --git a/NEWS b/NEWS
index a5c59f0d..6deb94f1 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,25 @@ GNU Bison NEWS
 
   Push parsers use YYMALLOC/YYFREE instead of direct calls to malloc/free.
 
+  Portability issues of bison itself with older compilers.
+
+*** CVEs (Common Vulnerabilities and Exposures)
+
+  Some unlikely crashes found by fuzzing have been fixed.
+
+  This is only about bison itself, not the generated parsers.
+
+  Some CVEs were created about Bison (e.g., CVE-2020-14150 and
+  CVE-2020-24240).  These so-called vulnerabilities are only about
+  bison-the-program itself, not about 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.
+
+  There is no known vulnerability in the generated parsers.
+
+
+
 * Noteworthy changes in release 3.7.1 (2020-08-02) [stable]
 
 ** Bug fixes
@@ -560,7 +579,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):