`nix copy` doesn't heal missing ca information in the receiving store (requiring trusted user and ignore-signatures) #956

New issue

Open

opened 2025-08-09 13:46:03 +00:00 by jade · 3 comments

jade commented

2025-08-09 13:46:03 +00:00

Owner

I ran this:

nix copy --derivation /nix/store/92nm8p7vdwax22wynqfl8lx9ijzd8nc3-nixos-system-thinnernix-25.11.20250719.c87b95e.drv --to ssh-ng://thinnernix

Source machine:

$ nix path-info --json /nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix
[{"ca":"fixed:r:sha256:0maq1klm24l8gbdsydq5fkb5md6z1b7fmll8zw2ilf3hlfkdq6xv","narHash":"sha256-uxvc
pqNwOBoF/4jS6s4K37Ra1nQFN6/beogSUekMWFU=","narSize":352,"path":"/nix/store/30qhz45nwgfyns13ijq0nwrs
jp8m7ypa-relaxedsandbox.nix","references":[],"registrationTime":1754019283,"valid":true}]

$ nix --version
nix (Lix, like Nix) 2.94.0-dev-pre20250721-bf3d52e
System type: aarch64-darwin
Additional system types: x86_64-darwin
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /Users/jade/.config/nix/nix.conf:/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/2pljkjvpvbd41bg6izk41j8ygy5087zw-lix-2.94.0-dev-pre20250721-bf3d52e/share

Dest machine:

[nixos@nixos:~]$ nix path-info --json /nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix
{"/nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix":{"ca":null,"deriver":null,"narHas
h":"sha256-uxvcpqNwOBoF/4jS6s4K37Ra1nQFN6/beogSUekMWFU=","narSize":352,"references":[],"registratio
nTime":1754742685,"signatures":[],"ultimate":false}}
[nixos@nixos:~]$ nix --version
nix (Nix) 2.28.4

Note the lost ca field here. Now, I don't know if this is cppnix being busted or us being busted, but we do need to double check if we are copying store path ca correctly as it's supported on the existing protocol to do it, but we might be calling the wrong stuff.

I ran this: ``` nix copy --derivation /nix/store/92nm8p7vdwax22wynqfl8lx9ijzd8nc3-nixos-system-thinnernix-25.11.20250719.c87b95e.drv --to ssh-ng://thinnernix ``` Source machine: ``` $ nix path-info --json /nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix [{"ca":"fixed:r:sha256:0maq1klm24l8gbdsydq5fkb5md6z1b7fmll8zw2ilf3hlfkdq6xv","narHash":"sha256-uxvc pqNwOBoF/4jS6s4K37Ra1nQFN6/beogSUekMWFU=","narSize":352,"path":"/nix/store/30qhz45nwgfyns13ijq0nwrs jp8m7ypa-relaxedsandbox.nix","references":[],"registrationTime":1754019283,"valid":true}] $ nix --version nix (Lix, like Nix) 2.94.0-dev-pre20250721-bf3d52e System type: aarch64-darwin Additional system types: x86_64-darwin Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /Users/jade/.config/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/2pljkjvpvbd41bg6izk41j8ygy5087zw-lix-2.94.0-dev-pre20250721-bf3d52e/share ``` Dest machine: ``` [nixos@nixos:~]$ nix path-info --json /nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix {"/nix/store/30qhz45nwgfyns13ijq0nwrsjp8m7ypa-relaxedsandbox.nix":{"ca":null,"deriver":null,"narHas h":"sha256-uxvcpqNwOBoF/4jS6s4K37Ra1nQFN6/beogSUekMWFU=","narSize":352,"references":[],"registratio nTime":1754742685,"signatures":[],"ultimate":false}} [nixos@nixos:~]$ nix --version nix (Nix) 2.28.4 ``` Note the lost ca field here. Now, I don't know if this is cppnix being busted or us being busted, but we do need to double check if we are copying store path ca correctly as it's supported on the existing protocol to do it, but we might be calling the wrong stuff.

jade added the

bug

Area/protocol

Area/store

labels

2025-08-09 13:46:03 +00:00

pennae commented

2025-08-09 17:27:40 +00:00

Owner

so far we've failed to reproduce this with ssh-ng://localhost?remote-store=/somewhere, ssh-ng://elsewhere?remote-store=/somewhere, ssh-ng://elsewhere?remote-store=/somewhere&remote-program=/nix/store/snafuuuuuyougettheidea-nix-2.28.4/bin/nix-daemon, and a nixos installer iso with cppnix 2.28.4.

we're running nix (Lix, like Nix) 2.94.0-dev-pre20250729-fde2a4b for these tests

so far we've failed to reproduce this with `ssh-ng://localhost?remote-store=/somewhere`, `ssh-ng://elsewhere?remote-store=/somewhere`, `ssh-ng://elsewhere?remote-store=/somewhere&remote-program=/nix/store/snafuuuuuyougettheidea-nix-2.28.4/bin/nix-daemon`, and a nixos installer iso with cppnix 2.28.4. we're running `nix (Lix, like Nix) 2.94.0-dev-pre20250729-fde2a4b` for these tests

jade commented

2025-08-10 09:26:28 +00:00

Author

Owner

I'll have to try to repro this again. It's very possible that somehow it got messed up in a weird way.

jade commented

2025-08-10 09:37:53 +00:00

Author

Owner

Okay I found the problem (and it explains perfectly why it was gaslighting us): that path was already there on a fresh iso (nixos-minimal-25.05.807313.59e69648d345-aarch64-linux), but was registered without ca information because it was already on the iso from the beginning (which probably was done via some method like nix-store --import or whatever that loses the metadata).

Ideally, this would be a self-healing condition, imo, but it may be impossible to fix under the current protocol (I don't know!): either we:

while deciding to copy, check if the dest has correct ca information (can we re-register/update a path in-place?), which we may even already be given, then fix the registration
figure out how to build the iso without semi-corrupting the store paths (maybe impossible, maybe not? it might be possible to find the ca information once more for FODs without modifying nix-store --export format by just checking whether it matches the path but definitely not for ca-with-references)

Okay I found the problem (and it explains perfectly why it was gaslighting us): that path was *already* there on a fresh iso (nixos-minimal-25.05.807313.59e69648d345-aarch64-linux), but was registered without ca information because it was already on the iso from the beginning (which probably was done via some method like nix-store --import or whatever that loses the metadata). Ideally, this would be a self-healing condition, imo, but it may be impossible to fix under the current protocol (I don't know!): either we: - while deciding to copy, check if the dest has correct ca information (can we re-register/update a path in-place?), which we may even *already be given*, then fix the registration - figure out how to build the iso without semi-corrupting the store paths (maybe impossible, maybe not? it might be possible to find the ca information once more for FODs without modifying nix-store --export format by just checking whether it matches the path but definitely not for ca-with-references)

jade changed title from ~~nix copy seems to not copy paths' ca details over ssh-ng~~ to nix copy doesn't heal missing ca information in the receiving store (requiring trusted user and ignore-signatures)

2025-08-10 15:37:10 +00:00