4 ms·

The difference between dynamically and statically linking doesn’t change the patching story so long as applications ship with all their libs and share nothing.

The difference between dynamically and statically linking doesn’t change the patching story so long as applications ship with all their libs and share nothing. The only difference is that a statically linked app is a large binary blob in a directory while a dynamically linked app is multiple smaller blobs in a directory. Whether or not statically or dynamically linked apps are the future, the idea of system wide shared libraries seems like it’s going away.

bbarnett 5y ago
shared ram too. it adds up.
- mpyne 5y ago
  It does, but we're already moving to a world where deployed apps are one of the very few things running in a container, which is itself running somewhere in a VM, so there's less sharing to achieve.
  - ithkuil 5y ago
    Yeah. In that scenario the distinction between dynamic and static linking is moot. In both cases you need to update the container image and when you do you only fixed that container image and you still need to update all the other images
mercurialfck 5y ago
There's absolutely no need for just one-ring-to-rule-them-all copy of libz.so. Shared libraries can be versioned and garbage collected like how habitat (hab) does it: in separate directories.
IshKebab 5y ago
Exactly. The issue is not static vs dynamic; it's bundled vs unbundled. You could probably even do an "unbundled" statically linked system, e.g. imagine Debian but everything is statically linked. Doesn't matter that everything is statically linked - if there's a vulnerability in libpng you can still easily update dependencies. Just uses more network / disk space.
- Wowfunhappy 5y ago
  I agree, but if you're bundling the dependencies why not just statically link them too? I've never understood the way macOS does it (dynamic linking, but app bundles ship with the libraries they need included).
  - ziml77 5y ago
    In some cases it's required such as if you're using a closed-source library that doesn't provide a static version or if you're calling LGPL code from non-GPL-compatible code.
  - alkonaut 5y ago
    This is also how windows apps always worked. It’s good for deployment because an update might not touch more than a few files. Also not all language ecosystems support static linking at all, e.g .NET
    - dragonwriter 5y ago
      > Also not all language ecosystems support static linking at all, e.g .NET The “language ecosystem” of .NET supports static linking via .NET Native, doesn't it?
      - mastax 5y ago
        .NET native is a dead end technology that only supported old UWP apps. There's the new single file builds but those just concatenate the dynamic libs together into one file. There's also the new .NET linker for trimmed builds, but that requires special annotations from many libs to work.
  - xg15 5y ago
    Not a mac user, but one upside I can see is that this forces apps to at least declare which libraries they are using. If everything is statically linked, it might be hard to figure out where on the system a vulnerable library is being used at all.
xg15 5y ago
> The difference between dynamically and statically linking doesn’t change the patching story I think there are some edge cases where the mainteners will always be caught between a rock and a hard place and the only way to move forward is to involve the application developers - at least as long as library compatibility can't be defined more rigidly. As a dev, you'd like to pin the versions of your dependencies as tightly as possible, so you know the library will behave in production exactly as it did in your tests. As a maintener, you'd like applications to specify their dependency versions as loosely as possible, so you can transparently update a dependency in case of critical patches. This means, there can always occur a case where version x of a library has a critical vulnerability but version x+1 breaks the assumptions that the software is making. No matter if the library is linked statically or dynamically, this situation can't be solved by the maintener alone. Of course the GP is also correct in a sense: If applications bundle libraries or set tight version restrictions, it's now the responsibility of the developers to track critical vulnerabilities in all of their dependencies and integrate the patches as quickly as possible. The problem with bundled libraries is that now we have to trust every single developer to get this right.
- alkonaut 5y ago
  > As a dev, you'd like to pin the versions of your dependencies as tightly as possible, so you know the library will behave in production exactly as it did in your tests. Indeed, and this is why the shared nothing models are so attractive. Unless I was developing anything security critical such as server apps, I'd probably never want to deploy anything in classical unix style where any part of the app could be replaced behind the back of my application. On windows and for desktop software, the risk of a failed install or the user sabotaging their own install without realizing it is more common than the risk of having an outdated version of a library. If the application is mostly or completely offline (e.g. only online for updates or documentation), then the surface area for attack is pretty small. So I'd usually go so far as validating the integrity of the app with a checksum on startup too, and refuse to start if the app isn't byte for byte exactly as expected. This also obivously means my app has almost no risk of ending up in a package in a Linux distribution too.

