Behavior of path_regex changed in patch release and broke some usecases

Since release 3.3.1 (mozilla/sops#478) path regexes check against the full path as implemented in PR mozilla/sops#466 (issue mozilla/sops#465). This solved the usecase mentioned in the issue but broke another one.

Consider this config (taken from mozilla/sops#466):

creation_rules:
    - path_regex: .*/development/.*
      kms: '…'

    - path_regex: .*/production/.*
      kms: '…'

    - kms: '…'

If the repo that contains the secrets is located under a path like /home/user/development/secrets/, the first rule will always match. I have no control over the location where other developers store their repos.

We tried to prevent this by using ^(./)?development/.+\.yaml as a path_regex and calling sops always from the project root, but this no longer works with sops 3.3.1 and fails with error loading config: no matching creation rules found. It even fails for existing encrypted files, despite the irrelevance of creation rules for them.

Possible solution

Instead of simply converting the path passed to sops to an absolute path, the absolute path should be made relative to the config file (if one exists).

This should support both the use case from mozilla/sops#465 and ours.