sops.secrets.<name>.path not working properly in the home-manager module

[johnhampton]

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?

[Mic92]

cc @pogobanane

[pogobanane]

For me secrets/ links to secrets.d/1/.

I can't reproduce your issue @johnhampton. Can you send your manifest.json please? Find your current one in less ~/Library/LaunchAgents/org.nix-community.home.sops-nix.plist which points to some less /nix/store/*-sops-nix-user which points to the manifest /nix/store/*-manifest.json

[MaxDaten]

Got the same problem with:

home.nix (called from a flake)

    imports = [
      inputs.sops-nix.homeManagerModule
    ];
#...
    sops = {
      defaultSopsFile = ../../secrets/main.yaml;
      age.sshKeyPaths = ["${config.home.homeDirectory}/.ssh/id_ed25519"];
      age.keyFile = "${config.home.homeDirectory}/.config/sops/age/keys.txt";
      age.generateKey = true;

      secrets.OPENAI_API_KEY = {
        path = "${config.home.homeDirectory}/.config/openai/OPENAI_API_KEY";
      };
    };

and my manifest.json

{
  "ageKeyFile": "/Users/me/.config/sops/age/keys.txt",
  "ageSshKeyPaths": [
    "/Users/me/.ssh/id_ed25519"
  ],
  "gnupgHome": null,
  "keepGenerations": 1,
  "logging": {
    "keyImport": true,
    "secretChanges": true
  },
  "secrets": [
    {
      "format": "yaml",
      "key": "OPENAI_API_KEY",
      "mode": "0400",
      "name": "OPENAI_API_KEY",
      "path": "/Users/me/.config/openai/OPENAI_API_KEY",
      "sopsFile": "/nix/store/l37i5ir4c9vgsa0iicgc2ifanscmv5q4-main.yaml"
    }
  ],
  "secretsMountPoint": "%r/secrets.d",
  "sshKeyPaths": [],
  "symlinkPath": "%r/secrets",
  "userMode": true
}

[duckpuppy]

Same for me, except that %r/secrets isn't created, and there's no secrets in %r/secrets.d - the only file there is sops-nix-secretfs.

manifest.json:

{
  "ageKeyFile": null,
  "ageSshKeyPaths": [],
  "gnupgHome": ".git/gnupg",
  "keepGenerations": 1,
  "logging": {
    "keyImport": true,
    "secretChanges": true
  },
  "secrets": [
    {
      "format": "yaml",
      "key": "ssh/matches/home",
      "mode": "0400",
      "name": "ssh/matches/home",
      "path": "/Users/<me>/.ssh/includes/home",
      "sopsFile": "/nix/store/64y4vidzmm08b5rz33y8vfjg80chxv2k-secrets.yaml"
    }
  ],
  "secretsMountPoint": "%r/secrets.d",
  "sshKeyPaths": [],
  "symlinkPath": "%r/secrets",
  "userMode": true
}

[duckpuppy]

Are all of us having the issue on macOS?

[jhvst]

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?

[pogobanane]

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

[pogobanane]

@duckpuppy if you make sure sops-install-secrets run again (for example home-manager swtich and reboot) do the secrets*/ contents appear again? If so, the files might have been garbage collected by macos tmpfile manaement due to inactivity.

[duckpuppy]

The files never exist, even immediately after a switch/reboot.

On Thu, Apr 13, 2023, 3:04 PM pogobanane @.***> wrote:

@duckpuppy https://github.com/duckpuppy if you make sure sops-install-secrets run again (for example home-manager swtich and reboot) do the secrets*/ contents appear again? If so, the files might have been garbage collected by macos tmpfile manaement due to inactivity.

— Reply to this email directly, view it on GitHub https://github.com/Mic92/sops-nix/issues/287#issuecomment-1507477317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEWNLSAXE4JRBP3A2BRULXBBE47ANCNFSM6AAAAAAVQMUF7U . You are receiving this because you were mentioned.Message ID: @.***>

[G3zz]

Try running the launchctl service manually and viewing the logs

[WolfangAukang]

I can confirm I have the same issue. Checking sops-nix.service, I see it fails when I try to start it (this on NixOS).

