3 ms·

If you are using upstream libxyz 1.3 but they don’t provide security updates for it then you should do something even if you are using dynamic linking. Imagine

If you are using upstream libxyz 1.3 but they don’t provide security updates for it then you should do something even if you are using dynamic linking. Imagine that redhat provides security updates but Debian uses 1.4, are you going to tell your users that they must use redhat? I don’t see that dynamic linking makes a lot of difference here.

AnthonyMouse 5y ago
Typically with dynamic linking, the library is maintained as a separate package by a separate party who takes distribution-wide responsibility for backporting anything. So you have two alternatives. One is that you make your software compatible with both version 1.3 and version 1.4, so it can be used on both Redhat and Debian with dynamic linking. This is a bit of work up front which is why everybody grumbles and looks for an alternative. The other is that you vendor in version 1.3 so that you're using version 1.3 even on Debian. But now that library is your responsibility to patch instead of the distribution's. So instead of doing that work up front, you either maintain the library yourself on an ongoing basis (which may be more work than supporting two only slightly different library versions up front), or you neglect to do it and have a security vulnerability.
- hibbelig 5y ago
  As a software author, the first alternative doesn't sound very attractive to me. Because as an author, I will want the upstream version of libxyz, and if the distribution provides security updates past the upstream date, this means that I need to use that exact distribution to benefit. And vendoring in is pretty much equivalent to what happens with static linking. My parent had suggested that dynamic linking is some great solution, and I don't see it's that great.
  - AnthonyMouse 5y ago
    > Because as an author, I will want the upstream version of libxyz Why would that be true in general? It would only be the case if the upstream version contains some feature you need that isn't present in the version packaged by the distribution, and then you would only need to do it until the next version of the distribution packages the newer library version. > and if the distribution provides security updates past the upstream date, this means that I need to use that exact distribution to benefit. Or support the multiple versions of the library, which for non-ridiculous libraries is often no more than refraining from using the features not present in the older versions.
    - hibbelig 5y ago
      >> Because as an author, I will want the upstream version of libxyz > Why would that be true in general? Because I want to write software that works on various Unices, not just one Linux distribution. So it seems safer to rely on software that my users (the people who install the software I wrote) will be able to install from source, if necessary. If I were to require whatever version Debian had at the moment, then I'd leave Fedora, Arch, OpenBSD, FreeBSD, Illumos aficionados in the lurch.

AnthonyMouse 5y ago

Typically with dynamic linking, the library is maintained as a separate package by a separate party who takes distribution-wide responsibility for backporting anything. So you have two alternatives. One is that you make your software compatible with both version 1.3 and version 1.4, so it can be used on both Redhat and Debian with dynamic linking. This is a bit of work up front which is why everybody grumbles and looks for an alternative. The other is that you vendor in version 1.3 so that you're using version 1.3 even on Debian. But now that library is your responsibility to patch instead of the distribution's. So instead of doing that work up front, you either maintain the library yourself on an ongoing basis (which may be more work than supporting two only slightly different library versions up front), or you neglect to do it and have a security vulnerability.

hibbelig 5y ago
As a software author, the first alternative doesn't sound very attractive to me. Because as an author, I will want the upstream version of libxyz, and if the distribution provides security updates past the upstream date, this means that I need to use that exact distribution to benefit. And vendoring in is pretty much equivalent to what happens with static linking. My parent had suggested that dynamic linking is some great solution, and I don't see it's that great.
- AnthonyMouse 5y ago
  > Because as an author, I will want the upstream version of libxyz Why would that be true in general? It would only be the case if the upstream version contains some feature you need that isn't present in the version packaged by the distribution, and then you would only need to do it until the next version of the distribution packages the newer library version. > and if the distribution provides security updates past the upstream date, this means that I need to use that exact distribution to benefit. Or support the multiple versions of the library, which for non-ridiculous libraries is often no more than refraining from using the features not present in the older versions.
  - hibbelig 5y ago
    >> Because as an author, I will want the upstream version of libxyz > Why would that be true in general? Because I want to write software that works on various Unices, not just one Linux distribution. So it seems safer to rely on software that my users (the people who install the software I wrote) will be able to install from source, if necessary. If I were to require whatever version Debian had at the moment, then I'd leave Fedora, Arch, OpenBSD, FreeBSD, Illumos aficionados in the lurch.