bbarnett 5y ago

shared ram too. it adds up.

mpyne 5y ago
It does, but we're already moving to a world where deployed apps are one of the very few things running in a container, which is itself running somewhere in a VM, so there's less sharing to achieve.
- ithkuil 5y ago
  Yeah. In that scenario the distinction between dynamic and static linking is moot. In both cases you need to update the container image and when you do you only fixed that container image and you still need to update all the other images

mercurialfck 5y ago

There's absolutely no need for just one-ring-to-rule-them-all copy of libz.so. Shared libraries can be versioned and garbage collected like how habitat (hab) does it: in separate directories.

IshKebab 5y ago

Exactly. The issue is not static vs dynamic; it's bundled vs unbundled. You could probably even do an "unbundled" statically linked system, e.g. imagine Debian but everything is statically linked. Doesn't matter that everything is statically linked - if there's a vulnerability in libpng you can still easily update dependencies. Just uses more network / disk space.

Wowfunhappy 5y ago
I agree, but if you're bundling the dependencies why not just statically link them too? I've never understood the way macOS does it (dynamic linking, but app bundles ship with the libraries they need included).
- ziml77 5y ago
  In some cases it's required such as if you're using a closed-source library that doesn't provide a static version or if you're calling LGPL code from non-GPL-compatible code.
- alkonaut 5y ago
  This is also how windows apps always worked. It’s good for deployment because an update might not touch more than a few files. Also not all language ecosystems support static linking at all, e.g .NET
  - dragonwriter 5y ago
    > Also not all language ecosystems support static linking at all, e.g .NET The “language ecosystem” of .NET supports static linking via .NET Native, doesn't it?
    - mastax 5y ago
      .NET native is a dead end technology that only supported old UWP apps. There's the new single file builds but those just concatenate the dynamic libs together into one file. There's also the new .NET linker for trimmed builds, but that requires special annotations from many libs to work.
- xg15 5y ago
  Not a mac user, but one upside I can see is that this forces apps to at least declare which libraries they are using. If everything is statically linked, it might be hard to figure out where on the system a vulnerable library is being used at all.

xg15 5y ago

> The difference between dynamically and statically linking doesn’t change the patching story I think there are some edge cases where the mainteners will always be caught between a rock and a hard place and the only way to move forward is to involve the application developers - at least as long as library compatibility can't be defined more rigidly. As a dev, you'd like to pin the versions of your dependencies as tightly as possible, so you know the library will behave in production exactly as it did in your tests. As a maintener, you'd like applications to specify their dependency versions as loosely as possible, so you can transparently update a dependency in case of critical patches. This means, there can always occur a case where version x of a library has a critical vulnerability but version x+1 breaks the assumptions that the software is making. No matter if the library is linked statically or dynamically, this situation can't be solved by the maintener alone. Of course the GP is also correct in a sense: If applications bundle libraries or set tight version restrictions, it's now the responsibility of the developers to track critical vulnerabilities in all of their dependencies and integrate the patches as quickly as possible. The problem with bundled libraries is that now we have to trust every single developer to get this right.

alkonaut 5y ago
> As a dev, you'd like to pin the versions of your dependencies as tightly as possible, so you know the library will behave in production exactly as it did in your tests. Indeed, and this is why the shared nothing models are so attractive. Unless I was developing anything security critical such as server apps, I'd probably never want to deploy anything in classical unix style where any part of the app could be replaced behind the back of my application. On windows and for desktop software, the risk of a failed install or the user sabotaging their own install without realizing it is more common than the risk of having an outdated version of a library. If the application is mostly or completely offline (e.g. only online for updates or documentation), then the surface area for attack is pretty small. So I'd usually go so far as validating the integrity of the app with a checksum on startup too, and refuse to start if the app isn't byte for byte exactly as expected. This also obivously means my app has almost no risk of ending up in a package in a Linux distribution too.