sops: 3.7.2 - error loading config: no matching creation rules found

Yes, it’s because of this: https://github.com/mozilla/sops/pull/853

You need to change the path regex to be the relative path of the config file. For example:

• The file you want to match is in ~/a/b/encrypted/secret.file
• Your .sops.yaml is in ~/a/.sops.yaml Then you need to have your creation_rules.path or creation_rules.path_regex to be b/encrypted/secret.file instead of the full path ~/a/b/encrypted/secret.file. I don’t know what is the reason of this change because I got that same error too and after modifying my config file it’s working again.

It should also be noted that ./b/encrypted/secret.file (a very common syntax for relative paths) ALSO exhibits the failing behavior.

Manually reverting the version to 3.7.1 per @rayterrill 's comment resolved the behavior. Appreciate the workaround.

The reason why I sent that PR is because parent directories with the same name as the intended subdirectory for the match were matched. Example:

Path regex: foo/* Sops file: /path/to/project/foo/.sops.yaml This should be included: /path/to/project/foo/foo/* This should not be included: /path/to/project/foo

That’s why it made sense for me, and it was accepted for merge, to consider matching the regex to paths relative to the location of the sops configuration file.

It’s weird to me to have sops alter a file in an upper level or disjoint branch of the file hierarchy. But I also understand the frustration of an unexpected breakage, which I didn’t antecipate.

To be clear - that’s a bit of a fluke, and obviously not the intended regex match… 😂
But it was definitely functioning before the update. I doubt we’re the only ones running into this edge case - let alone the broader implication of the change in general which makes assumptions about the path structure.

Looking at the PR diff I tossed together a toy example in go playground to compare the “old” method (no path trimming) and the new method (trim to a relative path).

It definitely looks like Go’s regexp package fires a match for regex string ./folder/secret.file against a full path like /home/user/some-app/folder/secret.file - but not against a path trimmed relative path like folder/secret.file.

Yes, it’s because of this: #853

You need to change the path regex to be the relative path of the config file. For example:

* The file you want to match is in `~/a/b/encrypted/secret.file`

* Your `.sops.yaml` is in `~/a/.sops.yaml`
  Then you need to have your `creation_rules.path` or `creation_rules.path_regex` to be `b/encrypted/secret.file` instead of the full path `~/a/b/encrypted/secret.file`. I don't know what is the reason of this change because I got that same error too and after modifying my config file it's working again.

That is a breaking change… I have also reverted to 3.7.1 in order to be able to work, and have instructed my team to avoid future updates of SOPS until we confirm this is fixed. Since this breaking change is intentional, it probably should not be a patch release… We have many people using SOPS across many repositories, some of which are customer-owned, and it is highly irregular to insist that everyone upgrade their configuration and update all of the repositories for a non-major version change.

For now we’re reverting users running into the problem:

#!/bin/bash

curl -L https://github.com/mozilla/sops/releases/download/v3.7.1/sops-v3.7.1.darwin -o sops --silent
chmod +x sops
sudo mv sops /usr/local/bin/sops