Dmitry Vilkov [off-list ref] writes:
2016-02-03 2:29 GMT+03:00 brian m. carlson [off-list ref]:
quoted
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.
On Fri, Feb 05, 2016 at 09:54:50AM -0800, Junio C Hamano wrote:
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.
You can give any invalid credentials you like. When using Kerberos, the
provided username and password are ignored, because all the
authentication information is in the ticket, and it's all encrypted.
I'm happy to send a documentation patch for this, as it seems to come up
a lot.
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?
I'd have to test how it works with Basic auth as a fallback. I don't
normally use that on my servers, so I'd have to enable it and try it
out.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
On Fri, 5 Feb 2016, Junio C Hamano wrote:
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?
quoted
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.
It is correct that libcurl needs a username to trigger the use of HTTP
authentication - any HTTP authentication - due to how we once designed the
internals for this - but when using GSS-Negotiate the actually provided user
name isn't used by libcurl for anything so it could be a fixed string or
random junk, it doesn't matter as long as a name is provided.
--
/ daniel.haxx.se