3 ms·

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 [...] Y

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