3 ms·

> Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations

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

by zrm 7y ago

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.