Hacker News new | ask | show | jobs
by __bjoernd 41 days ago
If they get enough time to build a website with a fancy logo instead, one might however question where their priorities are.
1 comments

I'd imagine it's not that they lacked the time to email linux-distros, but that they were unaware they were supposed to do so.

Feels like the more sensible process would be for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability and for distro maintainers to pay attention to that. Could be done without revealing what the vulnerability actually is in most cases, trusting the kernel maintainer's judgement. There does seem to be a public linux-cve-announce mailing list.

> Could be done without revealing what the vulnerability actually is in most cases

No it can’t. The bad actors that should actually worry most people are actively combing through commits on mainstream codebases, using a combination of automation/AI and manual review to pluck vulns out by their remediations.

The patch itself can be made to look fairly innocuous, as was done here. Won't always successfully prevent bad actors finding the vulnerability, but seems better to at least not unnecessarily increase that risk.
I’m saying it doesn’t matter how innocuous you try to make the patch when there are known bad actors directly evaluating every commit for “so did this close a vuln”, using both AI and human expertise.

This is true no matter what, but the comment I’m replying to was also pitching that maintainers actively call out that the patch includes a high sev security fix:

> for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability

I'm suggesting that less information about the vulnerability could be circulated than the current process, not more, due to distro maintainers being able to trust just "version X contains a fix for a high-impact security vulnerability" coming from a kernel maintainer - whereas they'll need some information/proof of that claim when coming from an outsider.
The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability.

In the current model, attackers are actively looking at all commits as potential vulnerabilities, regardless of what anybody says or doesn’t say about them.

You can’t make the commits not exist, or not be visible, because that’s a core part of how the kernel is developed and released.

So anything you do with notifications to distro maintainers about the vuln, or the existence of a vuln, or a nudge to patch with no context, or whatever, is totally irrelevant and does not change the calculus: the moment the fix is committed, bad actors who were not already aware notice it.

This is, of course, to say nothing of bad actors who had already found the vulnerability on their own.