You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The situation was the following: I added a new secret to a nixos configuration with the sops.secret."some/key" option and the path some/key existed in the secret file but was not encrypted for that machine. When deploying the configuration all secrets where missing, not just the one that failed to decrypt. I think it would be better if sops in such cases would decrypt and create all secrets it can and ignoring the ones it cannot. Or maybe it would be possible to detect this already at build time similar to when the path of a secret does not match.
The text was updated successfully, but these errors were encountered:
There is a validateSopsFiles option that is true by default and checks if the key is present in the sops, but we cannot check if machine has the right private key to decrypt at build time.
I know that behaviour and we haven't changed that.
Also it is obvious that at build time we cannot decrypt the secret but at install time would it be possible to skip the secrets which cannot be decrypted instead of not creating any secrets at all?
The situation was the following: I added a new secret to a nixos configuration with the
sops.secret."some/key"
option and the pathsome/key
existed in the secret file but was not encrypted for that machine. When deploying the configuration all secrets where missing, not just the one that failed to decrypt. I think it would be better if sops in such cases would decrypt and create all secrets it can and ignoring the ones it cannot. Or maybe it would be possible to detect this already at build time similar to when the path of a secret does not match.The text was updated successfully, but these errors were encountered: