Re: [PATCH] urlmatch: do not allow passwords in URLs by default

From: Robert Coup <robert.coup@koordinates.com>
Date: May 3, 2021, 08:40 UTC
Message-ID: <CAFLLRp+LA8WNsmOYPEBbNuSR4o8TBOqZpX-_P8fh6h46tNWmCw@mail.gmail.com>
In-Reply-To: <87czuayfy9.fsf@evledraar.gmail.com>

On Sat, 1 May 2021 at 10:13, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 11 quoted lines

>
> Unlike SSH this is a thing that the HTTP protocol supports, so I don't
> think it's the place of git to go out of its way by default to break
> working URL schemas by making hard breaking assumptions about the user's
> workflow.
>
> I think a much better way to address this issue, if it's an issue that
> needs to be addressed, is on the server-side. The service operator is in
> a much better position to know if URL passwords are a bad idea in their
> case (e.g. is the software frequently used in certain ways, is there no
> transport security, are we using debug URL tracing etc).

A URL scheme of the form https://user:password@example.com/my.git gets translated by the http *client* into a request of the form:

  <Connect via TLS to example.com:443>
  GET /my.git HTTP/1.1
  Host: example.com
  Authorization: Basic dXNlcjpwYXNzd29yZAo=
  ... some more headers ...

So the server can't determine whether either/both the username or password in the Authorization header were retrieved from a credential helper, were parsed from a URL string, or came via a terminal prompt. Conceivably If the server only uses a non-default Authorization method ("Token", "Bearer", "Key", etc) or uses a separate header (eg: "MyGitHosting-Auth") then it could conceivably block Basic Authorization, and afaik Git only supports that approach via http.extraHeader - which doesn't go via any credential helpers, and is essentially obscuring authentication as something else (and is pretty user-hostile).

Rob :)