> it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
If it's just about that, fix those low priority issues and bundle them along with the next higher-priority fix pack, i.e. "lower than low" -> fix but not release immediately; "medium" or higher -> release with any earlier unreleased "lower than low" fixes.
Seeing how much energy you spent in dismissing the person's report on the "lower than low" vuln in https://hackerone.com/reports/3455037, it'd be easier and faster to just fix it rather than argue...
I don't see how that correlates, and that's already pretty much what they do anyway. The reporter's issue wasn't that it didn't get fixed (it did), but that it wasn't given a CVE.
If one person can spend 2 days fighting to prevent 1h of useless work for all of the people running curl, that person has saved the software industry millions of dollars worth of developer time. So it's very much worth it, and I, for one, am very grateful for it.
And make no mistake - havin every user of curl spend time to read this CVE and decide that it doesn't affect that would be 10000% wasted effort for each and every one of them.
According to the linked article, that’s exactly what they did. It was a legitimate bug, but the security consequences were lower than low. It’s a code quality issue, not a security issue, but both are worth fixing.