4 ms·

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 sentim

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.
  - dralley 5y ago
    There's a difference between vendor provided packages and distro provided packages. Distros pay a lot more attention to breaking changes.
    - deleted 5y ago
      [deleted]
- ghoward 5y ago
  I understand where you are coming from. That's actually why I gave my ideas to get the best from both types of linking.
deleted 5y ago
[deleted]
taviso 5y ago
I've (probably?) found more linker vulnerabilities than anyone else, but don't really understand your argument. I definitely understand library search path vulnerabilities (I've literally found bugs in $ORIGIN parsing, e.g. CVE-2010-3847 was one of mine!). We think security updates don't break API/ABI because they're backported to all previous major versions that are still actively supported. This isn't "thoughts and prayers", it's work that the packagers and maintainers do. I can't tell you how useful being able to fix a vulnerability in every program is, just think of updating every application that uses libpng on your desktop, or every server application that uses OpenSSL. I just can't imagine wanting to give that up, because of name mangling ABI issues!
- gnufx 5y ago
  I hope that puts it to rest; I can hope. Unfortunately, my experience is that people who haven't fixed multiple security problems, and probably have never heard of taviso, know a lot more about security than people who have...
  - ghoward 5y ago
    I have heard of taviso. That doesn't mean I can't disagree with him.
    - gnufx 5y ago
      Sorry, I was talking generally. I try to avoid being personal in posts.
froh 5y ago
That's why you run a trusted Linux distro in production, like sles or rhel or ubuntu, their core value proposition is _exactly_ this: Provide binary compatible drop in replacement security updates for shared objects over the lifetime of the platform. They even maintain kernel internal abi compatibility for the released and maintained product, so your exotic-hardware.ko module doesn't need to be updated. Also there is mature tooling around ABI compliance checking: https://lvc.github.io/abi-compliance-checker/ https://lvc.github.io/abi-compliance-checker/ This is used to document the ABI stability of mature projects like so: https://abi-laboratory.pro/index.php?view=tracker https://abi-laboratory.pro/index.php?view=tracker E: re thoughts and prayers, the mature Linux distro all run extensive revalidation for their security updates. Breaking customer binary applications with a security update is the absolute worst case scenario. For yocto or similar cost free projects, or Linux distros that are source, not binary, that may be a different story. But for sles, rhel, ubuntu it's not thoughts and prayers but a maintenance verification and release process on their side and a monthly bill on yours.
gnufx 5y ago
> we have no automatic way of checking I do for Fedora packages I maintain. There can be false positives, like on symbols that shouldn't be exported, but you can look at the API to start with. (The library author should do that, of course.)

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.
- dralley 5y ago
  There's a difference between vendor provided packages and distro provided packages. Distros pay a lot more attention to breaking changes.
  - deleted 5y ago
    [deleted]
ghoward 5y ago
I understand where you are coming from. That's actually why I gave my ideas to get the best from both types of linking.

deleted 5y ago

[deleted]

taviso 5y ago

I've (probably?) found more linker vulnerabilities than anyone else, but don't really understand your argument. I definitely understand library search path vulnerabilities (I've literally found bugs in $ORIGIN parsing, e.g. CVE-2010-3847 was one of mine!). We think security updates don't break API/ABI because they're backported to all previous major versions that are still actively supported. This isn't "thoughts and prayers", it's work that the packagers and maintainers do. I can't tell you how useful being able to fix a vulnerability in every program is, just think of updating every application that uses libpng on your desktop, or every server application that uses OpenSSL. I just can't imagine wanting to give that up, because of name mangling ABI issues!

gnufx 5y ago
I hope that puts it to rest; I can hope. Unfortunately, my experience is that people who haven't fixed multiple security problems, and probably have never heard of taviso, know a lot more about security than people who have...
- ghoward 5y ago
  I have heard of taviso. That doesn't mean I can't disagree with him.
  - gnufx 5y ago
    Sorry, I was talking generally. I try to avoid being personal in posts.

froh 5y ago

That's why you run a trusted Linux distro in production, like sles or rhel or ubuntu, their core value proposition is _exactly_ this: Provide binary compatible drop in replacement security updates for shared objects over the lifetime of the platform. They even maintain kernel internal abi compatibility for the released and maintained product, so your exotic-hardware.ko module doesn't need to be updated. Also there is mature tooling around ABI compliance checking: https://lvc.github.io/abi-compliance-checker/ https://lvc.github.io/abi-compliance-checker/ This is used to document the ABI stability of mature projects like so: https://abi-laboratory.pro/index.php?view=tracker https://abi-laboratory.pro/index.php?view=tracker E: re thoughts and prayers, the mature Linux distro all run extensive revalidation for their security updates. Breaking customer binary applications with a security update is the absolute worst case scenario. For yocto or similar cost free projects, or Linux distros that are source, not binary, that may be a different story. But for sles, rhel, ubuntu it's not thoughts and prayers but a maintenance verification and release process on their side and a monthly bill on yours.

gnufx 5y ago

> we have no automatic way of checking I do for Fedora packages I maintain. There can be false positives, like on symbols that shouldn't be exported, but you can look at the API to start with. (The library author should do that, of course.)