sops-nix: sops.secrets..path not working properly in the home-manager module

I’m using the home-manager module on Darwin.

I am trying to add a .netrc file to my home directory. I tried setting the path to the target file

  imports = [ sops-nix.homeManagerModule ];

  sops.defaultSopsFile = ../secrets/john/secrets.yaml;
  sops.age.keyFile = "${config.home.homeDirectory}/${ageKeyFilePath}";

  sops.secrets.netrc = { path = "/Users/john/.netrc"; };

After applying the change, /Users/john/.netrc doesn’t exist. And $(getconf DARWIN_USER_TEMP_DIR)/secrets/netrc is linked to itself.

lt --no-icons $(getconf DARWIN_USER_TEMP_DIR)/secrets*

/var/folders/90/w6qv2tw95gb1c53jvsm3vh0w0000gn/T/secrets
└── netrc -> /var/folders/90/w6qv2tw95gb1c53jvsm3vh0w0000gn/T/secrets/netrc
/var/folders/90/w6qv2tw95gb1c53jvsm3vh0w0000gn/T/secrets.d
├── 1
│  └── netrc
├── age-keys.txt
└── sops-nix-secretfs

Is there another way to get the decrypted file into the correct location?

About this issue

Original URL
State: open
Created a year ago
Reactions: 1
Comments: 21 (6 by maintainers)

Most upvoted comments

I also have the issue where %r doesn’t get expanded on linux/nixos-unstable. It just places %r/secrets/mySecret in to my config 😕

Janik-Haag on Jul 16, 2023

@jhvst I believe your issue is tracked at #284 instead of this issue.

pogobanane on Apr 13, 2023

I have this issue on both macOS and Linux, in which the %r never gets extended. A quick look at the code of the home-manager module gave me the impression that maybe the path extension is not even implemented? It’s true that in systemd scripts %r gets extended by systemd, but I feel like the documentation at the current time give an impression that it would be the sops-module which does that. By the result of that, getting the folder path in anywhere else becomes a bit tricky task.

My example, on darwin: I try to encrypt Wireguard configurations. My sops has an explicitly declared path. If I do not set this path (as it’s done in README) the symlink is recursive under the secrets folder and cannot be read. After giving it a custom name, the %r becomes a literal word when using the .path property, for which I have to explicitly use (getconf DARWIN_USER_TEMP_DIR)${sops.secrets."wireguard/ponkila.conf".name} to get a working path name for the secret to be usable. And this a special case in which it works, because the activation of wireguard is interactive hence has shell environment support, but the same does not work for git (the path is a literal %r/git/sendmail) and I do not know how should I implement it. Honestly, it seems like an unsupported use-case.

If it’s true that the path extension only works for systemd and launchctl scripts, should this be explicitly stated in the README?

jhvst on Apr 13, 2023

Are all of us having the issue on macOS?

duckpuppy on Apr 12, 2023

cc @pogobanane

Mic92 on Mar 10, 2023