On Thu, Feb 23, 2017 at 11:11:05AM -0800, Junio C Hamano wrote: > >> As far as Kerberos, this is a desirable feature to have enabled, with > >> little downside. I just don't know about the security of the NTLM part, > >> and I don't think we should take this patch unless we're sure we know > >> the consequences of it. > > > > Hmm. That would be a problem with my proposed patch 2 then, too, if only > > because it turns the feature on by default in more places. > > > > If it _is_ dangerous to turn on all the time, I'd think we should > > consider warning people in the http.emptyauth documentation. > > I presume that we have finished discussing the security > ramification, and if I am not mistaken the conclusion was that it > could leak information if we turned on emptyAuth unconditionally > when talking to a wrong server, and that the documentation needs an > update to recommend those who use emptyAuth because they want to > talk to Negotiate servers to use the http.<site>.emptyAuth form, > limited to such servers, not a more generic http.emptyAuth, to avoid > information leakage? I don't know enough to evaluate the claims of emptyAuth being dangerous or not (nor do I use it myself or admin a server whose users need it). So I will let interested parties hash out whether it is a good idea or not, and I'm happy to drop my 2/2 for now. If we are to make it more widely available, I would prefer something more like my 2/2 than always turning on http.emptyAuth, if only because it reduces the cost to people not using the feature. I'm happy to work more on the patch if we decide to go that route. > If that is the case, let's take your 1/2 in the near-by thread > without 2/2 (auto-enable emptyAuth) for now, as Dscho seems to have > a case that may be helped by it. Yes, I think 1/2 stands on its own. Whether it helps Dscho's case or not, it eliminates an HTTP round-trip for Basic-only servers, which I think is worth it. -Peff