A turning point for CVE numbers [LWN.net]

A turning point for CVE numbers

Posted Feb 15, 2024 1:08 UTC (Thu) by pizza (subscriber, #46)
In reply to: A turning point for CVE numbers by bluca
Parent article: A turning point for CVE numbers

> I'm sure the developers of all past software that was once widespread and then faded into obscurity thought the same at some point or another. It just needs to stop making economic sense to use it,

It's _vastly_ cheaper to keep using it than to replace it with something else. By multiple orders of magnitude.

...Any replacement will necessarily need to be roughly equivalent in features and complexity, and even if you completely discount the initial development costs, you're going to still end up with a similar ongoing maintenance burden.

to post comments

A turning point for CVE numbers

Posted Feb 15, 2024 10:39 UTC (Thu) by bluca (subscriber, #118303) [Link] (6 responses)

It is now, but there is no law of physics that says it will remain cheaper forever, no matter what happens. Intentionally breaking the security tracking system so that it's unusable sounds like a great way to make it more expensive than it was before.

A turning point for CVE numbers

Posted Feb 16, 2024 13:17 UTC (Fri) by hkario (subscriber, #94864) [Link] (5 responses)

It's not breaking anything.

If you have a policy that says you need to ship fixes for all CVEs, then that's a stupid policy. It just conditions vendors to refuse each and every CVE until it goes through arbitration (something proprietary vendors already do).

What consumers of CVEs need to do is be selective, evaluate if the CVE is relevant, what are the effects of exploiting it, etc. and only then backport it to the product they ship that uses the kernel or other CVEs. Same for end users, if the bug is in an API that's not used by any software that is running, then, no, you don't have to install updates.

The problem is that all of it requires actual work, not blind adherence to the policy, and it's for security, so the business also doesn't want to spend money for it.

It's a complex problem and there are no simple solutions.

A turning point for CVE numbers

Posted Feb 16, 2024 13:35 UTC (Fri) by bluca (subscriber, #118303) [Link] (4 responses)

> If you have a policy that says you need to ship fixes for all CVEs, then that's a stupid policy.

Nobody I know of has such a policy, so that sounds like yet another of those made-up strawman that the kernel people pushing for this have conjured out of thin air.

We rely on CVE metadata&al to decide whether we need to pick a fix or not. If the metadata is bogus, because the kernel maintainers just flood the system with bogus CVEs, then we can't do that sensibly anymore, and the process is broken.

A turning point for CVE numbers

Posted Feb 16, 2024 13:43 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> Nobody I know of has such a policy, so that sounds like yet another of those made-up strawman that the kernel people pushing for this have conjured out of thin air.

I worked for a company that had such a policy.

Respectfully, you need to STFU about stuff that is outside your realm of expertise and experience.

A turning point for CVE numbers

Posted Feb 16, 2024 14:09 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)

> I worked for a company that had such a policy.

Sounds like a problem in that company then, why should that justify breaking everything for everybody else?

> Respectfully, you need to STFU about stuff that is outside your realm of expertise and experience.

Respectfully, you need to STFU about my expertise and experience, because you have no idea about either (just like I don't about yours)

A turning point for CVE numbers

Posted Feb 16, 2024 15:32 UTC (Fri) by pizza (subscriber, #46) [Link]

> Sounds like a problem in that company then, why should that justify breaking everything for everybody else?

*shrug* You made an assertion such organizations do not exist (because you didn't know any) and used that to accuse others of making things up or otherwise speaking in bad faith. You were incorrect on both fronts.

You're free to argue that the current status quo has problems (or not). You're free to talk about *your* experiences, and how proposed actions by others will have ill effects on you or third parties.

But you don't get to claim that other people's direct experiences are wrong, incorrect, or irrelevant, and accuse them of bad faith for taking steps to improve the messes they are dealing with, "because you have no idea about either".

A turning point for CVE numbers

Posted Feb 16, 2024 15:49 UTC (Fri) by pizza (subscriber, #46) [Link]

> Sounds like a problem in that company then

Incidently, that company was that way because *EU regulations required them to be*.

(They laid off my research team on the tail end of a major process/policy revamp brought about by new regulations soon to come into effect. I was made to endure many training sessions about how those new/updated regulations affected every part of the overall product lifecycle, from early design to manufacturing to label placement/content to post-sales support to how end-of-life would be handled)

So it's not "that company's problem" so much as "the problem of any company operating in a regulated space"

A turning point for CVE numbers

Posted Feb 15, 2024 11:43 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> ...Any replacement will necessarily need to be roughly equivalent in features and complexity, and even if you completely discount the initial development costs, you're going to still end up with a similar ongoing maintenance burden.

I would beg to differ. How much software - that was perfectly good at doing its job - has been replaced by a FAR inferior solution because one bunch of suits with a big marketing budget schmoozed another bunch of suits with a big spending budget. (Or other things like underhand shenanigans etc etc.)

Okay, there's loads of counter-pressures in place certainly as regards linux, but there's nothing stopping massively inferior solutions driving out far better ones.

Cheers,
Wol

A turning point for CVE numbers

Posted Feb 15, 2024 14:00 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Okay, there's loads of counter-pressures in place certainly as regards linux, but there's nothing stopping massively inferior solutions driving out far better ones.

The problem is that in the real world, _hardware_ (and its configurations, and the expectations of the software running on top of it) is more complex than ever, and that requires ever-more-complex software to sanely manage it. Decry that reality all you want, but at the end of the day, reality doesn't care about feelings.

So I stand by my point. You want "simpler/inferior" operating systems? They already exist [1], and it turns out nobody wants to use them, or invest the (considerable!) effort needed to adapt/maintain them for their own needs.

[1] Or rather, existed, having never grown beyond the "academic toy" status or long since confined to the dustbins of history.

A turning point for CVE numbers

Posted Feb 15, 2024 17:24 UTC (Thu) by Wol (subscriber, #4433) [Link]

> [1] Or rather, existed, having never grown beyond the "academic toy" status or long since confined to the dustbins of history.

And how much software, having started out as an "academic toy", is now mainstream despite being unfit for purpose precisely because it's all the CS grads know?

Pretty much all the software I swear BY, was designed and then built. Pretty much all the software I swear AT, was cobbled together and the cracks papered over. Unfortunately, properly designed software is a rarity :-( It's also usually older software which imho is still better in many cases than its modern replacements, which just aren't "fit for purpose".

Even if it's only in the programmer's head, a truth table of all possible options leads to a far better program than a programmer responding "oh I didn't think of that" when faced with an end user pointing out the beedin' obvious! (And no, I don't expect the first programmer to *implement* all possible options, just the fact that they were considered in the design results in a far better design.)

Cheers,
Wol

A turning point for CVE numbers

Posted Mar 9, 2024 0:50 UTC (Sat) by DanilaBerezin (guest, #168271) [Link] (1 responses)

> It's _vastly_ cheaper to keep using it than to replace it with something else. By multiple orders of magnitude.

This is a pretty large blanket statement that definitely isn't always true. If it were as true as you claim it was, things wouldn't fade into obscurity or ever be replaced. There are plenty of conditions where replacing something is cheaper than continuing to use it. X is a great recent example.

A turning point for CVE numbers

Posted Mar 9, 2024 1:21 UTC (Sat) by pizza (subscriber, #46) [Link]

> This is a pretty large blanket statement that definitely isn't always true.

I didn't claim it was true in a general sense; I only claimed it was true for the Linux kernel.