3 ms·

> Yes, it kind of sucks that I have 3 copies of Chrome (Electron) and 7 copies of Qt on my Windows system, but that sure works a hell of a lot better than tryin

> Yes, it kind of sucks that I have 3 copies of Chrome (Electron) and 7 copies of Qt on my Windows system, but that sure works a hell of a lot better than trying to synchronise the dependencies of a dozen applications. Does it? Even if 2 of those chromiums and all of the QTs have actively exploited vulnerabilities and it's anyone's guess if/when the application authors might bother updating?

Xylakant 2y ago
A common downside is that the distribution picks the lowest common denominator of some dependency and all apps that require a newer version are held behind. That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. Depending on the package maintainer, results may vary. (We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation.) This is clearly a tradeoff with no easy win for either side.
- vbezhenar 2y ago
  Another downside might be that developer just does not test his software with OS-supplied library versions. So it can cause all the kinds of bugs. There's a reason why containers won in server-side development.
  - yjftsjthsd-h 2y ago
    That's why distros (at least of the kind that Debian is) aim to do everything themselves; they mirror upstream code ( https://sources.debian.org/ https://sources.debian.org/ ), they write their own packaging scripts, they test the whole thing together, and then they handle problems in-house ( https://www.debian.org/Bugs/Reporting https://www.debian.org/Bugs/Reporting ). The upstream developer shouldn't need to have done any of this themselves.
- Arnavion 2y ago
  That is a problem for LTS distributions. Rolling distributions do not have this problem.
  - yjftsjthsd-h 2y ago
    I don't think that's true? If packages foo and bar both need libbaz, and foo always uses the latest version of libbaz but bar doesn't, you're going to have a conflict no matter whether you're rolling or not. If anything, a slow-moving release-based distro could have an easier time if they can fudge versions to get an older version of foo that overlaps dependencies with bar.
    - Arnavion 2y ago
      When the situation you describe happens, the easiest thing for the distro to do is to make the two versions of libbaz coinstallable via different package names, different sonames, etc. This is how every distro, LTS or rolling, handled openssl 1.0 vs 1.1 vs 3 for example. Regardless, the original point was: >>That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. ... and my response that this is only a problem for LTS distros stands. A rolling release distro will not get in the business of maintaining packages after upstream dropped support. It is only done by LTS distros, because the whole point of LTS distros is that their packages must be kept maintained and usable for N years even as upstreams lose interest and the world perishes in nuclear fire and zombies walk the Earth feasting on the brains of anyone still using outdated software. --- Now, to play devil's advocate, here's an OpenSUSE TW (rolling distro) bug that I helped investigate: https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 . The tl;dr is that: - Chromium upstream vendors all its dependencies, but OpenSUSE forces it to compile against distribution packages. - Chromium version X compiles against vendored library version A. OpenSUSE updates its Chromium package to version X and also has library version A in its repos, so the Chromium compiled against distro library works fine. - Chromium upstream updates the vendored library to version B, and makes that change as part of Chromium version Y. OpenSUSE hasn't updated yet. - OpenSUSE updates the library package to version B. Chromium version X's package is automatically rebuilt against the new library, and it compiles fine because the API is the same. - Disaster! The semantics of the library did change between versions A and B even though the API didn't, so OpenSUSE's Chromium now segfaults due to nullptr deref. Chromium version Y contains Chromium changes to account for this difference, but the OpenSUSE build of Chromium X of course doesn't have them. You will note that this is caused by a distro compiling a package against a newer version of a dependency than upstream tested it against, not an older one, but you are otherwise welcome to draw parallels from it. In this case it was fixed by backporting the Chromium version Y change to work with library version B, and eventually the Chromium package was updated to version Y and the patch was dropped. In a hypothetical scenario where Chromium could not be updated nor patched (say the patch was too risky), it could have worked for the distro to make the library coinstallable and then have Chromium use library version A while everything else uses version B.
- yjftsjthsd-h 2y ago
  > We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation. Could you remind those of us who don't remember that? The big one I know about is CVE-2008-0166, but that was 1. not a backport, and 2. was run by upstream before they shipped it. But yes, agreed that it's painful either way; I think it comes down to that someone has to do the legwork, and who exactly does it has trade-offs either way.
  - lmm 2y ago
    It wasn't run by upstream. It was run by the wrong mailing list, and only for one half of the Debian changes.
  - Xylakant 2y ago
    You’re correct. It wasn’t a backport, it was an attempt to fix a perceived issue that upstream had not fixed - a read of uninitialized memory. What the maintainer did not understand was that the call was deliberate. With this and subsequent changes, they broke the randomness in the key generation.
    - LtWorf 2y ago
      Good thing openssl is so good it hasn't had any CVE at all in all the years since that happened right?
      - Xylakant 2y ago
        So we’re introducing new bugs to add a little extra spice? Not trying to defend the code quality of OpenSSL, but the fallout of this bug affected everything and everyone and bad keys are still found 16 years later as of 2024.[1] And it was completely and utterly unnecessary - reporting the issue to upstream and fixing it upstream would have prevented the entire disaster. [1]https://16years.secvuln.info/ https://16years.secvuln.info/
        LtWorf 2y ago
        Yeah and now they know (like everyone else already knew) that uninitialised memory is a bad idea :D
vlovich123 2y ago
MacOS and Windows both seem to do quite well actually on this front. You should have OS-level defense mechanisms rather than trying to keep every single application secure. For example, qBitTorrent didn’t verify HTTPS certs for something like a decade. It’s really difficult to keep everything patched when it’s your full time job. When it’s arbitrary users with a mix of technical abilities and understandings of the issue it’s a much worse problem.
- yjftsjthsd-h 2y ago
  Isn't that an argument that macOS/Windows aren't doing so well? On Debian, I can run `apt upgrade` and patch every single program. On Windows, I have to have a bunch of updater background processes and that still doesn't cover everything.
  - vlovich123 2y ago
    If you think that that gets you the latest patches to all possible software you may have installed, you may want to avoid people offering to sell you bridges. It’s an illusion - you’re relying on the best effort of volunteers “maintaining” an insane amount of software packages (both from bugs and security and often ignoring upstream or even having upstream treat them as outsourced support). I would point you to qBitTorrent having a 10 year bug where they didn’t verify SSL certs as an example of the kinds of bugs that you need broader in depth security mechanisms to keep you safe.
- LtWorf 2y ago
  Possibly the not trying to keep applications secure explains why those systems get hacked all the time?
  - vlovich123 2y ago
    Far more reasonable explanation is that the addressable market for Windows and iOS is much larger and more lucrative - iOS exploits go for six figures whereas Linux exploits don’t generally go for as much. And exploits for Chrome and Safari go for a lot for similar reasons. No piece of software is likely to really be safe from a super determined and well funded adversary, and that’s why you need ways of structuring things (eg VMs, containers, peer ssl etc) to make things safer. If Linux had anywhere near the market share of those OSes you would see much more publicly the problems of how Debian and other distros choose to maintain those OSes.
