mirror of
https://github.com/Mic92/sops-nix.git
synced 2024-12-14 11:57:52 +00:00
eee831aadb
This fixes https://github.com/Mic92/sops-nix/issues/659 In https://github.com/Mic92/sops-nix/pull/649, we started rendering templates twice: 1. When rendering `neededForUsers` secrets (if there are any `neededForUsers` secrets). 2. When decrypting "regular" secrets. This alone was weird and wrong, but didn't cause issues for people until https://github.com/Mic92/sops-nix/pull/655, which triggered https://github.com/Mic92/sops-nix/issues/659. The cause is not super obvious: 1. When rendering `neededForUsers` secrets, we'd generate templates in `/run/secrets-for-users/rendered`. 2. However, the `path` for these templates is in `/run/secrets/rendered`, which is not inside of the `/run/secrets-for-users` directory we're dealing with, so we'd generate a symlink from `/run/secrets/rendered/<foo>` to `/run/secrets-for-users/rendered/<foo>`, which required making the parent directory of the symlink (`/run/secrets/rendered/`). 3. This breaks sops-nix's assumption that `/run/secrets` either doesn't exist, or is a symlink, and you get the symptoms described in <https://github.com/Mic92/sops-nix/issues/659>. Reproducing this in a test was straightforward: just expand our existing template test to also have a `neededForUsers` secret. Fixing this was also straightforward: don't render templates during the `neededForUsers` phase (if we want to add support for `neededForUsers` templates in the future, that would be straightforward to do, but I opted not do that here). |
||
|---|---|---|
| .. | ||
| home-manager | ||
| nix-darwin | ||
| sops | ||