Try running the launchctl service manually and viewing the logs

Running journalctl --user -xeu sops-nix.service gives me No entries.

UPDATE: I was previously using sops.gnupg.home. I used an age key, referenced it through sops.age.keyFile and it worked. My doubt is how can I use it with the sops.gnupg option.

[duckpuppy]

Just revisiting sops-nix - I still have the issue.

This is the plist file I have:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<dict>
		<key>Crashed</key>
		<false/>
		<key>SuccessfulExit</key>
		<false/>
	</dict>
	<key>Label</key>
	<string>org.nix-community.home.sops-nix</string>
	<key>ProcessType</key>
	<string>Background</string>
	<key>ProgramArguments</key>
	<array>
		<string>/nix/store/9hh47ajggyadd73kzbpxqr73bk0i3d2l-sops-nix-user</string>
	</array>
	<key>StandardErrorPath</key>
	<string>/Users/paikens/Library/Logs/SopsNix/stderr</string>
	<key>StandardOutPath</key>
	<string>/Users/paikens/Library/Logs/SopsNix/stdout</string>
</dict>
</plist>

If I look in /nix/store/9hh47ajggyadd73kzbpxqr73bk0i3d2l-sops-nix-user I find this command: /nix/store/n0x7kfpg68jwhz8nyy4pvpfzr66sj6yh-sops-install-secrets-0.0.1/bin/sops-install-secrets -ignore-passwd '/nix/store/yx0hcnnb7ysfavsfbhc08ywn4pyib970-manifest.json'

Running that directly actually creates the secrets properly! However, I still don't get symlinks in the path location when actually activating the configuration.

[Pizmovc]

Just to add another data point, for me the secret file was there from before, it just did not update its contents when I changed them in sops and did a switch. Manually starting the sops-nix.service did update the file (systemctl --user start sops-nix.service).

Looking at the logs of the service, I don't see anything suspicious other than the fact that it did not get run when I did a switch.

Using NixOS with flakes and home-manager integrated. sops-nix is pinned to rev 4ccdfb573f323a108a44c13bb7730e42baf962a9 in my flake.lock file.

[pogobanane]

note to self: https://github.com/Mic92/sops-nix/commit/98834d958bee6bb6c98637927f8fa679c771b550#r119147619

[Janik-Haag]

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 :/

[aur3l14no]

@Janik-Haag Same here. Have you got it resolved?

UPD: Solved by https://github.com/Mic92/sops-nix/issues/284

[Janik-Haag]

I just set the path to path = "$XDG_RUNTIME_DIR/secrets/mySecret; as workaround

[gbtb]

I use sops-nix.nixosModules.sops in conjuction with nixos-anywhere flake, and path option doesn't work for me at all.

[Janik-Haag]

I use sops-nix.nixosModules.sops in conjuction with nixos-anywhere flake, and path option doesn't work for me at all.

this seems unrelated to the home-manager issue. How are you decrypting stuff after the nixos-anywhere install? You have to have a valid ssh/age/gpg key in your .sops.yaml

[ylbeethoven]

Same issue here on Darwin using home manager module -> no secret is created.

The same config works fine on Linux.

[YaroKasear]

Having this issue with sops on home-manager. Restarting the sops-nix service doesn't work for me. It does decrypt the file as I can find it in /run where expected, but no symlink is made where I told it to be in my config.

[r17x]

@MaxDaten I have similar configuration with you and works.

I'm using MacOS, nix-darwin, and home-manager.

don't forget to reload your SHELL.

[musjj]

I'm also having the same %r not being replaced issue. I had to manually substitute it myself. But at the same time I'm not sure if there's a good, general solution to this.

AFAIK, there's no consistent & reliable method to obtain the current $XDG_RUNTIME_DIR at build time, especially when you consider flake configurations.

@jhvst

It's true that in systemd scripts %r gets extended by systemd

I don't even think it's a systemd thing, it's just a sops-nix-specific thing: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Specifiers (%t seems to be the systemd equivalent)

Here's where it gets parsed:

https://github.com/Mic92/sops-nix/blob/ffed177a9d2c685901781c3c6c9024ae0ffc252b/pkgs/sops-install-secrets/main.go#L878-L889

