Symlinks not getting cleaned when removed from the config with Home-Manager

[AdrienCos]

Hi ! Thanks a lot for this awesome project :)

Issue

I am currently setting up my secrets with sops-nix in my personal config, starting with Home-Manager, and using flakes, and I've ran into an issue when changing the sops.secrets.<secret>.path value:

• If I change the value to rename the symlink, the new symlink is properly created, but the old one is not cleaned up, and still points to the valid secret file
• If I remove the .path option from the secret but keep everything else the same, nothing changes on my system, the symlink is still there and points to the valid decrypted secret
• If I remove the config for the whole secret, again nothing changes: the symlink is still there, the secret still exists

Is this expected behavior, or is there some config that I may have missed somewhere ? Or is it a bug ?

Configuration excerpt :

The section of my flake that defines my HM config:

my-machine = home-manager.lib.homeManagerConfiguration {
        pkgs = nixpkgs.legacyPackages.x86_64-linux;
        modules = [
          ./home.nix
          ./hosts/my-machine/home.nix # HM-specific host configuration
          catppuccin.homeManagerModules.catppuccin
          ./home-manager-modules
          ./modules
          sops-nix.homeManagerModules.sops
        ];
        extraSpecialArgs = {
          pkgs-unstable = nixpkgs-unstable.legacyPackages.x86_64-linux;
          pkgs-catppuccin-toolbox = inputs.catppuccin-toolbox.packages.x86_64-linux;
          hostname = host;
          inherit
            inputs
            ;
        };
      };

The sops-nix config inside my home.nix:

sops = {
  age.keyFile = "${config.home.homeDirectory}/.age/adrien_cosson.key";
  secrets.canary = {
    sopsFile = ./secrets/secrets.yaml;
    path = "${config.home.homeDirectory}/.sops_canary";
  };
};

Misc. Ideas

I have noticed an option named sops.keepGenerations that should apparently be in charge of doing some cleanup of old generations. eval-ing its value in my config returns me 1 (as expected, because I do not set it anywhere, and it's the default value). However, the fact that my secrets remain in place and decrypted after multiple HM generations makes me think that there is a bug somewhere.

Additional information:

• System: WSL on Windows 10
• OS: Ubuntu 24.04
• Home-Manager version : 24.05

[robert-baldwin]

I'm trying this out for the first time today as well. I noticed that even when removing sops-nix completely from my flake and rebuilding my system that I still have a /run/secrets directory symlinked to the directory containing my secrets which remain readable.

[jfly]

For the record, the issue @AdrienCos describes above is not a home-manager specific issue. It's just a bug with sops-nix. Here's where these symlinks outside of /run/secrets are created:

sops-nix/pkgs/sops-install-secrets/main.go

Line 224 in c5ae1e2

if err := symlinkSecret(targetFile, &secrets[i], userMode); err != nil {

. There is no corresponding cleanup code in sops nix. Fixing this would require reworking symlinkSecrets to also delete now-unnecessary symlinks, which with the current architecture of sops-nix, I believe is impossible to do (short of scanning the entire filesystem for symlinks to files in /run/secrets/).

To fix this, I'd suggest that sops-nix maintain a list of "external symlinks" into /run/secrets (since sops-nix is the one that creates these, it can totally maintain a list of them). As part of activation, we attempt to remove any broken symlinks. If they don't exist, that's fine. If we can't remove them, that's an error. (This would behave sort of like nix's own gcroots mechanism).

I have noticed an option named sops.keepGenerations that should apparently be in charge of doing some cleanup of old generations

For the record, this setting is about garbage collection of the various "secret generation folders" ( /run/secrets.d/1, /run/secrets.d/2, etc). That system works, and isn't relevant for the issue described here.

I noticed that even when removing sops-nix completely from my flake and rebuilding my system that I still have a /run/secrets directory symlinked to the directory containing my secrets which remain readable.

@robert-baldwin, this is a different issue, and I'm not sure it's a solvable one: sops-nix's only mechanism for cleaning things up is to add stuff to system activation. If you remove sops-nix entirely, there's no way it could possibly clean itself up. Perhaps this suggests we're missing some documentation about how to remove sops-nix. I'd suggest you file a separate issue for that, though.