This forces sops to use our config file, otherwise if any of the
environment variables set to specify recipients is present then
`--config` will be ignored (see [env_check]).
That's simple enough, still I ended up refactoring how we call sops for
correctness, and to align with its behavior. The code now distinguishes
between public and private keys explicitly. `secrets.decrypt_secret`
does not try to lookup for public and private keys anymore.
With this changeset, some people might have to adjust their environment
as public age and PGP keys will be discovered like sops would do. In
particular if multiple public keys are discovered, then the user will
have to specify which one to use for the clan.
This also makes the following changes:
- try to use `/dev/shm` when swapping a secret (it's what [pass] does
fwiw);
- alias immediate values for readability;
- remove some float comparison that could never succeed, and use sops'
exit status instead;
- remove unused function `maybe_get_sops_key`.
[env_check]: 8c567aa8a7/cmd/sops/main.go (L2229)
[pass]: http://passwordstore.org/
This reverts commit 18b64f2d0b.
The old configuration cannot be updated like this:
eve] error:
[eve] … while calling the 'head' builtin
[eve] at /nix/store/5b0hl2dnvr1sawqlkwmsnaiyqz00d34h-source/lib/attrsets.nix:1575:11:
[eve] 1574| || pred here (elemAt values 1) (head values) then
[eve] 1575| head values
[eve] | ^
[eve] 1576| else
[eve]
[eve] … while evaluating the attribute 'value'
[eve] at /nix/store/5b0hl2dnvr1sawqlkwmsnaiyqz00d34h-source/lib/modules.nix:809:9:
[eve] 808| in warnDeprecation opt //
[eve] 809| { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
[eve] | ^
[eve] 810| inherit (res.defsFinal') highestPrio;
[eve]
[eve] … while evaluating the option `system.build.toplevel':
[eve]
[eve] … while evaluating definitions from `/nix/store/5b0hl2dnvr1sawqlkwmsnaiyqz00d34h-source/nixos/modules/system/activation/top-level.nix':
[eve]
[eve] … while evaluating the option `assertions':
[eve]
[eve] … while evaluating definitions from `/nix/store/5b0hl2dnvr1sawqlkwmsnaiyqz00d34h-source/nixos/modules/system/boot/systemd.nix':
[eve]
[eve] … while evaluating the option `systemd.services':
[eve]
[eve] … while evaluating definitions from `/nix/store/kpzcdgndym0qm1w490mjvk9c2qmz03h5-source/nixosModules/clanCore/zerotier':
[eve]
[eve] … while evaluating the option `clan.core.networking.zerotier.networkId':
[eve]
[eve] (stack trace truncated; use '--show-trace' to show the full, detailed trace)
[eve]
[eve] error: A definition for option `clan.core.networking.zerotier.networkId' is not of type `null or string'. Definition values:
[eve] - In `/nix/store/kpzcdgndym0qm1w490mjvk9c2qmz03h5-source/nixosModules/clanCore/networking.nix':
[eve] {
[eve] _type = "override";
[eve] content = "267efd4a15b69623";
[eve] priorit
Add dynamic completion scaffolding to the clan `cli`.
Also add a dynamic completion mechanism for machines for commands that
have machines as their sole argument.
More intricate dynamic completions will be implemented in follow up
PR's.
Add `--regenerate` flag to `clan facts generate` which allows forcing
the generation of facts, regardless of their current existence.
Examples:
```
clan facts generate [MACHINE] --regenerate
```
or
```
clan facts generate [MACHINE] --service [SERVICE] --regenerate
```
Add `--service` flag to the `clan` cli which allows specifying a certain
service to be generated.
Example:
```
clan facts generate [MACHINE] --service [SERVICE]
```
Fixes#1395
