5 ms·

It'll only rebuild the packages that depended on that particular openssl. This is an area where Nix shines, because all packages are explicitly bound to their d

by ris 6y ago

It'll only rebuild the packages that depended on that particular openssl. This is an area where Nix shines, because all packages are explicitly bound to their dependencies, it means it's no longer relevant what one file happens to be occupying `/usr/lib/libssl.so`, or even `/lib/x86_64-linux-gnu/libc.so.6`, so you can be running different apps that rely on totally different glibc versions alongside each other with no problems.

ComodoHacker 6y ago
I mean if there's a bug, it's not enough to patch one particular OpenSSL. You have to audit manually, so Nix won't make much of a difference.
- takeda 6y ago
  Well, by default it uses the same library everywhere, but it gives you an option that you can have two apps that rely on e.g. different version of openssl. If you do that it is on you to make sure both dependencies are updated. There is a bit of benefit as well. For example instead of creating a new derivation, you can override existing one (kind of like you extend a class in OO) if for example you make another version of openssl based off the existing one, but maybe changed compile flags, then nix will be smart enough to recompile both.
- bb010g 6y ago
  Except the auditing doesn't have to be manual: https://github.com/flyingcircusio/vulnix https://github.com/flyingcircusio/vulnix
zerd 6y ago
Oh, that sounds like it could solve my issue. E.g. I compiled my program against my glibc which is 2.24, but target was running 2.23. I didn't even use any "new" 2.24 features, but it was missing a symbol, so it wouldn't run. But then to compile against 2.23 locally, I had to get an older version of GCC (not sure why, but), and everything needed to build the older GCC, and so on. But then I got some old versions of libraries on my system, so I had to delete them. I ended up compiling it all inside a docker container because I didn't want to pollute my env with older versions.
- renox 6y ago
  Maybe but don't underestimate the effort, I needed to do something similar and tried to use Nix but I failed: the doc wasn't very good, there weren't 32bit packages.. So I just built gcc myself which I found very easy.

by ris 6y ago

ComodoHacker 6y ago

I mean if there's a bug, it's not enough to patch one particular OpenSSL. You have to audit manually, so Nix won't make much of a difference.

takeda 6y ago
Well, by default it uses the same library everywhere, but it gives you an option that you can have two apps that rely on e.g. different version of openssl. If you do that it is on you to make sure both dependencies are updated. There is a bit of benefit as well. For example instead of creating a new derivation, you can override existing one (kind of like you extend a class in OO) if for example you make another version of openssl based off the existing one, but maybe changed compile flags, then nix will be smart enough to recompile both.
bb010g 6y ago
Except the auditing doesn't have to be manual: https://github.com/flyingcircusio/vulnix https://github.com/flyingcircusio/vulnix

zerd 6y ago

Oh, that sounds like it could solve my issue. E.g. I compiled my program against my glibc which is 2.24, but target was running 2.23. I didn't even use any "new" 2.24 features, but it was missing a symbol, so it wouldn't run. But then to compile against 2.23 locally, I had to get an older version of GCC (not sure why, but), and everything needed to build the older GCC, and so on. But then I got some old versions of libraries on my system, so I had to delete them. I ended up compiling it all inside a docker container because I didn't want to pollute my env with older versions.

renox 6y ago
Maybe but don't underestimate the effort, I needed to do something similar and tried to use Nix but I failed: the doc wasn't very good, there weren't 32bit packages.. So I just built gcc myself which I found very easy.