I am not sure to understand what `extract_public_key` was for. It seems
like `age-keygen -y` will just work fine for a file like
`extract_public_key` is looking for. Unless someone intentionally made a
file with a comment like that without the private key in it.
Messages are moved to stdout rather being logged. It feels like the
output is meaningful in the first step users are going to take. Also
makes testing easier, as log messages are captured differently than
stdout. The call to add an user is changed to be easier to copy paste
and work whether PGP or age is in use.
A description for the command is added instead of help which does not
seem to be displayed.
To use a PGP key instead of an age key you can set `SOPS_PGP_FP`. (You
can use `gpg -k --fingerprint --fingerprint` to get your PGP encryption
key fingerprint, remove spaces from it).
The internal manifest file already supported a type field, and so I built
from there.
With those changes, I was able to add my PGP key, and update all my
secrets with it, instead of the age key originally generated:
```
% clan secrets key show | jq
{
"key": "ADB6276965590A096004F6D1E114CBAE8FA29165",
"type": "pgp"
}
% clan secrets key update
% for s in $(clan secrets list) ; do clan secrets users add-secret kal-pgp-from-2022-12-to-2024-12 "$s"; done
% for s in $(clan secrets list) ; do clan secrets users remove-secret --debug kal "$s" ; done
```
- generate keys in ./sops instead of ./sops/vars for now
- don't initialize all flakes with sops keys, only generate when needed
- use the new 'clan vars keygen' in tests
now that we call it "update" hardware configurration and we are heading
towards facter anyway, we don't need all the force overide logic. Just
allow this to be overwritten by default.
When a second machine checks for a shared secret, now the exists() call returns negative and only when updating the secrets for that machine, the machine is added to the sops receivers.
Also throw proper errors when the user switches backends without cleaning the files first.
Migrating generated files from the facts subsystem to the vars subsystem is now possible.
HowTo:
1. declare `clan.core.vars.generators.<generator>.migrateFact = my_service` where `my_service` refers to a service from `clan.core.facts.services`
2. run `clan vers generate your_machine` or `clan machines update your_machine`
Vars will only be migrated for a generator if:
1. The facts service specified via `migrateFact` does exist
2. None of the vars to generate exist yet
3. All public var names exist in the public facts store
4. All secret var names exist in the secret fact store
If the migration is deemed possible, the generator script will not be executed. Instead the files from the public or secret facts store are read and stored into the corresponding vars store
