4 ms·

Immutabililty actually destroys the security benefits that shared objects bring, because with every patch the location of the library changes. So you're back to

by tremon 2y ago

Immutabililty actually destroys the security benefits that shared objects bring, because with every patch the location of the library changes. So you're back to the exact same situation as without dynamic linking: every dependency will need to be recompiled anyway against the new library location. And that means that even though you may have a shared object that's already patched, every other package on your system that's not yet been recompiled is still vulnerable.

saagarjha 2y ago
Applications rarely link against versioned shared libraries. It is rare that a security patch would require every application to have its list of dependent libraries edited.
- whytevuhuni 2y ago
  And yet, even a compatible change that doesn't break the ABI, will cause NixOS to rebuild all packages that depend on that library. That's because while tracking dependencies is a solved problem, tracking whether each dependency correctly follows semver (especially in C land), and which packages and which "minor" patches break or don't break ABI, is not a solved problem.
  - saagarjha 2y ago
    This sounds NixOS exercising an abundance of caution rather than actually needing to do this.
  - anon291 2y ago
    Rebuilding is cheap, especially when NixOS's hydra does it for you. For most typical use cases, where you're just using distro packages, you will get the latest updates (including shared dependency updates) straight from hydra. There's no need to recompile, and I'm not sure why compilation is even being brought up here
rssoconnor 2y ago
In NixOS, you can use system.replaceDependencies to create a new derivation that performs a search and replace on references to dynamically linked libraries in the old derivation, recursively swapping them out for the new library without recompiling.
anon291 2y ago
It's no better than static linking then, which is one of the proposed solutions here. In reality, if you're using a latest nixpkgs, there's no recompile, since hydra's already done that, and the binaries come updated with shared dependencies. Again... solved problem

by tremon 2y ago

saagarjha 2y ago

Applications rarely link against versioned shared libraries. It is rare that a security patch would require every application to have its list of dependent libraries edited.

whytevuhuni 2y ago
And yet, even a compatible change that doesn't break the ABI, will cause NixOS to rebuild all packages that depend on that library. That's because while tracking dependencies is a solved problem, tracking whether each dependency correctly follows semver (especially in C land), and which packages and which "minor" patches break or don't break ABI, is not a solved problem.
- saagarjha 2y ago
  This sounds NixOS exercising an abundance of caution rather than actually needing to do this.
- anon291 2y ago
  Rebuilding is cheap, especially when NixOS's hydra does it for you. For most typical use cases, where you're just using distro packages, you will get the latest updates (including shared dependency updates) straight from hydra. There's no need to recompile, and I'm not sure why compilation is even being brought up here

rssoconnor 2y ago

In NixOS, you can use system.replaceDependencies to create a new derivation that performs a search and replace on references to dynamically linked libraries in the old derivation, recursively swapping them out for the new library without recompiling.

anon291 2y ago

It's no better than static linking then, which is one of the proposed solutions here. In reality, if you're using a latest nixpkgs, there's no recompile, since hydra's already done that, and the binaries come updated with shared dependencies. Again... solved problem