"Drop all revenue work and rush out a fix" is another.
The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.
No disagreement here. What is dangerous for me is the idea that difficulty upgrading for security fixes does not predict the same difficulty for other fixes. It's not that security bugs are uniquely hard to patch, it's that dependency management on the whole is neglected and security gets the blame.
Those crusty old dependencies and the processes around them are an operational risk, we should be lowering the bar to just patching rather than picking and choosing.
You are assuming that this is about dependencies. OP's example is explicitly "gdb crashes when opening on a malformed core dump and can be used for DoS". If you were working on GDB and got this bug report, would you consider it a fire to be put out immediately? Or would it be a low-impact bug to be looked at when someone gets some free time?
The OP is complaining that, if there is a CVE associated for whatever stupid reason, the bug suddenly jumps from a "might fix" to "hot potato".
I think you're making all sorts of assumptions and extrapolations here that I'm not really seeing any hints of. What I see is that someone is responsible for dealing with CVEs, judges its severity as they come in, and concludes that a lot of them are just cruft and not really worthy of a CVE as such. Nothing more, nothing less.
"Drop all revenue work and rush out a fix" is another.
The previous poster didn't say it should never get fixed, but rather that there's some nuance to be had in these things, and that fixing it in e.g. the next release is usually just fine too.