Allow to sign generated derivation

[FirelightFlagboy]

I would like that nh to be able to sign generated derivation similar to nix store sign when used like so:

nix store sign --recursive --key-file a_key_file ./result

I would use that feature when building a nixos configuration for a remote host.

If I had to do it, I would add an optional option --sign-key-file to nh os {switch,boot,test,build,build-vm} (not sure about the others 🤷) that execute the nix store command above

[NotAShelf]

Interesting.

I'm going to have to think about the implementation a little but I am generally not opposed to the idea. Though, there are some refactors planned for the near futute so I cannot promise that this can be done fast.

In the meantime, could you elaborate on the use case you are envisioning? I'm curious.

[NotAShelf]

Interesting.

I'm going to have to think about the implementation a little but I am generally not opposed to the idea. Though, there are some refactors planned for the near futute so I cannot promise that this can be done fast.

In the meantime, could you elaborate on the use case you are envisioning? I'm curious.

[FirelightFlagboy]

Currently if I do:

nh os test .#nixosConfiguration.foo --target-host foo.local

During the activation I would get:

cannot add path '[...]' because it lacks a signature by a trusted key

I could add the host user to trusted-user but it does not fell right to me to give more permission to that user. So the only other possibility is to sign the derivation.

I've done a minimal script that does every steps like nh os switch but with the sign before the copy and found out that it work:

result=$(nix build .\#nixosConfigurations.foo.config.system.build.toplevel --no-link --print-out-paths)
nix store sign $result --key-file a_file --recursive
nix copy --to 'ssh://foo.local' $result
ssh -t foo.local "sudo $result/bin/switch-to-configuration switch"

[NotAShelf]

This sounds like a nice feature for the future, but I'm not going to be able to work on it at the time. There are other features I'm hoping to prioritize in the immediate future, specifically for the 4.3.0 release.

Though looking into your issue, it seems a little like the SSH user is not a trusted user on the host foo.local, which causes the "lacks a signature" error. I've got a PR on the way that refactors how --build-host functions, which might resolve the issue. Testing would be appreciated once the PR is up, but if it doesn't solve the issue I'm going to add a signature function after the 4.3.0 release.