Skip to content

Conversation

@mjcheetham
Copy link
Contributor

Only erase stored credentials when the user name and password values match those passed on standard input, if any. When no user name and/or password are given on standard input we skip checking the stored value and just erase the credential.

This is an important but possibly subtle behaviour to help prevent erroneous erasure of credentials.

Calls to git-credential fill should immediately be followed by git-credential approve or reject. If there are concurrent processes that have called fill but not yet approve or reject, there's a gap when another (faster) process could have completed the fill+approve combination and have stored a different credential value than what the first process got from fill.

If the first process fails and calls reject the valid credential as approve-ed by the second process would be deleted. This change helps prevent such a scenario (although there is still a small gap inside the GCM erase command itself between reading the OS's credential store and deleting from it - we could look at some system-wide lock around the credential store if this is deemed a problem later).

Fixes #24

Only erase stored credentials when the user name and password values
match those passed on standard input, if any. When no user name and/or
password are given on standard input we skip checking the stored value
and just erase the credential.

This is an important but possibly subtle behaviour to help prevent
erroneous erasure of credentials.

Calls to `git-credential fill` should immediately be followed by
`git-credential approve` or `reject`. If there are concurrent processes
that have called `fill` but not yet `approve` or `reject`, there's a
gap when another (faster) process could have completed the
`fill+approve` combination and have stored a different credential value
than what the first process got from `fill`.

If the first process fails and calls `reject` the valid credential as
`approve`-ed by the second process would be deleted. This change helps
prevent such a scenario (although there is still a small gap inside the
GCM erase command itself between reading the OS's credential store and
deleting from it - we could look at some system-wide lock around the
credential store if this is deemed a problem later).
@mjcheetham mjcheetham added the bug A bug in Git Credential Manager label Feb 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug A bug in Git Credential Manager

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants