4 ms·

I think the whole security thing of relying on dynamic linking is a red herring. It is neither necessary nor sufficient. It will miss private dynamic libraries

I think the whole security thing of relying on dynamic linking is a red herring. It is neither necessary nor sufficient. It will miss private dynamic libraries, Docker containers, potentially virtual envs. And it has a huge cost in terms of maintenance and backwards compatibility. In a world where we have regular builds from source, this model really doesn't have a place.

notacoward 3y ago
> It will miss private dynamic libraries, Docker containers, potentially virtual envs. Yes, it will. Does that make dynamic libraries a red herring, or does it mean these approaches all make the same mistake? Please think before you answer. Just because something's common doesn't mean it's wise or necessary. > it has a huge cost in terms of maintenance and backwards compatibility How much are those "huge costs" unique to that approach? Maintenance and backwards compatibility are still problems even with static linking or embedding into containers or any other alternative. It's disingenuous to count common problems against only one approach. The real tradeoff is between problems that are unique to each, and it's possible to disagree about which choice is best without stacking the deck for one side.
- nicoburns 3y ago
  Ultimately if the app is unmaintained, then it's likely to have security issues even if it's using dynamic libraries. If it is maintained then it shouldn't be a big deal to update it.
  - deleted 3y ago
    [deleted]
  - layer8 3y ago
    Security is not black and white. Better to be able to fix some security issues of an unmaintained app than none. This is a bit of a tangent, but I don’t think it is sustainable in the long run to require the ever-growing volume of software in use to all be actively maintained. We should find a model of software development where we can achieve sufficient security without having to maintain and rebuild the world all the time.
    - nicoburns 3y ago
      Long term I think we'll get most of the way there by eliminating C and C++ from our software stacks. Most security vulnerabilities (and even more of the most serious ones) are memory safety or UB related. And systematically eliminating those will give us more time to audit our code for other issues. Eliminating C and C++ also likely leads us to standardised build systems which makes rebuilding things much much easier.
JohnFen 3y ago
I disagree, especially for the desktop. I think there's great value in being able to update a shared library and get a fix in place for all applications, versus waiting for each application to update.
- UncleMeat 3y ago
  And as an application developer, hoping that your users aren't exposed to danger by linking ancient openssl versions or whatever is also a problem.
- duped 3y ago
  Apps ship with vendored or statically linked dependencies everywhere possible these days because system wide updates of shared libraries have caused too many breakages. It's just not a viable technology for todays' ecosystems.
  - JohnFen 3y ago
    > It's just not a viable technology for todays' ecosystems. I disagree, obviously. The problem you cite is very real, of course, but there are numerous ways to address it. I think that applications that avoid shared libraries do so because that's the path of least resistance.
    - duped 3y ago
      There really aren't numerous ways. You statically link, vendor your dependencies and bundle your app, specify version numbers for your .so dependencies, or use symbol versions. The latter two are the only options that involve any sharing of libraries. And avoiding it isn't just a path of least resistance but one of reliability and reproducibility. If I cannot pin the dependency down to the exact bytes I tested it with, I cannot tell you if you should trust the bits that get mapped and executed on your system. At the same time, the benefits to shared libraries are really diminishing: https://drewdevault.com/dynlib https://drewdevault.com/dynlib. It's not just that it's easier to ship statically linked or bundled apps. It's more reliable and doing the alternative doesn't have many benefits.

notacoward 3y ago

> It will miss private dynamic libraries, Docker containers, potentially virtual envs. Yes, it will. Does that make dynamic libraries a red herring, or does it mean these approaches all make the same mistake? Please think before you answer. Just because something's common doesn't mean it's wise or necessary. > it has a huge cost in terms of maintenance and backwards compatibility How much are those "huge costs" unique to that approach? Maintenance and backwards compatibility are still problems even with static linking or embedding into containers or any other alternative. It's disingenuous to count common problems against only one approach. The real tradeoff is between problems that are unique to each, and it's possible to disagree about which choice is best without stacking the deck for one side.

nicoburns 3y ago
Ultimately if the app is unmaintained, then it's likely to have security issues even if it's using dynamic libraries. If it is maintained then it shouldn't be a big deal to update it.
- deleted 3y ago
  [deleted]
- layer8 3y ago
  Security is not black and white. Better to be able to fix some security issues of an unmaintained app than none. This is a bit of a tangent, but I don’t think it is sustainable in the long run to require the ever-growing volume of software in use to all be actively maintained. We should find a model of software development where we can achieve sufficient security without having to maintain and rebuild the world all the time.
  - nicoburns 3y ago
    Long term I think we'll get most of the way there by eliminating C and C++ from our software stacks. Most security vulnerabilities (and even more of the most serious ones) are memory safety or UB related. And systematically eliminating those will give us more time to audit our code for other issues. Eliminating C and C++ also likely leads us to standardised build systems which makes rebuilding things much much easier.

JohnFen 3y ago

I disagree, especially for the desktop. I think there's great value in being able to update a shared library and get a fix in place for all applications, versus waiting for each application to update.

UncleMeat 3y ago
And as an application developer, hoping that your users aren't exposed to danger by linking ancient openssl versions or whatever is also a problem.
duped 3y ago
Apps ship with vendored or statically linked dependencies everywhere possible these days because system wide updates of shared libraries have caused too many breakages. It's just not a viable technology for todays' ecosystems.
- JohnFen 3y ago
  > It's just not a viable technology for todays' ecosystems. I disagree, obviously. The problem you cite is very real, of course, but there are numerous ways to address it. I think that applications that avoid shared libraries do so because that's the path of least resistance.
  - duped 3y ago
    There really aren't numerous ways. You statically link, vendor your dependencies and bundle your app, specify version numbers for your .so dependencies, or use symbol versions. The latter two are the only options that involve any sharing of libraries. And avoiding it isn't just a path of least resistance but one of reliability and reproducibility. If I cannot pin the dependency down to the exact bytes I tested it with, I cannot tell you if you should trust the bits that get mapped and executed on your system. At the same time, the benefits to shared libraries are really diminishing: https://drewdevault.com/dynlib https://drewdevault.com/dynlib. It's not just that it's easier to ship statically linked or bundled apps. It's more reliable and doing the alternative doesn't have many benefits.