Open Kreyren opened 5 months ago
The problem here is that agenix
doesn't decrypt at build time, but at activation time, and it doesn't need any keys for a typical configuration to successfully build. It is impossible to make the attribute return false and use the or
keyword in this case. To make things worse, secrets are decrypted quite early in a typical use case like nixos boot, so there's not much that can probably be done. Perhaps log failures somewhere and, when system activation ends, mail the log somewhere. OTOH not every use case is typical and sometimes probably such an option would make a bigger difference (EDIT: having thought about this some more, I now believe that, apart from a custom notification, nothing more should be done, and especially not substituting a failed decryption with some "default").
The problem here is that
agenix
doesn't decrypt at build time, but at activation time, and it doesn't need any keys for a typical configuration to successfully build. It is impossible to make the attribute return false and use theor
keyword in this case. To make things worse, secrets are decrypted quite early in a typical use case like nixos boot, so there's not much that can probably be done. Perhaps log failures somewhere and, when system activation ends, mail the log somewhere. OTOH not every use case is typical and sometimes probably such an option would make a bigger difference. -- @jacekszymanski (https://github.com/ryantm/agenix/issues/262#issuecomment-2173222595)
Can't that be managed by making agenix to generate a service that checks if the file was decrypted in the agenix directory and if not to place an alternative file on it's place?
It would technically be possible to make agenix
put some "ersatz" in case of a failed decryption, but it would be anything from merely pointless to outright dangerous: if you can use this "ersatz" file without encryption then just do it, and you don't need agenix
; and if you can't, you also don't want to do this at all, it could e.g. start a service with credentials stored in the world-readable Nix store. So while it could be done, it also most definitely shouldn't.
I think that the most that can be done without defeating the very purpose of agenix
is store attribute names/paths of failed decryption attempts and then, after the activation, somehow notify the operator that these attempts failed. But this last step should probably be done outside of agenix
as this notification might, depending on the concrete use case, be an e-mail, desktop alert, IM message or anything one can imagine.
NB, if you don't care about the secret being accessible in the Nix store, but just don't want to publish it to GitHub or similar, then you don't want agenix
, but git-agecrypt
; with that you could also check, at build time, whether the secret had been decrypted, and if not, fail the build.
A lot of repositories state caution alike:
from https://github.com/NotAShelf/nyx?tab=readme-ov-file#disclaimer
As currently (r)agenix will just silently fail which results in a blank data parsed to the option.
This complicates some usecases:
As e.g. with
disko
you currently need to make a script to decrypt all relevant secrets and then parse them todisko
to make an image (https://github.com/nix-community/disko/blob/master/docs/disko-images.md) that then you can load in e.g. QEMU.Proposal
Make the attribute to return
false
when e.g.config.age.secrets.<name>.path
is called that (r)agenix is unable to decrypt so that theor
operator can be used to supply an alternative secret:Alternatively adding an attribute to
age.secrets.<name>
with an option to declare a fail condition that will trigger in case (r)agenix is unable to decrypt the secret: