Unclear usage of `--filename` option in `exec-file`

[5p4k]

I was expecting --filename to be able to set the exact file name where sops decrypts the original file; however, I noticed that instead it uses that as an argument to generate the temporary file name. Example:

sops exec-file --filename test.yml file.sops.yml "echo file is at {}"
file is at /tmp/.sops1007086337/test.yml

I would have expected something like

sops exec-file --filename test.yml file.sops.yml "echo file is at {}"
file is at test.yml

or even an error, since I'm passing the filename, the interpolation of {} could even be disabled.

I wonder whether this is intended? And what could be the usage case of the --filename option, if the file name is still a randomly generated temp.

---

For context, I am trying to decrypt simultaneously a yaml file and an envfile, which are both needed for deploying a docker stack. I need to fix the file location because that is picked up as a docker secret.

This in particular implies that I need to nest an exec-env and an exec-file command, which generates a rather ugly command line (in fact, I have not managed to convince bash to escape that correctly yet); something like multiple files decryption would really be useful here.

[pdfrod]

I think the use case for that flag is explained here: some tools (like Terraform) expect the secrets file to have a specific file extension, so the --filename allows us to make sure the generated file has the right extension.

Although, it would be nice if the --filename allowed to specify the exact path where we'd like the file to be mounted, as some tools are hard to work with when the file is not in a fixed path.

[felixfontein]

For your original use-case, why not simply use --decrypt to decrypt the files you need, then run what you need on them, and finally clean up later? (If it's a shell script, you can use traps to make sure the cleanup happens - as sure as you can be, since programs can always get killed before they can do their cleanup.)

[5p4k]

@felixfontein that's indeed the approach we used to work around the limitation. It's a bit delicate, however, because each stack with this env+file requirements needs its script, or a convention to decide where the decrypted file needs to be mapped. Sops on the other hand, has already 90% of this functionality already builtin. It would be nice to have the ability to specify a path too.