- generate a flake.lock file for each template by copying the clan-core flake.lock and modifying it
- call nix build with --store for tests inside the sandbox
- Move public keys collection to a class method on `SopsKey`, and
implement collection for each key type in `KeyType`, this helps make
the code more generic ;
- Replace `Operation.__call__` by `run` (`sops.run` if you import the
entire module), that allows us to dedent the code so that's cool ;
- Fix exception handling when trying to get a in-memory temporary file ;
- Make Executor cuter 😵🪦.
vars changes in question are from commit: 8b94bc71bc
With this changeset the age specific sops logic that was added is now
generic.
To keep things simple, this changeset modifies `SopsKey` so that
`username` is ignored when comparing different keys. I don't really see
us relying on `username` and this makes `SopsKey` hashable, and usable
in a `set`, which is nice when you check that you have a particular key.
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 adds options `invalidationData` to generators.
`invalidationData` can be used by an author of a generator to signal if a re-generation is required after updating the logic.
Whenever a generator with invalidation data is executed, a hash of that data is stored by the respective public and/or secret backends.
The stored hashes will be checked on future deployments, and a re-generation is triggered whenever a hash doesn't match what's defined in nix.
