4 ms·

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. Tha

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

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