RFC: Adding a SECURITY.md document to the Binutils

[Michael Matz]

Hello,

On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote:

> And, honestly, these are not standards that are unusually difficult to 
> meet.  Don't dump core, don't use up all of memory, don't have buffer 
> overflows.  Treat failures of this sort as security bugs to be fixed 
> ASAP in minor releases.  These are achievable goals.

These are all noble goals to reach for.  But the fact is that all the crap 
CVE entries from script-kiddies with their fuzzers are mainly fixed by 
Alan with his seemingly endless patience.  Downstream they are the cause 
of endless worries (as customers blindly _demand_ that all CVEs be fixed 
by checking tickmarks on an endless list of entries they've downloaded 
last week from mitre; just by virtue of the entry having a CVE number and 
hence "be a serious security problem").  All of these are bugs to be fixed 
eventually.  Literally _none_ of them are in any way a serious bug 
demanding an immediate fix.  Next release is completely fine for that.

The endless trouble is in either (a) disputing the CVE with mitre, or (b) 
discussing each of the entries with the customer of why it's harmless and 
so on or (c) to backport zillions of useless patches to multiple 
codestreams and (d) to rebuild all stuff with the new patched binutils.  
And _then_ multiply this by the overwhelming feeling of wasting lifetime 
on completely irrelevant, unrealistic and stupid problems that noone in a 
realistic world will hit.  Fixing the (e.g. buffer overflow) bug is good.  
Fixing it "right now because I'm important" is not.

Essentially fuzzers have destroyed any value of the CVE database (they are 
wonderful as bug hunters, don't get me wrong on that; but CVEs are 
meanwhile used as "I'm important, fix my bug right now!!!").  We as 
downstream for instance, since a long time, essentially defer all 
binutiles "CVEs" resulting from fuzzing to the next release of binutils 
(even though updating to new releases in old codestreams brings its own 
problems, they are just a lot easier to deal with than backporting 100 
"CVE" fixes, where each of them poses the danger of introducing an actual 
bug).

If it were me my SECURITY.md text would read "If you get a CVE from a 
fuzzed input we ignore you.  Report it as normal bug and stop hunting for 
a CVE-entry ranking record.", but I can see why that might be a bit too 
blunt :)

Sorry for the rant :)


Ciao,
Michael.