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
Reject passwords in URLs #945
Reject passwords in URLs #945
Conversation
Git allows URLs of the following pattern: https://username:password@domain/route These URLs are then parsed to pull out the username and password for use when authenticating with the URL. Git is careful to anonymize the URL in status messages with transport_anonymize_url(), but it stores the URL as plaintext in the .git/config file. The password may leak in other ways. This is not a recommended way to store credentials, especially authentication tokens that do more than simply allow access to a repository. Users should be aware that when they provide a URL in this form that they are not being incredibly secure. It is much better to use a credential manager to securely store passwords. Even better, some credential managers use more sophisticated authentication strategies including multi-factor authentication. This does not stop users from continuing to do this. Some Git hosting providers are working to completely drop username/password credential strategies, which will make URLs of this form stop working. However, that requires certain changes to credential managers that need to be released and sufficiently adopted before making such a server-side change. In the meantime, it might be helpful to alert users that they are doing something insecure with these URLs. Create a new config option, core.allowUsernamePasswordUrls, which is disabled by default. If Git attempts to parse a password from a URL in this form, it will die() if this config is not enabled. This affects a few test scripts, but enabling the config in those places is relatively simple. This will cause a significant change in behavior for users who rely upon this username:password pattern. The error message describes the config that they must enable to continue working with these URLs. This has a significant chance of breaking some automated workflows that use URLs in this fashion, but even those workflows would be better off using a different mechanism for credentials. I cannot understate the care in which we should consider this change. The impact of this change in a Git release could be significant. We should advertise this very clearly in the release notes. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
680dfdc
to
7eaad0c
Compare
/submit |
Submitted as pull.945.git.1619807844627.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
On the Git mailing list, Jeff King wrote (reply to this):
|
On the Git mailing list, "brian m. carlson" wrote (reply to this):
|
User |
On the Git mailing list, Christian Couder wrote (reply to this):
|
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):
|
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):
|
On the Git mailing list, Junio C Hamano wrote (reply to this):
|
On the Git mailing list, Robert Coup wrote (reply to this):
|
User |
On the Git mailing list, Derrick Stolee wrote (reply to this):
|
User |
On the Git mailing list, Jeff King wrote (reply to this):
|
I received multiple messages "alerting" me to the issue of users supplying server-side tokens into the
username:password
field of a URL. This is not a secure way to handle these tokens.On the one hand, this is user error: Users should not supply a token to a location where they do not know what will happen to it. In Git's defense, its behavior is completely open about storing the URL in the .git/config file as a plain-text string and users should know that when using this feature.
However, users just. keep. doing it.
There is some expectation that since this portion of the URL is a password, then Git is responsible for tracking that password securely. I'm not sure we should venture down that road, since we already have a pretty good solution by using the credential helper interface.
Here is my best effort to find a compromise here: start failing when parsing a password from a URL like this, with a config option to re-enable the existing behavior.
I completely understand if this is too much of a breaking change. I wonder if there is anything we can do to assist users into being more careful with their secrets.
Thanks,
-Stolee
Cc: gitster@pobox.com
Cc: peff@peff.net
Cc: me@ttaylorr.com
Cc: avarab@gmail.com
Cc: christian.couder@gmail.com
Cc: johannes.schindelin@gmx.de
Cc: jrnieder@gmail.com
cc: "brian m. carlson" sandals@crustytoothpaste.net
cc: Robert Coup robert.coup@koordinates.com
cc: Derrick Stolee stolee@gmail.com