3 ms·

It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use th

by zrm 7y ago

It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Doing that isn't much if any of a reduction in workload compared with getting every application to use the version the distribution ships, and is much more likely to end up with a situation where dozens of versions of the same library exist and half of them are broken in some way. The better solution is for libraries to only break compatibility between major versions. Then the packager can ship some suitably recent minor version for each major version of the library, at most two or three major versions are supported at any given time which keeps the maintenance overhead feasible, and every application can successfully link against one of those major versions or another.

avar 7y ago
It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It just means when users upgrade they can do so gradually for some sets of packages at a time. You can emulate this on traditional distributions by having a single VM image you use for your browser, then cloning the image, updating packages, and using that one for your E-Mail etc. Having a mechanism like this should mean less support is needed from the distribution, because system-wide breakages are less likely to occur. You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. In Debian testing this sort of thing happens occasionally and will get fixed sooner than later, but that it happens at all is just an emergent property of how the versions are managed. If I were to run the latest firefox with those new versions and not touch the other packages until they're recompiled both myself and the package maintainers would be exposed to fewer bugs, not less. I'd get a bugfixed firefox today, and they wouldn't need to deal with bug reports about a broken upgrade, or firefox bugs in an older version users like me can't upgrade past simply because firefox happens to share the use of a popular OS library.
- zrm 7y ago
  > Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. > You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. You'll get the same bugs and then the 5% of packages a security update breaks are broken until they're fixed, which should happen promptly because broken packages should be very high priority. Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? The real solution is for sufficient testing to be done during the embargo period so that by the time the new version goes wide it doesn't actually break anything. > For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. Right, that's a problem. It's valid to need version >= 5.6 of some library, but something has gone wrong if some other package specifically needs version 5.5 -- version 5.6 should be able to satisfy that dependency. Or if it can't then "5.6" should be 6.0 and it should be possible to have 5.x and 6.x installed together, but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once. In general the latest version should be able to satisfy applications expecting older versions and then you need only a suitably recent version and nothing else, and the lack of that is the real issue.
  - avar 7y ago
    > It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. Yes I agree that would be a royal pain in the ass, i.e. running something like a Debian where each package would be the equivalent of a docker image with an individual maintainer who'd need to decide when they upgrade OpenSSL. I'm saying you could have something like a Debian where the build infrastructure and package maintenance works exactly the same, your package is always built against the latest library versions. But users get a NixOS-like experience where they can partially update their system, now with traditional OS package management an update of a common library & a full system-update are often in practice the same thing. > Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? On the flip side is it really better that if you're using the other 95% of applications that your security fix is delayed because upstream is finding it a pain to rebuild the patched package for 5% of its users? That's realistically the alternative. > [...]but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once[...] The sum of differing versions in use among a distro's userbase is vastly larger than that, some of those users are deferring security updates because their distro makes upgrading an all-or-nothing experience.
jcelerier 7y ago
> If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. It does not matter to the users of my software that I use libraries versions X, Y, Z, what matters is that what they want to happen happens when they click the buttons. e.g. I generally use Qt - there are plenty of bugs, but what matters is that my use cases work, and it is my onus of developer to ensure it. And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested.
- zrm 7y ago
  > Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. Not exactly. For the system libraries (e.g. the Windows crypto API) you effectively get one version for the whole system, and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. Whereas for applications that include their own copy of e.g. OpenSSL, that problem does occur there. When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely. > And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested. You don't have to ensure it works with every version ever made, only the one the distribution ships. This is made much easier if the library developer designates specific versions as stable and then stable distributions use those versions, because then working against the two or three actively maintained stable versions is all you need to work anywhere.
  - jcelerier 7y ago
    > and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. yet people have to ship microsoft DLLs left and right since behaviour sometimes still break. One breakage is enough to convince stakeholders to do that. > When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely. On the other hand, I had software who broke, as in, core features became unoperational due to openssl distro updates and changes of default policies. My users much prefer having working potentially unsafe software in the exceptional case where the software would connect to the network (eg reading a youtube stream in VLC or something like that) that non-working software. > You don't have to ensure it works with every version ever made, only the one the distribution ships. Which is "every version ever made" because people are still rocking Debian Wheezy or Ubuntu 12.04 and want to use my software

