4 ms·

The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need

The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or more binaries to go and take the new library and release a new version of their binary. This is a solvable problem. Package managers such as Nix and Guix rebuild packages if any of their transitive dependencies have been changed. The difficult part are now language-specific ecosystems that use lock files to lock all their dependencies. Traditional C/C++ programs, either statically linked or dynamically linked, have a dependency graph such that e.g. each program that uses OpenSSL has the same package definition in their transitive dependencies. However, e.g. Rust programs may have different versions of the same crate locked. (There are solutions to that, but there is still work to be done.)

tsimionescu 6y ago
I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains for C, C++, Java, Go and maybe 1-2 others on my systems and on my servers in case I need to rebuild all of my binaries.
- danieldk 6y ago
  I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains [...] You don't have to, most NixOS/Guix systems use binary caches. So, their build clusters do the work for the packages included the nixpkgs/guix package sets. If your organization builds their own packages in top of that, you can use a CI plus your private cache (or something like Cachix).
  - adev_ 6y ago
    > You don't have to, most NixOS/Guix systems use binary caches. Yes, Nix/Guix and Spack are up to my knowledge the only systems that got that right. The centralised recipe repository (and their functional nature) make scratch recompilation reliable and easy. Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number... The distributed approach of some package manager often come with a security cost unfortunately. And that's a problem for static linking.
    - danieldk 6y ago
      > Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number... I don't know about spack or Guix, but nixpkgs has buildRustCrate, which builds each Rust crate dependency as a Nix derivation (it does not use Cargo). In this kind of setup it is possible to override specific crate versions across all packages that use a specific crate. Unfortunately, currently most Rust-based packages in nixpkgs use buildRustPackage, which does not follow this approach [1]. [1] https://github.com/NixOS/nixpkgs/issues/89563 https://github.com/NixOS/nixpkgs/issues/89563

tsimionescu 6y ago

I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains for C, C++, Java, Go and maybe 1-2 others on my systems and on my servers in case I need to rebuild all of my binaries.

danieldk 6y ago
I was talking about finding vulnerabilities on end-user systems and servers. I don't know about others, but I don't generally keep compiler tool chains [...] You don't have to, most NixOS/Guix systems use binary caches. So, their build clusters do the work for the packages included the nixpkgs/guix package sets. If your organization builds their own packages in top of that, you can use a CI plus your private cache (or something like Cachix).
- adev_ 6y ago
  > You don't have to, most NixOS/Guix systems use binary caches. Yes, Nix/Guix and Spack are up to my knowledge the only systems that got that right. The centralised recipe repository (and their functional nature) make scratch recompilation reliable and easy. Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number... The distributed approach of some package manager often come with a security cost unfortunately. And that's a problem for static linking.
  - danieldk 6y ago
    > Now good luck to get that with most lock-file based package managers like npm, cargo or pip with ~1000 packages in your dependency tree that hardcode their dependency number... I don't know about spack or Guix, but nixpkgs has buildRustCrate, which builds each Rust crate dependency as a Nix derivation (it does not use Cargo). In this kind of setup it is possible to override specific crate versions across all packages that use a specific crate. Unfortunately, currently most Rust-based packages in nixpkgs use buildRustPackage, which does not follow this approach [1]. [1] https://github.com/NixOS/nixpkgs/issues/89563 https://github.com/NixOS/nixpkgs/issues/89563