> -----Original Message----- > From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C > Hamano > Sent: Wednesday, February 22, 2017 3:20 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; sand...@crustytoothpaste.net; Johannes Schindelin > <johannes.schinde...@gmx.de>; Eric Sunshine > <sunsh...@sunshineco.com>; Jeff King <p...@peff.net> > Subject: Re: [PATCH] http(s): automatically try NTLM authentication first > > David Turner <dtur...@twosigma.com> writes: > > > From: Johannes Schindelin <johannes.schinde...@gmx.de> > > > > It is common in corporate setups to have permissions managed via a > > domain account. That means that the user does not really have to log > > in when accessing a central repository via https://, but that the > > login credentials are used to authenticate with that repository. > > > > The common way to do that used to require empty credentials, i.e. > > hitting Enter twice when being asked for user name and password, or by > > using the very funny notation https://:@server/repository > > > > A recent commit (5275c3081c (http: http.emptyauth should allow empty > > (not just NULL) usernames, 2016-10-04)) broke that usage, though, all > > of a sudden requiring users to set http.emptyAuth = true. > > > > Which brings us to the bigger question why http.emptyAuth defaults to > > false, to begin with. > > This is a valid question, and and I do not see it explicitly asked in the > thread: > > https://public- > inbox.org/git/CAPig+cSphEu3iRJrkdBA+BRhi9HnopLJnKOHVuGhUqavtV1RXg > @mail.gmail.com/#t > > even though there is a hint of it already there. > > > It would be one thing if cURL would not let the user specify > > credentials interactively after attempting NTLM authentication (i.e. > > login credentials), but that is not the case. > > > > It would be another thing if attempting NTLM authentication was not > > usually what users need to do when trying to authenticate via https://. > > But that is also not the case. > > Some other possible worries we may have had I can think of are: > > - With this enabled unconditionally, would we leak some information?
I think "NTLM" is actually a misnomer here (I just copied Johannes's commit message). The mechanism is actually SPNEGO, if I understand this correctly. It seems to me that this is probably secure, since it is apparently widely implemented in browsers. > - With this enabled unconditionally, would we always incur an extra > roundtrip for people who are not running NTLM at all? > > I do not think the former is the case, but what would I know (adding a few > people involved in the original thread to CC: ;-) Always, no. For failed authentication (or authorization), apparently, yes. I tested this by setting the variable to false and then true, and trying to Push to a github repository which I didn't have write access to, with both an empty username (https://@:github.com/...) and no username (http://github.com/...). I ran this under GIT_CURL_VERBOSE=1 and I saw two 401 responses in the "http.emptyauth=true" case and one in the false case. I also tried with a repo that I did have access to (first configuring the necessary tokens for HTTPS push access), and saw two 401 responses in *both* cases.
