Dmitry Vilkov <dmitry.a.vilkov@xxxxxxxxx> writes: > 2016-02-03 2:29 GMT+03:00 brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx>: >> I'm unclear in what case you'd need to have a username and password >> combination with GSS-Negotiate. Kerberos doesn't use your password, >> although you need some indication of a username (valid or not) to get >> libcurl to do authentication. >> >> Are you basically using a bare URL (without a username component) and >> waiting for git to prompt you for the username, so that it will then >> enable authentication? If so, this patch looks fine for that, although >> I'd expand on the commit message. If not, could you provide an example >> of what you're trying to do? > > You are right, we are using a bare URL (without a username component). > With username encoded in URL everything works just fine. But it's > generally wrong to pass creds in URL (in my opinion) and security > policy of my employer prohibits doing such thing. > > Anyway, as you said libcurl needs valid (not NULL) username/password > to do GSS-Negotiate, so there is nothing wrong if I set empty > username/password combination when git prompts for creds. OK, as Brian said, that use case would need to be in the log message, at least. I am curious, though, if you can give just a random string to username, or at least that must match what the underlying authentication mechanism uses. Brian, I can see how this would work in that use case, but I haven't convinced myself that the change would not affect other existing use cases that are supported--do you think of any that would negatively affect the user expeerience? > Even more, > there is no other way to let libcurl to use GSS-Negotiate without > username in URL. Asking lubcurl expert about that might not be a bad idea; Cc'ed Daniel Stenberg. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html