Hi David, On Thu, 8 Dec 2016, David Turner wrote:
> On Thu, 2016-12-08 at 15:47 +0100, Johannes Schindelin wrote: > > > I got a couple of bug reports that claim that 2.10.2 regressed on > > using network credentials. That is, users regularly hit Enter twice > > when being asked for user name and password while fetching via > > https://, and cURL automatically used to fall back to using the login > > credentials (i.e. authenticating via the Domain controller). > > > > Turns out those claims are correct: hitting Enter twice (or using URLs > > with empty user name/password such as https://:tfs:8080/) work in > > 2.10.1 and yield "Authentication failed" in 2.10.2. > > > > I tracked this down to 5275c3081c (http: http.emptyauth should allow > > empty (not just NULL) usernames, 2016-10-04) which all of a sudden > > disallowed empty user names (and now only handles things correctly > > when http.emptyAuth is set to true specifically). > > > > This smells like a real bad regression to me, certainly given the time > > I had to spend to figure this out (starting from not exactly helpful > > bug reports, due to being very specific to their setups being > > private). > > > > I am *really* tempted to change the default of http.emptyAuth to true, > > *at least* for Windows (where it is quite common to use your login > > credentials to authenticate to corporate servers). > > > > Before I do anything rash, though: Do you see any downside to that? > > I know of no reason that shouldn't work. Indeed, it's what we use do > internally. So far, nobody has reported problems. Good. > That said, we have exactly three sets of git servers that most users > talk to (two different internal; and occasionally github.com for > external stuff). So our coverage is not very broad. Okay. I think I will extend that coverage rather boldly, then ;-) > If you're going to do it, tho, don't just do it for Windows users -- do > it for everyone. Plenty of Unix clients connect to Windows-based auth > systems. Makes sense. > That said, I could imagine that there are cases where it would cause > failures for a different set of users. Let's see. At the moment, my main concern is that Git for Windows is broken for corporate users (i.e. users who rely on the implicit login authentication provided through their domain accounts). I cannot imagine that defaulting http.emptyAuth=true could cause any worse breakage. It would be different, of course, if http.emptyAuth would *not* allow the user to type their credentials when accessing something like https://github.com/dscho/shhh-secret-repository, *only* trying the login credentials. But that is not the case, with http.emptyAuth=true, login credentials are attempted first, and when they fail, the user is still asked interactively for their credentials. All I can see is that this would be *an improvement*: corporate users trying to access a Git repository that requires their login credentials would now not even need to enter empty user name/password. This alone would be already a good reason to change the default, IMHO. So here is my plan: - change the default of http.emptyAuth to true in the next Git for Windows version - publish a prerelease for early adopters to test - contribute this patch here on the Git mailing list, in the hope that it will make it into the next major version Ciao, Dscho
