From e9c3340eff9dd39b4d1b84f1000b3f0ecee143e5 Mon Sep 17 00:00:00 2001 From: Wout Mertens Date: Thu, 5 Nov 2020 14:13:34 +0100 Subject: [PATCH] 17: updates from comments --- rfcs/0017-intensional-store.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/0017-intensional-store.md b/rfcs/0017-intensional-store.md index ad0c3a0..d596237 100644 --- a/rfcs/0017-intensional-store.md +++ b/rfcs/0017-intensional-store.md @@ -32,6 +32,7 @@ By using content hashes instead of output hashes, we can: - make the Nix store network-writeable and world-shareable - predefine mappings from output to content hash without building - store paths can be verified without access to the Nix Store DB +- public trust mappings allow detecting non-reproducible builds Additionally, this is an opportunity to move the Nix store to a filesystem location supported by most non-NixOS systems, namely `/var/lib/nix`. @@ -175,7 +176,7 @@ To make sure only the build's own references need rewriting, it is recommended t After the build, its `$cas` is calculated and any occurences of the build path are replaced with `/var/lib/nix/$cas`. -If there undetected build path references, they might cause the finished entry to work incorrectly, and they will cause `$cas` to differ on every build of `$out`. This must be handled on a case-by-case basis. +If there undetected build path references, they might cause the finished entry to work incorrectly, and they will cause `$cas` to differ on every build of `$out`. This must be handled on a case-by-case basis. Perhaps we'll need pluggable hash rewriters. The build can happen by a sandboxing build daemon like `nix-build`, but that is not a requirement.