woodruffw 2y ago
The problem here is ultimately visibility and actionability: half a dozen binaries with known vulnerabilities isn't much better than a single distribution one, if the distribution isn't (or can't) provide security updates. Or, as another framing: everything about user-side packaging cuts both ways: it's both a source of new dependency and vulnerability tracking woes, and it's a significant accelerant to the process of getting patched versions into place. Good and bad.

Xylakant 2y ago

A common downside is that the distribution picks the lowest common denominator of some dependency and all apps that require a newer version are held behind. That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. Depending on the package maintainer, results may vary. (We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation.) This is clearly a tradeoff with no easy win for either side.

vbezhenar 2y ago
Another downside might be that developer just does not test his software with OS-supplied library versions. So it can cause all the kinds of bugs. There's a reason why containers won in server-side development.
- yjftsjthsd-h 2y ago
  That's why distros (at least of the kind that Debian is) aim to do everything themselves; they mirror upstream code ( https://sources.debian.org/ https://sources.debian.org/ ), they write their own packaging scripts, they test the whole thing together, and then they handle problems in-house ( https://www.debian.org/Bugs/Reporting https://www.debian.org/Bugs/Reporting ). The upstream developer shouldn't need to have done any of this themselves.
Arnavion 2y ago
That is a problem for LTS distributions. Rolling distributions do not have this problem.
- yjftsjthsd-h 2y ago
  I don't think that's true? If packages foo and bar both need libbaz, and foo always uses the latest version of libbaz but bar doesn't, you're going to have a conflict no matter whether you're rolling or not. If anything, a slow-moving release-based distro could have an easier time if they can fudge versions to get an older version of foo that overlaps dependencies with bar.
  - Arnavion 2y ago
    When the situation you describe happens, the easiest thing for the distro to do is to make the two versions of libbaz coinstallable via different package names, different sonames, etc. This is how every distro, LTS or rolling, handled openssl 1.0 vs 1.1 vs 3 for example. Regardless, the original point was: >>That version may well be out of support and not receive fixes at all any more, which leaves the burden of maintenance on the distribution. ... and my response that this is only a problem for LTS distros stands. A rolling release distro will not get in the business of maintaining packages after upstream dropped support. It is only done by LTS distros, because the whole point of LTS distros is that their packages must be kept maintained and usable for N years even as upstreams lose interest and the world perishes in nuclear fire and zombies walk the Earth feasting on the brains of anyone still using outdated software. --- Now, to play devil's advocate, here's an OpenSUSE TW (rolling distro) bug that I helped investigate: https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 https://bugzilla.opensuse.org/show_bug.cgi?id=1214003 . The tl;dr is that: - Chromium upstream vendors all its dependencies, but OpenSUSE forces it to compile against distribution packages. - Chromium version X compiles against vendored library version A. OpenSUSE updates its Chromium package to version X and also has library version A in its repos, so the Chromium compiled against distro library works fine. - Chromium upstream updates the vendored library to version B, and makes that change as part of Chromium version Y. OpenSUSE hasn't updated yet. - OpenSUSE updates the library package to version B. Chromium version X's package is automatically rebuilt against the new library, and it compiles fine because the API is the same. - Disaster! The semantics of the library did change between versions A and B even though the API didn't, so OpenSUSE's Chromium now segfaults due to nullptr deref. Chromium version Y contains Chromium changes to account for this difference, but the OpenSUSE build of Chromium X of course doesn't have them. You will note that this is caused by a distro compiling a package against a newer version of a dependency than upstream tested it against, not an older one, but you are otherwise welcome to draw parallels from it. In this case it was fixed by backporting the Chromium version Y change to work with library version B, and eventually the Chromium package was updated to version Y and the patch was dropped. In a hypothetical scenario where Chromium could not be updated nor patched (say the patch was too risky), it could have worked for the distro to make the library coinstallable and then have Chromium use library version A while everything else uses version B.
yjftsjthsd-h 2y ago
> We sysadmins still remember debians effort to backport a fix to OpenSSL and breaking key generation. Could you remind those of us who don't remember that? The big one I know about is CVE-2008-0166, but that was 1. not a backport, and 2. was run by upstream before they shipped it. But yes, agreed that it's painful either way; I think it comes down to that someone has to do the legwork, and who exactly does it has trade-offs either way.
- lmm 2y ago
  It wasn't run by upstream. It was run by the wrong mailing list, and only for one half of the Debian changes.
- Xylakant 2y ago
  You’re correct. It wasn’t a backport, it was an attempt to fix a perceived issue that upstream had not fixed - a read of uninitialized memory. What the maintainer did not understand was that the call was deliberate. With this and subsequent changes, they broke the randomness in the key generation.
  - LtWorf 2y ago
    Good thing openssl is so good it hasn't had any CVE at all in all the years since that happened right?
    - Xylakant 2y ago
      So we’re introducing new bugs to add a little extra spice? Not trying to defend the code quality of OpenSSL, but the fallout of this bug affected everything and everyone and bad keys are still found 16 years later as of 2024.[1] And it was completely and utterly unnecessary - reporting the issue to upstream and fixing it upstream would have prevented the entire disaster. [1]https://16years.secvuln.info/ https://16years.secvuln.info/
      - LtWorf 2y ago
        Yeah and now they know (like everyone else already knew) that uninitialised memory is a bad idea :D

vlovich123 2y ago

MacOS and Windows both seem to do quite well actually on this front. You should have OS-level defense mechanisms rather than trying to keep every single application secure. For example, qBitTorrent didn’t verify HTTPS certs for something like a decade. It’s really difficult to keep everything patched when it’s your full time job. When it’s arbitrary users with a mix of technical abilities and understandings of the issue it’s a much worse problem.

yjftsjthsd-h 2y ago
Isn't that an argument that macOS/Windows aren't doing so well? On Debian, I can run `apt upgrade` and patch every single program. On Windows, I have to have a bunch of updater background processes and that still doesn't cover everything.
- vlovich123 2y ago
  If you think that that gets you the latest patches to all possible software you may have installed, you may want to avoid people offering to sell you bridges. It’s an illusion - you’re relying on the best effort of volunteers “maintaining” an insane amount of software packages (both from bugs and security and often ignoring upstream or even having upstream treat them as outsourced support). I would point you to qBitTorrent having a 10 year bug where they didn’t verify SSL certs as an example of the kinds of bugs that you need broader in depth security mechanisms to keep you safe.
LtWorf 2y ago
Possibly the not trying to keep applications secure explains why those systems get hacked all the time?
- vlovich123 2y ago
  Far more reasonable explanation is that the addressable market for Windows and iOS is much larger and more lucrative - iOS exploits go for six figures whereas Linux exploits don’t generally go for as much. And exploits for Chrome and Safari go for a lot for similar reasons. No piece of software is likely to really be safe from a super determined and well funded adversary, and that’s why you need ways of structuring things (eg VMs, containers, peer ssl etc) to make things safer. If Linux had anywhere near the market share of those OSes you would see much more publicly the problems of how Debian and other distros choose to maintain those OSes.

woodruffw 2y ago

The problem here is ultimately visibility and actionability: half a dozen binaries with known vulnerabilities isn't much better than a single distribution one, if the distribution isn't (or can't) provide security updates. Or, as another framing: everything about user-side packaging cuts both ways: it's both a source of new dependency and vulnerability tracking woes, and it's a significant accelerant to the process of getting patched versions into place. Good and bad.