Nix content-addressing dreams
Interestingly, although Nix does hash the inputs (ideally[1] meaning source code),
it doesn’t actually protect too well the outputs against subversion…
because it regularly downloads the outputs (i.e. compiled binaries) from a cache,
and thus requires extending the trust to the cache server…
The core packages presumably download from the official cache,
but some thirdparty packages
do like to try and happily mandate extending global trust permanently towards external caches,
posing a concrete security concern.
AFAIU there’s a (slow going, maybe even stuck)
effort to try and support content-addressed fetching of binaries (i.e. outputs) as well;
I kinda hope for a future when the nixpkgs repo includes expected hashes of the build outputs,
and the nix command downloads them via DHT from torrents or somewhere such,
with the official Nix Hydra server only working as a torrent seed.
(See also: related,
related/archive,
related,
related,
related.)
-
Quite often, packages definitions unfortunately use prebuilt binary blobs, i.e. “releases” from github, as “inputs”. At least they have to hash them, thus pinning/“content-addressing”, but then again the trust is moved onto the person who uploaded the compiled binary to the github releases page, thus introducing disconnect from the actual source code. ↩︎