Changing transfer.credentialsInUrl to default to "warn"

Changing transfer.credentialsInUrl to default to "warn"

[M Hickford]

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:<redacted>@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).

Re: Changing transfer.credentialsInUrl to default to "warn"

[Junio C Hamano]

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"?

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.

Re: Changing transfer.credentialsInUrl to default to "warn"

[Johannes Schindelin]

Hi M & Junio,

On Mon, 13 Jan 2025, Junio C Hamano wrote:

> 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.

> 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

Re: Changing transfer.credentialsInUrl to default to "warn"

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 2025-01-13 at 16:42:34, Junio C Hamano wrote:
> 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"?
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Changing transfer.credentialsInUrl to default to "warn"

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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://<user>:<password>@<host>`
> ...
> 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.