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
$ sops -e foo/hello.yaml
config file not found and no keys provided through command line options
Creating an encrypted file interactively fails.
$ sops foo/goodbye.yaml
config file not found and no keys provided through command line options
Encrypting the file from within foo works.
$ cd foo
$ sops -e hello.yaml > hello.enc.yaml
Creating a new encrypted file from within foo works.
$ cd foo
$ sops goodbye.yaml
Decrypting the encrypted file... works!
$ sops -d foo/hello.enc.yaml
That is, the behaviour of 5 is inconsistent with 1 and 2. For decryption, sops appears to walk from the file towards the root in search of configuration; for encryption, it doesn't.
Is this the intended design or is the inconsistency a minor mistake?
The text was updated successfully, but these errors were encountered:
I've also noticed a secondary issue of consistency. (This one I think is more unambiguously a bug.)
Decrypting a file that doesn't exist leads to a reasonable error message.
$ sops -d foo/farewell.enc.yaml
Error: cannot operate on non-existent file
Attempting to modify a file that doesn't exist leads to a spurious error message.
$ sops --in-place foo/farewell.enc.yaml
config file not found and no keys provided through command line options
(The error message for 7 caught me out earlier today...)
adamroyjones
changed the title
Inconsistent behaviour when the sops configuration file isn't in (a parent of) current working directory
Inconsistent behaviour when the sops configuration file isn't in (a parent of) the current working directory
Jun 9, 2023
The below is with sops 3.7.3 on Debian 12 on x86 (installed using the deb provided on the releases page).
Take a folder structure as follows
where .sops.yaml contains (trivial) GCP KMS creation rules, e.g.
and hello.yaml contains
Note the following.
That is, the behaviour of 5 is inconsistent with 1 and 2. For decryption, sops appears to walk from the file towards the root in search of configuration; for encryption, it doesn't.
Is this the intended design or is the inconsistency a minor mistake?
The text was updated successfully, but these errors were encountered: