closureInfo: disallow substitutes, instead of only prefering local build

[ajs124]

"exportReferencesGraph" combined with "__structuredAttrs = true" "includes
the sizes and hashes of paths". If the result of the closureInfo is
substituted, but the contents of any path of the closure differs between
the binary cache and the local store, which can easily happen, because
not everything is perfectly reproducible, this leads to hash mismatches in
the image builders, which pass the output of closureInfo to
"nix-store --load-db".

Also see NixOS/nix#4840

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Added a release notes entry if the change is major or breaking
• Fits CONTRIBUTING.md.

[jonringer]

cc @edolstra

[roberth]

Nothing prevents a subsequent derivation, like the one that builds the image, from incorporating the output of closureInfo, causing it to be substitutable. So while this may help with the symptoms you're experiencing, it is not a general solution.

This derivation exacerbates all reproducibility problems, which no-one expects a derivation to do. For this reason, this functionality must only be used in derivations that produce no references to the original paths; instead incorporating all paths in an image (or similar). After all that's the only way to guarantee a consistent output. (a locally built path with unreproducible output may exist before substituting the derivation with the closureInfo dependency)

I would suggest replacing it by a hash- and size-free variant such as writeReferencesToFile wherever possible. That function only writes all closure paths and doesn't exacerbate reproducibility problems. The remaining use cases, hopefully only image building derivations, don't benefit at all from having this dangerous logic in a separate derivation. Perhaps its (limited) logic can be provided as a script instead, with some clear warnings that any derivations using it must not reference the original paths.