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
It makes more sense to import the key when we have one and ignore the
SSH keys instead of only importing the key when we have no SSH keys.
This is because we import all SSH keys by default in the module and
using a key file means the use has to explicitly unset the SSH keys.
This does not significantly decrease security while making it a lot more
convinient. There are also services, where it is not possible to set
the keys group i.e. if a daemon unsets all groups. Processes still
won't be able to list other secrets if they are not in the secret group.
fixes#86
