On Sat, 1 May 2021 at 10:13, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > 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@xxxxxxxxxxx/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 :)