by zrm 7y ago

avar 7y ago

It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It just means when users upgrade they can do so gradually for some sets of packages at a time. You can emulate this on traditional distributions by having a single VM image you use for your browser, then cloning the image, updating packages, and using that one for your E-Mail etc. Having a mechanism like this should mean less support is needed from the distribution, because system-wide breakages are less likely to occur. You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. In Debian testing this sort of thing happens occasionally and will get fixed sooner than later, but that it happens at all is just an emergent property of how the versions are managed. If I were to run the latest firefox with those new versions and not touch the other packages until they're recompiled both myself and the package maintainers would be exposed to fewer bugs, not less. I'd get a bugfixed firefox today, and they wouldn't need to deal with bug reports about a broken upgrade, or firefox bugs in an older version users like me can't upgrade past simply because firefox happens to share the use of a popular OS library.

zrm 7y ago
> Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. > You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. You'll get the same bugs and then the 5% of packages a security update breaks are broken until they're fixed, which should happen promptly because broken packages should be very high priority. Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? The real solution is for sufficient testing to be done during the embargo period so that by the time the new version goes wide it doesn't actually break anything. > For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. Right, that's a problem. It's valid to need version >= 5.6 of some library, but something has gone wrong if some other package specifically needs version 5.5 -- version 5.6 should be able to satisfy that dependency. Or if it can't then "5.6" should be 6.0 and it should be possible to have 5.x and 6.x installed together, but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once. In general the latest version should be able to satisfy applications expecting older versions and then you need only a suitably recent version and nothing else, and the lack of that is the real issue.
- avar 7y ago
  > It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. Yes I agree that would be a royal pain in the ass, i.e. running something like a Debian where each package would be the equivalent of a docker image with an individual maintainer who'd need to decide when they upgrade OpenSSL. I'm saying you could have something like a Debian where the build infrastructure and package maintenance works exactly the same, your package is always built against the latest library versions. But users get a NixOS-like experience where they can partially update their system, now with traditional OS package management an update of a common library & a full system-update are often in practice the same thing. > Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? On the flip side is it really better that if you're using the other 95% of applications that your security fix is delayed because upstream is finding it a pain to rebuild the patched package for 5% of its users? That's realistically the alternative. > [...]but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once[...] The sum of differing versions in use among a distro's userbase is vastly larger than that, some of those users are deferring security updates because their distro makes upgrading an all-or-nothing experience.

jcelerier 7y ago

> If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. It does not matter to the users of my software that I use libraries versions X, Y, Z, what matters is that what they want to happen happens when they click the buttons. e.g. I generally use Qt - there are plenty of bugs, but what matters is that my use cases work, and it is my onus of developer to ensure it. And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested.

zrm 7y ago
> Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. Not exactly. For the system libraries (e.g. the Windows crypto API) you effectively get one version for the whole system, and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. Whereas for applications that include their own copy of e.g. OpenSSL, that problem does occur there. When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely. > And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested. You don't have to ensure it works with every version ever made, only the one the distribution ships. This is made much easier if the library developer designates specific versions as stable and then stable distributions use those versions, because then working against the two or three actively maintained stable versions is all you need to work anywhere.
- jcelerier 7y ago
  > and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. yet people have to ship microsoft DLLs left and right since behaviour sometimes still break. One breakage is enough to convince stakeholders to do that. > When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely. On the other hand, I had software who broke, as in, core features became unoperational due to openssl distro updates and changes of default policies. My users much prefer having working potentially unsafe software in the exceptional case where the software would connect to the network (eg reading a youtube stream in VLC or something like that) that non-working software. > You don't have to ensure it works with every version ever made, only the one the distribution ships. Which is "every version ever made" because people are still rocking Debian Wheezy or Ubuntu 12.04 and want to use my software