[SebTM]

Hey, I ran into the same issue when trying to adapt the https://github.com/NixOS/nix/issues/6536#issuecomment-1254858889 solution for using with the home-manager module as I use different keys for home-manager secrets and host-secrets.

%r does not get replaces which causes the include to just be ignored, $XDG_RUNTIME_DIR does not seem to work in "nix.conf" (home-manager via nix.extraOptions)

Is there any possibility to make path stable/quick-fix this for home-manager?

I was thinking about porting the template-system from the nixos-module for home-manager (via a common nix-file(s) if possible) as it would avoid me to define secrets e.g. github-token multiple-times if needed in different formats, but considering this issues this seems to be a requirement before improving/extending the functionality.

Tried different possibilities: without specifying path, with %r manual specified, with $XDG_RUNTIME_DIR

[musjj]

I think a hacky alternative would be to append the secrets to your config with a custom service (which has access to $XDG_RUNTIME_DIR via %t).

You can write out the sensitive parts in your secrets file, then your service can append it to the actual config on run-time, after it is decrypted by sops-nix. The contents of the (original) config can be read from config.xdg.configFile."nix/nix.conf".source.

Be sure to only write to /run to avoid writing the secrets to the disk.

Another potentially easier option: use symlinkJoin and wrapProgram to pass additional options to the nix program. Since the wrapper is just a shell script, you can read $XDG_RUNTIME_DIR.

[SebTM]

Hey, thanks for helping out on this 🙏🏻 I'm not sure I understand the first solution as the ~/.config/nix/nix.conf is a symlink to the nix-store I'm not sure how to append something there and I haven't found a solution to change the path used for the users nix-config.

I wouldn't find it too hacky if I can replace the config on decrypt and reset with explained source-reference on stop/in general as it still leaves the functionality of nix-commands in tact if the whole config is switched because I don't have to rely on include.

Switching out/Rewriting the linked config without switching the location somehow has one big disadvantage (I would assume) that on every rebuild/switch it will be replaced with the default again?

---

Be sure to only write to /run to avoid writing the secrets to the disk. I guess you refer to the actual secret file? How would I do this?

After posting my issue I still tried to search through configs on GitHub maybe someone has already solved it for him and I discovered I can do the following:

secrets.nix_extra-access-tokens = {
    path = "${config.home.homeDirectory}/.config/nix/nix_extra-access-tokens";
};

This way I get a symlink to the secret in /run/user/1000/secrets/nix_extra-access-tokens is that fine/safe?

I assume that only works if you use NixOS and home-manager combined as otherwise since later 20.05 home.homeDirectory is empty by default - I haven't set it in my current config at least.

[musjj]

I'm not sure I understand the first solution as the ~/.config/nix/nix.conf is a symlink to the nix-store I'm not sure how to append something there

You can read the contents of the file in the /nix/store, concat it with your secrets into a file in the /run/user directory, then symlink it to the config directory (overwriting the original). I haven't actually tested this, so I'm not sure if you'd run into any trouble with this method. The wrapper method is probably more straightforward.

and I discovered I can do the following:

AFAIK, this will write the secrets directly to the disk. If you're fine with that, it should work. Otherwise I'd recommend making a service that symlinks it from /run to ~/.config on startup.

Also, it looks like that you can pass config via env, so you can just put something like this to your shell:

export NIX_CONFIG="extra-access-tokens = $(cat $XDG_RUNTIME_DIR/secrets/extra-access-tokens)"

[dminca]

I don't know if it helps, I finally managed to set this thing up for my x86_64-darwin box after 2 weeks; in my case, without specifying a path, the secrets are symlinked to config.xdg.configHome which is ~/.config/sops-nix/secrets

MacOS Sonoma 14.4.1 (23E224)

LE: Just tested sops.secrets.<name>.path and sops.secrets.<name>.owner and the latter throws an error while the former simply does nothing.

I've setup sops-nix in my flake as a sops-nix.homeManagerModules.sops

[Mic92]

We just changed the path to be stored in config.xdg.configHome.

[SebTM]

For me this change also resolves this issue so I invite you to test it out :)