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).
This fixes https://github.com/Mic92/sops-nix/issues/653.
Note: `main.go` has been slowly accumulating shared logic between vanilla
"secrets" and "templates". It feels to me like we could DRY up some of
the logic in here by creating some shared "interface" that they both
implement. I opted not to try to tackle that here, though.
I've reworked the test to assert on the entire output. This allows us to
detect unexpected output without having to write weird "i expect this
random string to *not* show up assertions", which aren't great at
preventing regressions.
I did have to change the code under test a little bit to make it
behavior deterministically (by sorting the files it outputs).
tl;dr: this demonstrates <https://github.com/Mic92/sops-nix/issues/652>
but does not fix it. I will fix it in a subsequent commit.
We import ssh keys by default if openssh is enabled.
However if users are using age keys while using sops to deploy ssh keys we have
a catch-22.
While users could use lib.mkForce to empty the list, this is not intuitive
When you have a follow in your flake inputs, sops-install-secrets is
rebuild everytime the flake.lock changes despite that being a noop. When
filtering src this can be avoided.
In later versions of macOS (e.g. Ventura), the command used to get a
runtime directory (e.g. `getconf DARWIN_USER_TEMP_DIR`) returns a
trailing slash.
When using a configuration like:
```
sops.defaultSecretsMountPoint = "%r/secrets.d";
```
The final path is going to contain a double slash in the suffix of the
path, an example:
```
/var/<random>/<hash>//secrets.d
```
This commit ensures that the runtime dir will get the trailing '/'
character removed.
On the latest version of macOS (Ventura 13.4 as of this date), this
change ownership will always fail with the error:
> Failed to mount filesystem for secrets: Cannot change owner/group of '.../secrets.d' to 0/0: chown .../secrets.d: operation not permitted
