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
When using sops filestatus <filename> the response is either {"encrypted":true} or {"encrypted":false}.
There is no indication as to whether or not it would have an encryption applied or not based on creation_rules defined in .sops.yaml.
If the file is not encrypted and it doesn't match any of the creation_rules then filestatus should return either an empty response {} or some other flag, e.g. {"ignored":true}.
This would make linting extremely easy and not require an external function trying to emulate the sops logic.
The text was updated successfully, but these errors were encountered:
If the file is not encrypted, encrypted should always be false. Not returning that would be a breaking change. Adding additional information based on .sops.yaml would be possible, but not emitting encrypted is not acceptable.
Agreed, a breaking change would be bad, then something like {"encrypted":false,"ignored":true} or {"encrypted":false,"encryption_required":false} would be a possible solution.
red-lichtie
changed the title
sops filestatus should return an empty JSON when creation_rules do not apply
sops filestatus should return an different JSON when creation_rules do not apply
Feb 15, 2025
When using
sops filestatus <filename>
the response is either{"encrypted":true}
or{"encrypted":false}
.There is no indication as to whether or not it would have an encryption applied or not based on
creation_rules
defined in.sops.yaml
.If the file is not encrypted and it doesn't match any of the
creation_rules
thenfilestatus
should return either an empty response{}
or some other flag, e.g.{"ignored":true}
.This would make linting extremely easy and not require an external function trying to emulate the sops logic.
The text was updated successfully, but these errors were encountered: