# Changing transfer.credentialsInUrl to default to "warn" 5 messages from 2025-01-11 to 2025-01-13. Participants: M Hickford, Junio C Hamano, Johannes Schindelin, brian m. carlson. Thread: https://gitlist.dev/t/62788 ## M Hickford, 2025-01-11 07:15 Subject: Changing transfer.credentialsInUrl to default to "warn" Message-ID: <20250111071500.710169-1-mirth.hickford@gmail.com> URL: https://gitlist.dev/e/20250111071500.710169-1-mirth.hickford%40gmail.com ``` Including plaintext credentials in the remote URL risks inadvertent credentials exposure, as explained in docs https://git-scm.com/docs/git-config#Documentation/git-config.txt-transfercredentialsInUrl Config key transfer.credentialsInUrl defaults to "allow", but if set to "warn", Git warns the user about plaintext credentials in the remote URL. $ git clone https://tim:hunter2@example.com/example.git warning: URL 'https://tim:@example.com/example.git' uses plaintext credentials In order to nudge users towards more secure practices (namely, using a credential helper), would anyone else be in favour of changing transfer.credentialsInUrl to default to "warn"? https://github.com/git/git/commit/6dcbdc0d6616d7fbd2445aa2237b22e3c172ea85 > This change currently defaults the behavior to "allow" which does > nothing with these URLs. We can consider changing this behavior to > "warn" by default if we wish. At that time, we may want to add some > advice about setting fetch.credentialsInUrl=ignore for users who still > want to follow this pattern (and not receive the warning). ``` ## Junio C Hamano, 2025-01-13 16:42 Subject: Re: Changing transfer.credentialsInUrl to default to "warn" Message-ID: URL: https://gitlist.dev/e/xmqq1px6br7p.fsf%40gitster.g In-Reply-To: <20250111071500.710169-1-mirth.hickford@gmail.com> ``` M Hickford writes: > In order to nudge users towards more secure practices (namely, > using a credential helper), would anyone else be in favour of > changing transfer.credentialsInUrl to default to "warn"? I personally do not have a problem with the proposal, but it is curious that it is documented as inspecting only .URL and .pushURL is not checked. So, in addition to "once we start warning by default, we'd need an advice message to tell the users how to turn it off" Derrick says in the commit log message, we would probably want to see if we should/can cover .pushURL and need necessary updates before it happens. Thanks. ``` ## Johannes Schindelin, 2025-01-13 21:53 Subject: Re: Changing transfer.credentialsInUrl to default to "warn" Message-ID: <7a60c9ec-8f98-73d3-4539-d96b63a4f442@gmx.de> URL: https://gitlist.dev/e/7a60c9ec-8f98-73d3-4539-d96b63a4f442%40gmx.de In-Reply-To: ``` Hi M & Junio, On Mon, 13 Jan 2025, Junio C Hamano wrote: > M Hickford writes: > > > In order to nudge users towards more secure practices (namely, using a > > credential helper), would anyone else be in favour of changing > > transfer.credentialsInUrl to default to "warn"? IIRC that was the plan all along, and if the original Git Fundamentals team (of which both Stolee and myself were members, and from which this patch originated) still existed, I believe that plan would have been turned into reality already. Or more clearly: Yes, this is a good idea. > I personally do not have a problem with the proposal, but it is curious > that it is documented as inspecting only .URL and .pushURL is not > checked. So, in addition to "once we start warning by default, we'd > need an advice message to tell the users how to turn it off" Derrick > says in the commit log message, we would probably want to see if we > should/can cover .pushURL and need necessary updates before it happens. The reason why `.pushURL` was not handled as well is that it is way too common for Git users to call `git clone https://:@` (heck, I am privy to documentation that explicitly calls for this) and those users typically do not realize that the credentials are then stored as plain text in their Git config (and prior to b7d49ac1ecd (trace2: redact passwords from https:// URLs by default, 2023-11-22) would even be logged via Trace2). There is no similar indirect way to leak credentials into `pushURL`; You really have to set that config setting explicitly (or call something like `git remote set-url --push [...]`). It is much more obvious in those instances that the verbatim credentials will be leaked into the config. Having said that, I would be in favor of letting `transfer.credentialsInURL` treat `remote.*.pushURL` in the same manner as `remote.*.url`. Ciao, Johannes ``` ## brian m. carlson, 2025-01-13 21:54 Subject: Re: Changing transfer.credentialsInUrl to default to "warn" Message-ID: URL: https://gitlist.dev/e/Z4WLsmq4rPEMnUXK%40tapette.crustytoothpaste.net In-Reply-To: ``` On 2025-01-13 at 16:42:34, Junio C Hamano wrote: > M Hickford writes: > > > In order to nudge users towards more secure practices (namely, > > using a credential helper), would anyone else be in favour of > > changing transfer.credentialsInUrl to default to "warn"? > > I personally do not have a problem with the proposal, but it is > curious that it is documented as inspecting only .URL and .pushURL > is not checked. So, in addition to "once we start warning by > default, we'd need an advice message to tell the users how to turn > it off" Derrick says in the commit log message, we would probably > want to see if we should/can cover .pushURL and need necessary updates > before it happens. I agree. It's not clear to me from the documentation if this only warns if there's a password in the URL or also if there's just a username. (To me, the word "credentials" doesn't seem to explain that very well.) The former I think is fine, the latter is not. Looking at the code, it appears it is the former, so that's good. Perhaps we should also clarify the documentation so that users can make an educated decision. I'll send a patch. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ``` ## Junio C Hamano, 2025-01-13 22:27 Subject: Re: Changing transfer.credentialsInUrl to default to "warn" Message-ID: URL: https://gitlist.dev/e/xmqq34hm8i4b.fsf%40gitster.g In-Reply-To: <7a60c9ec-8f98-73d3-4539-d96b63a4f442@gmx.de> ``` Johannes Schindelin writes: > The reason why `.pushURL` was not handled as well is that it is way too > common for Git users to call `git clone https://:@` > ... > There is no similar indirect way to leak credentials into `pushURL` Ah, so it is not primarily between .URL vs .pushURL, but the difference is between "clone" that leaves the URL used on the command line in the configuraiton, vs "push" that does not. And because .pushURL has to be explicitly configured by the end-user, there is much less need to remind that they are _storing_ credential material in the configuration files. The reasoning does make sense. > Having said that, I would be in favor of letting > `transfer.credentialsInURL` treat `remote.*.pushURL` in the same manner as > `remote.*.url`. Amen to that. Thanks. ```