mort

(replying to mort)

But no seriously what the fuck is @gregkh trying to achieve here? Before, I could use a CVE count as an argument to spend time upgrading : "there have been found 5 vulnerabilities in the version we use, we should upgrade to the latest". These days, CVEs are useless for that purpose, everyone knows that pretty much every single one of the thousands of "CVEs" affecting the kernel version we're on is bogus so they aren't useful for that purpose any more so we stay on old kernels for longer

Morten Linderud

(replying to mort)

@mort @gregkh

Using CVE counts as an argument this way has always been bogus though, regardless of what is currently happening.

mort

(replying to Morten Linderud)

@Foxboron No.

Morten Linderud

(replying to mort)

@mort

Of course it has. CVE identifiers have been misinterpreted/misused/misunderstood this way for years.

mort

(replying to Morten Linderud)

@Foxboron No

2 replies →
2 replies

tbodt

(replying to mort)

@mort @Foxboron i scrolled briefly through the list of cves assigned last friday and it looks like the largest chunk are memory safety issues. maybe you should update your kernel... though most of them are in optional components. maybe it would be useful to include metadata on the cve describing what kconfig you need for the affected code to be compiled in

Saagar Jha

(replying to mort)
@mort @Foxboron You can keep saying no all you want; it doesn’t make it any more true. CVEs have basically never been an accurate representation of changes that have security impact. Actually trying to do this remains an open problem that requires significant resources.

Saagar Jha

(replying to Saagar Jha)
@mort @Foxboron You’re upset that the situation went from “these are 10% of the security bugs and each one is definitely bad” to “this is 100% of the security bugs and maybe 10% of them are definitely bad”. Neither helps you solve the problem you have of “should I update”.