4 ms·
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
by beardedwizard 6y ago
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.
- arp242 6y agoWho is talking about "crusty old dependencies"? Or processes which are an "operational risk"? The previous poster never mentioned any of those things.
- beardedwizard 6y agoThey get old and crusty when you have to choose not to patch, or de prioritize those not so serious bugs because the operational cost is too high. Developers shouldn't have to make this call, the cost should be zero.
- arp242 6y agoI 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.
- beardedwizard 6y agoI see your point
- tsimionescu 6y agoYou 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".
- beardedwizard 6y agoThat's fair