Hacker News Reader

Comment by perihelions | Hacker News Reader

Debian-stable users, once again, remain unaffected by $currentDumpsterFire.

(Experts: how do you weigh the risks of the two choices against each other? Running bleeding-edge upgrades brings in these fresh security holes before anyone's noticed them. But, running "stable" software can mean running vulnerable software that upstream has already patched. Not every vulnerability is recognized as a vulnerability, and patched as a security update; many "ordinary" bugs have security consequences which aren't obvious to recognize. Which choice is less worse?)

View on HN

Packages in "stable" versions get bugfixes, too. How often obviously depends on the maintainer, but anything marked as a security issue upstream tends to be patched fairly quickly.

On the whole, I would assume that someone who maintains a Debian or RHEL package is better qualified to assess the severity of a bug than I am. The bigger problem is that xz hasn't had a proper maintainer for the better part of a decade.

An example that worried me was this Linux kernel bug [0], which in hindsight turned out to be a severe vulnerability, but didn't get a Debian-stable security update for three months. The vulnerability aspect wasn't obvious in the initial reports.

Is this common? Is it more common in software that has lower profile than the Linux kernel—software with fewer maintainers and fewer eyeballs, and fewer security-focused people flagging the right issues in the right ways to downstream?

[0] https://news.ycombinator.com/item?id=28926426

If everyone is running LTS, then discovery just runs to LTS.

the reason $currentDumpsterFire is identified is only because it's being used. Cannon fodder exists for a purpose.

Debian's development model actually seems to hit a sweet spot between "everyone runs LTS" and "everyone is cannon fodder".

Stable is LTS, sid is cutting edge, and testing is somewhere in between. You can choose the level of stability you want, and even move from one to the other, all without leaving the umbrella of Debian.

This implies that testing is "more stable" than sid, which is often not the case, if what you care about is breaking changes. Broken packages in sid tend to be updated fairly quickly, whereas breakage in testing often stays broken for quite some time until the fix is promoted.

Depends on what you mean by "stable". A distro with known-broken packages can be "stable" in a sense that its brokenness is reproducible with every new container you spin up, and therefore can be reliably worked around. I've had this happen with minor packages in known-stable distros like CentOS and Ubuntu LTS, too.

slackware (both stable and -current) is unaffected too, as it doesn't patch ssh to link to systemd (that dependens on lzma).

Well, it doesn't ship systemd whatsoever, but that's a plus to me.

Not really, malicious actor committed to xz project for 2 years, over 700 commits, there could be security issues in stable xz as well.

Exactly. Per discussion in the link, the safe versions are 5.2.x and earlier. So, Debian 11 (oldstable) is not affected as it runs 5.2.5, but Debian 12 (stable) could have some other backdoor from the same author.

Reply on news.ycombinator.com