On Thu, Feb 23, 2017 at 12:37:25PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I suspect it isn't enough to help without 2/2. This will tell curl that > > the server does not do Negotiate, so it will skip the probe request. But > > Git will still feed curl the bogus empty credential. > > > > That's what 2/2 tries to fix: only kick in the emptyAuth hack when there > > is something besides Basic[1] to try. The way it is written adds an > > In your [1] you wanted to mention that Digest would have the same > property as Basic, or something like that? Oops, yeah. What I was going to say is that we may want a list of auth types where we _do_ want the hack on, rather than ones where we know it does not work. People are more likely to notice when the list is wrong, then. > > But if we are worried about turning on emptyAuth everywhere, the auto > > behavior could be tied to emptyauth=true (and have something like > > "emptyauth=always" to _really_ force it). I don't have an opinion there. > > I do not have a strong opinion, either, but it sounds like that even > the "disable emptyAuth hack if the server is Basic only" variant > would be much better than setting emptyAuth on by default. At least > the user whose issue was reported in Dscho's message would be fixed > by such a variant, I would think (i.e. talking to a server with no > Negotiate and emptyAuth set to true results in no attempt to give > the user a chance to tell who s/he is --- your 2/2 will turn > emptyAuth off in that case). Yes, I agree that the "auto" behavior is better than defaulting to "true". I am speaking from the perspective of git.git, which is currently defaulting to "false". It is not clear to me if "auto" is better than "false" because of the security implications. For Git for Windows, it seems like the auto behavior would be a strict improvement over the "true" default they've been shipping. -Peff