Re: Changing transfer.credentialsInUrl to default to "warn"
Hi M & Junio,
On Mon, 13 Jan 2025, Junio C Hamano wrote:
Show 5 quoted lines
> M Hickford <mirth.hickford@gmail.com> 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.
Show 6 quoted lines
> 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://<user>:<password>@<host>` (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
M Hickford
