9 ms·

The first section, on security fixes ("[...] you only need to update a shared library to apply security fixes to all executables that rely on that library"), st

by cesarb 5y ago

The first section, on security fixes ("[...] you only need to update a shared library to apply security fixes to all executables that rely on that library"), starts talking about security fixes but then suddenly switches to talking about ABI and API breaks. But that sleight-of-hand hides the fact that many (perhaps even most) security fixes do not break the ABI or API; they are completely contained to the implementation (one obvious exception would be if the security issue was caused by bad API design, but even then often there are ways to fix it without breaking the ABI).

rewma 5y ago
> But that sleight-of-hand hides the fact that many (perhaps even most) security fixes do not break the ABI or API; they are completely contained to the implementation (one obvious exception would be if the security issue was caused by bad API design, but even then often there are ways to fix it without breaking the ABI). Right you are. I was also perplexed when I read that non sequitur. The author's reference to DLL Hell also suggests there's some confusion in his analysis of the underlying problem, given that DLL Hell is very specific to windows and at best is only orthogonally related to ABI. The author's references to API changes make even less sense, and definitely cast doubt over his insight into the issue.
- pjmlp 5y ago
  And was kind of fixed with application manifests, on XP.
- salawat 5y ago
  Differentiating DLL and SO hell is getting a bit beyond pedantic as they are implementations of the same fundamental abstraction. Any substantial difference in merely one of implementation details.
  - rewma 5y ago
    > Differentiating DLL and SO hell is getting a bit beyond pedantic (...) It really isn't. Unlike linking problems, where the problem is focused on how you need to fight your dependencies to be able to resolve symbols, DLL Hell has been for over a decade a dependency resolution problem that is solved at the packaging level. More importantly, on Windows, where sharing DLLs is not a thing, you can simply drop a DLL in the app dir and be done with it. In fact, it's customary for windows apps to just bundle all their dependencies.
ghoward 5y ago
Author here. Sure, most security fixes do not break the ABI or API. But it only takes one, and then you have a security issue. So I can understand your sentiment that it was sleight-of-hand, but I argue that it's not. Also, we only think that most security updates don't break API or ABI because we have no automatic way of checking. It's all thoughts and prayers. I'm a religious person, but thoughts and prayers are not a good way to do computer security.
- zozbot234 5y ago
  If a security fix must break the API, you can bump up the SONAME which forces all packages depending on your shared library to recompile against the new version. This is comparable to the requirements under static linking, but you only have to do it when absolutely needed.
- throw0101a 5y ago
  > Sure, most security fixes do not break the ABI or API. But it only takes one, and then you have a security issue. As someone who has been a Unix sysadmin for almost twenty years now, I don't recall every installing a patch or package update that broke the ABI/API. If one should happen to occur next week, I'll still go with leaning towards linked libraries, as their convenience out-weights (has out-weighted) the once-in-twenty-years occurrence of breakage. > It's all thoughts and prayers. I'm a religious person, but thoughts and prayers are not a good way to do computer security. Ditto. But "faith" and "trust" are (almost) synonyms. And I trust the updaters of libraries to be able to get out a security update in short order more than I trust the possibility of all the package maintainers that link to it to be able to coördinate a quick update. When OpenSSL's Heartbleed occurred it was one package update and restarting of a bunch of processes (helped by the checkrestart utility in the debian-goodies package). That's a lot quicker than updating a bazillion dependents.
  - xgbi 5y ago
    Not related to the OP but I’ve had many issues with non standard vendors placing breaking changes in their patch/minor releases. You think you’re updating to a relatively normal version and it actually breaks your entire production. I’m looking at you, MySQL, docker, Mongodb, or harbor. I’m not complaining, those are provided free of charge and we are happy when it works, but semver is really all that matters in this: either you adhere and it’s smooth sailing, or you don’t and then please don’t use semver-looking numbering.

by cesarb 5y ago

rewma 5y ago

> But that sleight-of-hand hides the fact that many (perhaps even most) security fixes do not break the ABI or API; they are completely contained to the implementation (one obvious exception would be if the security issue was caused by bad API design, but even then often there are ways to fix it without breaking the ABI). Right you are. I was also perplexed when I read that non sequitur. The author's reference to DLL Hell also suggests there's some confusion in his analysis of the underlying problem, given that DLL Hell is very specific to windows and at best is only orthogonally related to ABI. The author's references to API changes make even less sense, and definitely cast doubt over his insight into the issue.

pjmlp 5y ago
And was kind of fixed with application manifests, on XP.
salawat 5y ago
Differentiating DLL and SO hell is getting a bit beyond pedantic as they are implementations of the same fundamental abstraction. Any substantial difference in merely one of implementation details.
- rewma 5y ago
  > Differentiating DLL and SO hell is getting a bit beyond pedantic (...) It really isn't. Unlike linking problems, where the problem is focused on how you need to fight your dependencies to be able to resolve symbols, DLL Hell has been for over a decade a dependency resolution problem that is solved at the packaging level. More importantly, on Windows, where sharing DLLs is not a thing, you can simply drop a DLL in the app dir and be done with it. In fact, it's customary for windows apps to just bundle all their dependencies.

ghoward 5y ago

Author here. Sure, most security fixes do not break the ABI or API. But it only takes one, and then you have a security issue. So I can understand your sentiment that it was sleight-of-hand, but I argue that it's not. Also, we only think that most security updates don't break API or ABI because we have no automatic way of checking. It's all thoughts and prayers. I'm a religious person, but thoughts and prayers are not a good way to do computer security.

zozbot234 5y ago
If a security fix must break the API, you can bump up the SONAME which forces all packages depending on your shared library to recompile against the new version. This is comparable to the requirements under static linking, but you only have to do it when absolutely needed.
throw0101a 5y ago
> Sure, most security fixes do not break the ABI or API. But it only takes one, and then you have a security issue. As someone who has been a Unix sysadmin for almost twenty years now, I don't recall every installing a patch or package update that broke the ABI/API. If one should happen to occur next week, I'll still go with leaning towards linked libraries, as their convenience out-weights (has out-weighted) the once-in-twenty-years occurrence of breakage. > It's all thoughts and prayers. I'm a religious person, but thoughts and prayers are not a good way to do computer security. Ditto. But "faith" and "trust" are (almost) synonyms. And I trust the updaters of libraries to be able to get out a security update in short order more than I trust the possibility of all the package maintainers that link to it to be able to coördinate a quick update. When OpenSSL's Heartbleed occurred it was one package update and restarting of a bunch of processes (helped by the checkrestart utility in the debian-goodies package). That's a lot quicker than updating a bazillion dependents.
- xgbi 5y ago
  Not related to the OP but I’ve had many issues with non standard vendors placing breaking changes in their patch/minor releases. You think you’re updating to a relatively normal version and it actually breaks your entire production. I’m looking at you, MySQL, docker, Mongodb, or harbor. I’m not complaining, those are provided free of charge and we are happy when it works, but semver is really all that matters in this: either you adhere and it’s smooth sailing, or you don’t and then please don’t use semver-looking numbering.