On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote: > Forgive my ignorance: is there a way to do something analagous to that > patch but for GSS-Negotiate authentication? In other words, after > using the first request to figure out what authentication mechanism > the server prefers, could git prefer it in remaining requests to avoid > the need to rewind?
We know what authentication mechanisms the server offers, but we don't know what curl will use, other than the fact that it prefers non-Basic authentication (this is documented). So if we see Negotiate only or Negotiate and Basic, we know it will try to use Negotiate if possible. So essentially the question is, do we believe that Negotiate and other authentication are likely to be used together, and are we willing to take the risk that a user wants to use non-Negotiate on such a server and has a broken server or proxy? > I don't see any simple way to do that using the libcurl API. If > checking if the server accepts GSS-Negotiate authentication and using > that to decide whether to 'Expect: 100-Continue' is easier, that would > be fine, too. If that's what the consensus is, that's much, much easier to do. The only problem is that if we have Negotiate and a non-Basic method, such as Digest, we might force Expect: 100-continue on when it does not need to be used. I think that in practice that's unlikely to be the case, as most people using GSSAPI authentication probably use Kerberos as their authentication server, and Digest hashes the password in a different way that isn't compatible. I'm the only person I'm aware of, other than Stanford (and potentially MIT), that uses Kerberos auth over HTTP, and probably fewer still use it for git push. I think that this is probably fine to do, because probably most people who are using Kerberos auth over HTTP are using Apache or nginx, which support 100-continue, and many of those institutions are universities, which don't tend to have restrictive (and broken) proxies. It also is fine with me because it means that things just work and I don't have to worry about setting configuration options. I'll plan to do a revised patch along these lines later this week unless I hear some loud objections before then. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
