Look for .sops.yaml relative to target

[mrgleeco]

file under use-ability:

this may be rtfm fail on my behalf, but i thought the path checking would find my .sops.yaml config in heirarchy to the target. This assumption explained:

the release: 2.0.10

the setup:

mkdir -p foo/bar/baz/
cp $sops_config_file foo/bar/.sops.yaml
sops foo/bar/baz/secrets.yaml

In this scenario, editor proceeds, but saving it carps:

No master keys were provided, so sops can't encrypt the file.
Press a key to return to the editor, or Ctrl+C to exit.

Should it not find the .sops.yaml starting from the target file's path?

looking closer with strace:

stat("foo/bar/baz/secrets.yaml", 0xc42015eed8) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "foo/bar/baz/secrets.yaml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat(".sops.yaml", 0xc42015efa8)        = -1 ENOENT (No such file or directory)
stat("../.sops.yaml", 0xc42015f078)     = -1 ENOENT (No such file or directory)
stat("../../.sops.yaml", 0xc42015f148)  = -1 ENOENT (No such file or directory)
stat("../../../.sops.yaml", 0xc42015f218) = -1 ENOENT (No such file or directory)
stat("../../../../.sops.yaml", 0xc42015f2e8) = -1 ENOENT (No such file or directory)
stat("../../../../../.sops.yaml", 0xc42015f3b8) = -1 ENOENT (No such file or directory)
stat("../../../../../../.sops.yaml", 0xc42015f488) = -1 ENOENT (No such file or directory)
stat("../../../../../../../.sops.yaml", 0xc42015f558) = -1 ENOENT (No such file or directory)
stat("../../../../../../../../.sops.yaml", 0xc42015f628) = -1 ENOENT (No such file or directory)
[pattern repeats (up to maxDepth afaict) ]

indeed it is going up from my PWD.

Of course this does work fine if i specify location; eg. sops --config foo/bar/.sops.yaml foo/bar/baz/secrets.yaml. But it does put the burden on the editor to a) know where the config is and .b) be in the target file's dir.

[autrilla]

SOPS looks for the config file from the current working directory. Commit 597acb7 changed this for the Go version, the Python version does this too. However, the docs are not very clear at explaining this.

[mrgleeco]

thx - that is interesting! What was the motivation? Not clear from the commit.

from the peanut gallery, a +1 for an 'ascending from target' M.O; In various repos where this might be used, it's typical to be rooted in the root directory.

[autrilla]

This was the behavior of the Python version, and the Go version wants to keep compatibility with the Python version, so the commit I mentioned was basically fixing a bug. As to why the Python version uses cwd instead of the file's path, I do not know.

[jvehent]

It's a bit tricky to design. You may want to encrypt a file located under /tmp/foo.key while being placed inside your secrets directory, and .sops.yaml would be picked up correctly. If we change that, add support for both, and 2 config exists for cwd and file directory, which one should take precedence?

…

On Aug 30, 2017 01:28, "Adrian Utrilla" ***@***.***> wrote: This was the behavior of the Python version, and the Go version wants to keep compatibility with the Python version, so the commit I mentioned was basically fixing a bug. As to why the Python version uses cwd instead of the file's path, I do not know. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#242 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZXgU72hWROa-3R3sc0NG-5ETTGaGRGks5sdPL1gaJpZM4PGrBk> .

[s-spindler]

I'm interested in this as it would allow me to structure my repo in a way where different .sops.yaml config files could be used for different directories. At the moment I have to use one config file at the root of the directory that grows quite larg. Not terrible but could be nicer 😉

What is the status of this? Can it be worked on?
@jvehent From your comment I'm not sure if you are ok with the behavior being changed to "ascend from secret file location" or if you want some kind of combined behavior...

[jvehent]

I don't think we can make any change to the current behavior until we have a reasonable approach to deciding which configuration file would take precedence when two configs exists in cwd and
file directory. I think the current approach, while limiting, has the benefit of being clearly understood and footgun-proof, which are important properties of any security tool.

[jpluscplusm]

A modest suggestion, so as not to break existing workflows but to allow adoption of the (IMHO!) clearly better (;-)) choice over time:

• search both hierarchies: CWD-and-up, and file-dir-and-up
• if only CWD-and-up is found, use that
• if only file-dir-and-up is found, use that
• if both are found, prefer the CWD-and-up unless an explicit marker has been placed in that file deferring to file-dir-and-up if present

This way, an existing user preserves behaviour as is; a new user wanting file-dir-and-up gets it as they have no clash; and an existing user can transition as they choose, requiring both a file-dir-and-up config file and an opt-in in their CWD-and-up file.

[Enva2712]

Here's a shell script to do the file-centric resolution in userland. You can use it like sops --config "$(sopsconfig path/to/file.yaml)" path/to/file.yaml

function sopsconfig() {
	CONFIG_DIR="$(dirname "$(realpath "$1")")"
	while [ ! -f "$CONFIG_DIR/.sops.yaml" ]; do
		if [ "$CONFIG_DIR" = "/" ]; then exit 1; fi
		CONFIG_DIR="$(dirname "$CONFIG_DIR")"
	done

	echo "$CONFIG_DIR/.sops.yaml"
}