This avoids re-initializing the Flake object deep in the tree, which in turn leads to issue when overriding the Flake for testing, eg the URl would reset.
Extends how we parse the contents of `SOPS_AGE_KEY` / `SOPS_AGE_KEY_FILE` / `keys.txt`, allowing a user to prepend a comment before any `AGE-PLUGIN-` secret key entry to indicate its corresponding public key.
For example:
```
AGE-PLUGIN-FIDO2-HMAC-xxxxxxxxxxxxx
```
The comment can use any prefix (e.g. `# public key: age1xxxx`, `# recipient: age1xxx`) as we are looking directly for `age1xxxx` within the line.
This change is necessary to support `age` plugins as there is no unified mechanism to recover the public key from a plugin's secret key.
If a plugin secret key does not have a preceding public key comment, an error will be thrown when attempting to set a secret.
... instead of loading both keys and raise an error
This is important for testing when one wants to override SOPS_AGE_KEY_FILE
New prio: `SOPS_AGE_KEY` > `SOPS_AGE_KEY_FILE` > `~/.config/sops/age/keys.txt`
When a machine is deleted with `clan machines delete`, remove its
vars and legacy secrets, and update any secrets that reference the
machine's key.
This command is a superset of `clan secrets machine delete`, and I am
wondering if we could remove the `clan secrets machine` subcommand,
unless there is an use case for having a machine defined without its
key, and any secrets/vars?
Note:
- This deletes the `ListSecretsOptions` dataclass, as it did not seem to
bring any value, especially since `list_secrets` was receiving its
individual members instead of the whole dataclass. We can always bring
it back if complexity grows to demand it.
Quick follow up to PR #2781, this commit does the same kind of logic but
for machines instead of users and groups.
Note that this only affects the `clan secrets machines remove`
sub-command, and that `clan machines delete` still leaves unusable
secrets & vars behind. This can be addressed in a different change.
We need to remove all keys that were in the group from affected secrets.
With this change we now take `group_name` as an argument in
`{add,remove}_member`, which is a little bit more readable than
`group_folder.parent.name`, and helps DRY the code a bit.
