lis 
let's try deploying the SSH host key declaratively so that we can decrypt the host key with the host key that we haven't decrypted yet– lis, since yesterday 
but hey that's how you learn 
so i suppose it's impossible to pre-generate any secret that nix has to touch, and therefore it's impossible to create a system that uses secrets purely from a nix expression
because anything nix has to touch must be considered public knowledge (as in, ends up in at least one world-readable nix store or can be recreated from there)
therefore, there is no safe way nix would be able to access any of the secrets you define in sops, they're black boxes shipped to the target host and only encrypted there
strictly speaking, you could pass secrets with
which means the target host has to have some state that can't be managed with nix; at the very least the recipient key
because anything nix has to touch must be considered public knowledge (as in, ends up in at least one world-readable nix store or can be recreated from there)
therefore, there is no safe way nix would be able to access any of the secrets you define in sops, they're black boxes shipped to the target host and only encrypted there
strictly speaking, you could pass secrets with
--arg/--argstr, or you could use --impure and just read environment variables or arbitrary files, and sops even has exec-env and exec-file subcommands to do just that, but even then i'm pretty sure everything you pass this way ends up in some .drvwhich means the target host has to have some state that can't be managed with nix; at the very least the recipient key
i'm pretty sure everything you pass this way ends up in some .drvyea
> secret=meow nix build --impure --print-out-paths --expr '
derivation {
name = "foo";
system = builtins.currentSystem;
builder = "/bin/sh";
args = ["-c" "echo ${builtins.getEnv "secret"} > $out"];
}
'
> nix derivation show /nix/store/cywy0y5cb0njz975j0lrrh2m3ll29kqy-foo
{
"/nix/store/5axlc4wjy3s4v5xrk6c5db31y9kh6fi5-foo.drv": {
"args": [
"-c",
"echo meow > $out"
],
"builder": "/bin/sh",
"env": {
"builder": "/bin/sh",
"name": "foo",
"out": "/nix/store/cywy0y5cb0njz975j0lrrh2m3ll29kqy-foo",
"system": "x86_64-linux"
},
"inputDrvs": {},
"inputSrcs": [],
"name": "foo",
"outputs": {
"out": {
"path": "/nix/store/cywy0y5cb0njz975j0lrrh2m3ll29kqy-foo"
}
},
"system": "x86_64-linux"
}
}
iio_core.h@lis I don't really consider this a problem in practice; target hosts don't exist in a vacuum, they'll always have *some* state associated with them that wasn't fully determined by a deterministic nix expression. For starters, something had to create them in the first place, and get them into a state where your deploy tool can deploy to them, might as well create a secrets encryption key at that point too and export its pubkey to your nix config, right?