Interaction between validity registration and fetchClosure #14912
Description
I intend this as feedback for the experimental fetchClosure feature.
I've hit a limitation of fetchClosure caused by the existing closureInfo / validity registration mechanism which I think limits its usefulness or makes it tricky to use in its current form.
Observation: makeValidityRegistration => the validity registration format conveys no information about CA paths. Therefore, all paths registered via this mechanism are loaded as non-CA, and require inputAddressed = true with fetchClosure to reference any path which is installed on a system via the validity registration mechanism. (This is used to populate the store database on first boot of a VM image for example).
If all paths on a freshly booted system are non-CA, then you can't refer to those without hitting, e.g:
error: The 'fromPath' value '/nix/store/zzzz...-source' is input-addressed, but 'inputAddressed' is set to 'false' (default).
Concretely, I get this problem when I want to put the nixpkgs sources into a VM image during its build using fetchClosure. If I build the VM image with /new/ nixpkgs sources, then the sources are CA signed. If I build a new VM image using the same CA sources, they are picked up from the registration of the host and they are not CA signed. This means there is no single choice of inputAddressed that I can use. tryEval blows up so I can't fall back to the other choice.
My current high level goal is to avoid fetching the nixpkgs sources for the current VM image when evaluating expressions using that nixpkgs, by baking them into the VM image; but I believe the lack of CA information in the validity registration could cause this any time the path you wanted to fetch with fetchClosure was fed in through nix-store --load-db.
I'm wondering if the problem here is a deficiency in the registration format and if there are plans to make this preserve CA hashes.
Related: