-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand ~ and ~user in secrets.providers #215
base: master
Are you sure you want to change the base?
Conversation
if git config --global --get-regex --type path "^secrets\.providers$"; then RESULT=0; fi | ||
if git config --global --get-regex "^secrets\.patterns$"; then RESULT=0; fi | ||
if git config --global --get-regex "^secrets\.allowed$"; then RESULT=0; fi | ||
[ $RESULT -eq 0 ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old regex was overly broad and should have been at least ^secrets\..*
to begin with.
--type path
should only be applied to providers, so they have to be broken out here. That means explicitly enumerating the settings keys. Because the tests (and plausible real world use cases) expect --list
's exit code to reflect whether any settings were found I had to accumulate a result along the way, and this was the most concise way that I was comfortable with.
f493691
to
ce45cc2
Compare
ce45cc2
to
193a2bd
Compare
Description of changes:
By adding
--type path
when retrieving the list of providers, provider paths starting with ~ or ~user will undergo expansion. This allows referring to paths relative to the home directory of the current user or a specific user.My use case for ~ is to put a provider script under my home directory and refer to it from config.providers without having to hard-code my username in my dotfiles.
There is a technically possible but completely implausible regression mode for this PR: Someone has a provider defined starting with "~" which they expect to resolve to a directory with a literal "~" leading its name, located in the cwd(s) from which they call git-secrets. That provider path would fail to resolve after this change.
--path
would accomplish the same goal, with more backwards compatibility for older git versions, but less forward compatibility if that deprecated option is ever removed.Also fixes #159
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.