"G. Branden Robinson" <[email protected]> writes:
> A. I am annoyed by this sort of bug submission, not because it reports > issues (only some of which were valid), but because it is larded > with unnecessary analysis, "minimal reproducers" that were anything > but minimal, and delusional recommendations for fixes. > > B. I think addressing the valid reported issues has made groff better. Well said. I've been complaining about this for a while now, but more whiny than you. :) The bug reports are always appreciated, but in the case of obvious memory issues, sending a command line that tickles ASAN doesn't need a multi-paragraph essay copied from an LLM to go along with it. > Characterizing assertion failures as CVE-worthy security holes is, in my > opinion, a corrosive practice. What happens when we don't check the > conditions that assertions? Theory and practice agree: the program > barrels forward in an invalid state, producing unreliable results or, > worse, violates the confidentiality or integrity of host system data. > > That, combined with the project's nature as a suite of command-line > applications and utilities (contrast: network services) is why the groff > project generally does not regard assertion failures as security > problems. The "availability" leg of the "CIA triad" is not implicated. > If the program exits from a SIGABRT signal due to invalid input (which > is almost always the case in groff), no "availability" is lost and a > remedy is immediately at hand--run the program again with _valid_ input. [...] > Feel free to engage with MITRE however you like. I am disinclined to > contribute to the further gamification of CVE allocation. > > https://lwn.net/Articles/953738/ > > To my fellow groff developers, I advise a policy of non-cooperation with > MITRE regarding CVE characterization. Witness Curl developer Daniel > Stenberg's experience. Yes, I'd estimate that a majority of CVEs filed under denial-of-service are totally pointless. Also, a frustrating number of "security" people I have spoken to seem to be under the impression that any time ASAN is triggered, it necessitates there being a security issue. I suspect that the CVE system is mostly used to pad people's resumes and/or to boost numbers on employer websites nowadays. I've also come to the conclusion that it is totally pointless to dispute CVEs, since most CNAs will require the original reporter to agree with your assessment to get it retracted. They obviously have incentives not to agree with your assessment and to maintain the position that it is a security issue. I disputed CVE-2026-53910 [1] in GNU diffutils, which was an obviously silly CVE, since the use of 'diff3 --diff-program' necessitates the user being able to execute arbitrary code, without needing to generate bogus input to trigger out-of-bounds memory accesses. Of course, the reporter didn't agree, so it just has a meaningless disputed label instead of being retracted. I did not bother disputing their GNU coreutils CVEs [2] [3], since I do not have the energy to go through more email threads containing 15 long emails, only for the CVE to get a disputed label. There are various other dubious ones like that, which I find annoying, e.g., a 'sort' one that shows up in CVE scans that large enterprises enjoy doing [4]. I hope that as a side effect of LLM companies making software security their primary form of advertising (unless they continue the switch to math, as seems to be their new fixation), is that more people will realize how pointless most of the CVEs that get filed are. So my message isn't entirely negative; I will say that all of my experiences with the Red Hat CNA have been good. I've had them assign a few CVEs for GNU Inetutils. Collin [1] https://nvd.nist.gov/vuln/detail/cve-2026-53910 [2] https://nvd.nist.gov/vuln/detail/cve-2026-56391 [3] https://nvd.nist.gov/vuln/detail/cve-2026-56392 [4] https://nvd.nist.gov/vuln/detail/cve-2025-5278
