3 ms·

Debian-stable users, once again, remain unaffected by $currentDumpsterFire. (Experts: how do you weigh the risks of the two choices against each other? Running

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?)

kijin 3y ago
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.
- perihelions 3y ago
  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 https://news.ycombinator.com/item?id=28926426
cyanydeez 3y ago
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.
- kijin 3y ago
  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.
  - LeoPanthera 3y ago
    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.
    - kijin 3y ago
      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.
_ZeD_ 3y ago
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.
wooque 3y ago
Not really, malicious actor committed to xz project for 2 years, over 700 commits, there could be security issues in stable xz as well.
- babuskov 3y ago
  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.

kijin 3y ago

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.

perihelions 3y ago
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 https://news.ycombinator.com/item?id=28926426

cyanydeez 3y ago

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.

kijin 3y ago
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.
- LeoPanthera 3y ago
  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.
  - kijin 3y ago
    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.

_ZeD_ 3y ago

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.

wooque 3y ago

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

babuskov 3y ago
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.