{"thread":{"id":"41306","subject":"[PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","startedAt":"2016-02-02T09:11:24Z","lastAt":"2016-02-25T16:54:21Z","messageCount":25,"participants":["Dmitry Vilkov","Junio C Hamano","brian m. carlson","Daniel Stenberg","Eric Sunshine","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"277215","messageId":"1454404284-2197-1-git-send-email-dmitry.a.vilkov@gmail.com","threadId":"41306","inReplyTo":null,"subject":"[PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Dmitry Vilkov","fromEmail":"dmitry.a.vilkov@gmail.com","sentAt":"2016-02-02T09:11:24Z","receivedAt":"2016-02-02T09:11:24Z","isPatch":true,"sender":{"key":"dmitry.a.vilkov@gmail.com","avatar":null},"body":"This is fix of bug introduced by 4dbe66464 commit.\nThe problem is that when username/password combination was not set,\nthe first HTTP(S) request will fail and user will be asked for\ncredentials. As a side effect of first HTTP(S) request, libcurl auth\nmethod GSS-Negotiate will be disabled unconditionally. Although, we\nhaven't tried yet provided credentials for this auth method.\n\nSigned-off-by: Dmitry Vilkov \n---\n http.c | 9 ++++++---\n 1 file changed, 6 insertions(+), 3 deletions(-)\n\ndiff --git a/http.c b/http.c\nindex 0da9e66..707ea84 100644\n--- a/http.c\n+++ b/http.c\n@@ -951,12 +951,15 @@ static int handle_curl_result(struct slot_results *results)\n \t\treturn HTTP_MISSING_TARGET;\n \telse if (results->http_code == 401) {\n \t\tif (http_auth.username && http_auth.password) {\n+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n+\t\t\tif (http_auth_methods & CURLAUTH_GSSNEGOTIATE) {\n+\t\t\t\thttp_auth_methods &= ~CURLAUTH_GSSNEGOTIATE;\n+\t\t\t\treturn HTTP_REAUTH;\n+\t\t\t}\n+#endif\n \t\t\tcredential_reject(&http_auth);\n \t\t\treturn HTTP_NOAUTH;\n \t\t} else {\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n-\t\t\thttp_auth_methods &= ~CURLAUTH_GSSNEGOTIATE;\n-#endif\n \t\t\treturn HTTP_REAUTH;\n \t\t}\n \t} else {\n-- \n2.4.10\n"},{"id":"277273","messageId":"xmqqegcusvb4.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"1454404284-2197-1-git-send-email-dmitry.a.vilkov@gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-02T20:37:19Z","receivedAt":"2016-02-02T20:37:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Vilkov writes:\n\n> This is fix of bug introduced by 4dbe66464 commit.\n\nThat would be 4dbe6646 (remote-curl: fall back to Basic auth if\nNegotiate fails, 2015-01-08) that appears in v2.3.1 and onward.\n\n> The problem is that when username/password combination was not set,\n> the first HTTP(S) request will fail and user will be asked for\n> credentials. As a side effect of first HTTP(S) request, libcurl auth\n> method GSS-Negotiate will be disabled unconditionally. Although, we\n> haven't tried yet provided credentials for this auth method.\n\nBrian, comments? Here is what you wrote in that commit:\n\n If Basic and something else are offered, libcurl will never\n attempt to use Basic, even if the other option fails. Teach the\n HTTP client code to stop trying authentication mechanisms that\n don't use a password (currently Negotiate) after the first\n failure, since if they failed the first time, they will never\n succeed.\n\nThanks.\n\n> Signed-off-by: Dmitry Vilkov \n> ---\n> http.c | 9 ++++++---\n> 1 file changed, 6 insertions(+), 3 deletions(-)\n>\n> diff --git a/http.c b/http.c\n> index 0da9e66..707ea84 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -951,12 +951,15 @@ static int handle_curl_result(struct slot_results *results)\n> \t\treturn HTTP_MISSING_TARGET;\n> \telse if (results->http_code == 401) {\n> \t\tif (http_auth.username && http_auth.password) {\n> +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n> +\t\t\tif (http_auth_methods & CURLAUTH_GSSNEGOTIATE) {\n> +\t\t\t\thttp_auth_methods &= ~CURLAUTH_GSSNEGOTIATE;\n> +\t\t\t\treturn HTTP_REAUTH;\n> +\t\t\t}\n> +#endif\n> \t\t\tcredential_reject(&http_auth);\n> \t\t\treturn HTTP_NOAUTH;\n> \t\t} else {\n> -#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n> -\t\t\thttp_auth_methods &= ~CURLAUTH_GSSNEGOTIATE;\n> -#endif\n> \t\t\treturn HTTP_REAUTH;\n> \t\t}\n> \t} else {\n"},{"id":"277283","messageId":"20160202232952.GA6503@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"xmqqegcusvb4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-02T23:29:52Z","receivedAt":"2016-02-02T23:29:52Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Feb 02, 2016 at 12:37:19PM -0800, Junio C Hamano wrote:\n> Dmitry Vilkov writes:\n> \n> > This is fix of bug introduced by 4dbe66464 commit.\n> \n> That would be 4dbe6646 (remote-curl: fall back to Basic auth if\n> Negotiate fails, 2015-01-08) that appears in v2.3.1 and onward.\n> \n> > The problem is that when username/password combination was not set,\n> > the first HTTP(S) request will fail and user will be asked for\n> > credentials. As a side effect of first HTTP(S) request, libcurl auth\n> > method GSS-Negotiate will be disabled unconditionally. Although, we\n> > haven't tried yet provided credentials for this auth method.\n\nI'm unclear in what case you'd need to have a username and password\ncombination with GSS-Negotiate. Kerberos doesn't use your password,\nalthough you need some indication of a username (valid or not) to get\nlibcurl to do authentication.\n\nAre you basically using a bare URL (without a username component) and\nwaiting for git to prompt you for the username, so that it will then\nenable authentication? If so, this patch looks fine for that, although\nI'd expand on the commit message. If not, could you provide an example\nof what you're trying to do?\n\n> Brian, comments? Here is what you wrote in that commit:\n> \n> If Basic and something else are offered, libcurl will never\n> attempt to use Basic, even if the other option fails. Teach the\n> HTTP client code to stop trying authentication mechanisms that\n> don't use a password (currently Negotiate) after the first\n> failure, since if they failed the first time, they will never\n> succeed.\n\nI think what's happening here is no username is ever provided, so\nlibcurl never tries authentication in the first place.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"277529","messageId":"CAHdYDCqtNQMoU3Gu2AcSEWM5wA0SbaMrivu3WV_-N+B-F67v1Q@mail.gmail.com","threadId":"41306","inReplyTo":"20160202232952.GA6503@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Dmitry Vilkov","fromEmail":"dmitry.a.vilkov@gmail.com","sentAt":"2016-02-05T09:18:22Z","receivedAt":"2016-02-05T09:18:22Z","isPatch":true,"sender":{"key":"dmitry.a.vilkov@gmail.com","avatar":null},"body":"2016-02-03 2:29 GMT+03:00 brian m. carlson :\n> I'm unclear in what case you'd need to have a username and password\n> combination with GSS-Negotiate. Kerberos doesn't use your password,\n> although you need some indication of a username (valid or not) to get\n> libcurl to do authentication.\n>\n> Are you basically using a bare URL (without a username component) and\n> waiting for git to prompt you for the username, so that it will then\n> enable authentication? If so, this patch looks fine for that, although\n> I'd expand on the commit message. If not, could you provide an example\n> of what you're trying to do?\n\nYou are right, we are using a bare URL (without a username component).\nWith username encoded in URL everything works just fine. But it's\ngenerally wrong to pass creds in URL (in my opinion) and security\npolicy of my employer prohibits doing such thing.\nAnyway, as you said libcurl needs valid (not NULL) username/password\nto do GSS-Negotiate, so there is nothing wrong if I set empty\nusername/password combination when git prompts for creds. Even more,\nthere is no other way to let libcurl to use GSS-Negotiate without\nusername in URL.\n"},{"id":"277555","messageId":"xmqq60y3dout.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"CAHdYDCqtNQMoU3Gu2AcSEWM5wA0SbaMrivu3WV_-N+B-F67v1Q@mail.gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-05T17:54:50Z","receivedAt":"2016-02-05T17:54:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Vilkov writes:\n\n> 2016-02-03 2:29 GMT+03:00 brian m. carlson :\n>> I'm unclear in what case you'd need to have a username and password\n>> combination with GSS-Negotiate. Kerberos doesn't use your password,\n>> although you need some indication of a username (valid or not) to get\n>> libcurl to do authentication.\n>>\n>> Are you basically using a bare URL (without a username component) and\n>> waiting for git to prompt you for the username, so that it will then\n>> enable authentication? If so, this patch looks fine for that, although\n>> I'd expand on the commit message. If not, could you provide an example\n>> of what you're trying to do?\n>\n> You are right, we are using a bare URL (without a username component).\n> With username encoded in URL everything works just fine. But it's\n> generally wrong to pass creds in URL (in my opinion) and security\n> policy of my employer prohibits doing such thing.\n>\n> Anyway, as you said libcurl needs valid (not NULL) username/password\n> to do GSS-Negotiate, so there is nothing wrong if I set empty\n> username/password combination when git prompts for creds. \n\nOK, as Brian said, that use case would need to be in the log\nmessage, at least. I am curious, though, if you can give just a\nrandom string to username, or at least that must match what the\nunderlying authentication mechanism uses.\n\nBrian, I can see how this would work in that use case, but I haven't\nconvinced myself that the change would not affect other existing use\ncases that are supported--do you think of any that would negatively\naffect the user expeerience?\n\n> Even more,\n> there is no other way to let libcurl to use GSS-Negotiate without\n> username in URL.\n\nAsking lubcurl expert about that might not be a bad idea; Cc'ed\nDaniel Stenberg.\n"},{"id":"277592","messageId":"20160205204648.GA7403@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"CAHdYDCqtNQMoU3Gu2AcSEWM5wA0SbaMrivu3WV_-N+B-F67v1Q@mail.gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-05T20:46:48Z","receivedAt":"2016-02-05T20:46:48Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote:\n> You are right, we are using a bare URL (without a username component).\n> With username encoded in URL everything works just fine. But it's\n> generally wrong to pass creds in URL (in my opinion) and security\n> policy of my employer prohibits doing such thing.\n> Anyway, as you said libcurl needs valid (not NULL) username/password\n> to do GSS-Negotiate, so there is nothing wrong if I set empty\n> username/password combination when git prompts for creds. Even more,\n> there is no other way to let libcurl to use GSS-Negotiate without\n> username in URL.\n\nYou can literally do https://:@git.crustytoothpaste.net/git/repo.git as\nthe URL, and that will work. GSS-Negotiate using Kerberos passes the\nticket, which contains the principal name in it, so an actual username\nand password is not needed at all. libcurl just needs something to tell\nit to do authentication.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"277594","messageId":"20160205205835.GB7403@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"xmqq60y3dout.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-05T20:58:35Z","receivedAt":"2016-02-05T20:58:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Feb 05, 2016 at 09:54:50AM -0800, Junio C Hamano wrote:\n> OK, as Brian said, that use case would need to be in the log\n> message, at least. I am curious, though, if you can give just a\n> random string to username, or at least that must match what the\n> underlying authentication mechanism uses.\n\nYou can give any invalid credentials you like. When using Kerberos, the\nprovided username and password are ignored, because all the\nauthentication information is in the ticket, and it's all encrypted.\n\nI'm happy to send a documentation patch for this, as it seems to come up\na lot.\n\n> Brian, I can see how this would work in that use case, but I haven't\n> convinced myself that the change would not affect other existing use\n> cases that are supported--do you think of any that would negatively\n> affect the user expeerience?\n\nI'd have to test how it works with Basic auth as a fallback. I don't\nnormally use that on my servers, so I'd have to enable it and try it\nout.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"277595","messageId":"xmqqa8nedg59.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"20160205204648.GA7403@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-05T21:02:58Z","receivedAt":"2016-02-05T21:02:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote:\n>> You are right, we are using a bare URL (without a username component).\n>> With username encoded in URL everything works just fine. But it's\n>> generally wrong to pass creds in URL (in my opinion) and security\n>> policy of my employer prohibits doing such thing.\n>> Anyway, as you said libcurl needs valid (not NULL) username/password\n>> to do GSS-Negotiate, so there is nothing wrong if I set empty\n>> username/password combination when git prompts for creds. Even more,\n>> there is no other way to let libcurl to use GSS-Negotiate without\n>> username in URL.\n>\n> You can literally do https://:@git.crustytoothpaste.net/git/repo.git as\n> the URL, and that will work. GSS-Negotiate using Kerberos passes the\n> ticket, which contains the principal name in it, so an actual username\n> and password is not needed at all. libcurl just needs something to tell\n> it to do authentication.\n\nHmph, so documenting that :@\nas a supported way might be an ugly-looking solution to the original\nproblem. A less ugly-looking solution might be a boolean that can\nbe set per URL (we already have urlmatch-config infrastructure to\nhelp us do so) to tell us to pass the empty credential to lubCurl,\nbypassing the step to ask the user for password that we do not use.\n\nThe end-result of either of these solution would strictly be better\nthan the patch we discussed in that the end user will not have to\ninteract with the prompt at all, right?\n"},{"id":"277597","messageId":"20160205210623.GC7403@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"xmqqa8nedg59.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-05T21:06:24Z","receivedAt":"2016-02-05T21:06:24Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote:\n> Hmph, so documenting that :@\n> as a supported way might be an ugly-looking solution to the original\n> problem. A less ugly-looking solution might be a boolean that can\n> be set per URL (we already have urlmatch-config infrastructure to\n> help us do so) to tell us to pass the empty credential to lubCurl,\n> bypassing the step to ask the user for password that we do not use.\n> \n> The end-result of either of these solution would strictly be better\n> than the patch we discussed in that the end user will not have to\n> interact with the prompt at all, right?\n\nYes, that's true. I'll try to come up with a patch this weekend that\nimplements that (maybe remote.forceAuth = true or somesuch).\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"277604","messageId":"xmqq60y2dduw.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"20160205210623.GC7403@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-05T21:52:23Z","receivedAt":"2016-02-05T21:52:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote:\n>> Hmph, so documenting that :@\n>> as a supported way might be an ugly-looking solution to the original\n>> problem. A less ugly-looking solution might be a boolean that can\n>> be set per URL (we already have urlmatch-config infrastructure to\n>> help us do so) to tell us to pass the empty credential to lubCurl,\n>> bypassing the step to ask the user for password that we do not use.\n>> \n>> The end-result of either of these solution would strictly be better\n>> than the patch we discussed in that the end user will not have to\n>> interact with the prompt at all, right?\n>\n> Yes, that's true. I'll try to come up with a patch this weekend that\n> implements that (maybe remote.forceAuth = true or somesuch).\n\nThanks.\n\nI think the configuration should live inside http.* namespace, as\nthere are already things like http[.].sslCert and friends.\n\nI do not have a good suggestion on the name of the leaf-level\nvariable. ForceAuth sounds as if you are forcing authentication\neven when the other side does not require it, though.\n"},{"id":"277664","messageId":"alpine.DEB.2.20.1602061850460.4476@tvnag.unkk.fr","threadId":"41306","inReplyTo":"xmqq60y3dout.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2016-02-06T17:53:55Z","receivedAt":"2016-02-06T17:53:55Z","isPatch":true,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Fri, 5 Feb 2016, Junio C Hamano wrote:\n\n> OK, as Brian said, that use case would need to be in the log message, at \n> least. I am curious, though, if you can give just a random string to \n> username, or at least that must match what the underlying authentication \n> mechanism uses.\n>\n> Brian, I can see how this would work in that use case, but I haven't \n> convinced myself that the change would not affect other existing use cases \n> that are supported--do you think of any that would negatively affect the \n> user expeerience?\n>\n>> Even more, there is no other way to let libcurl to use GSS-Negotiate \n>> without username in URL.\n>\n> Asking lubcurl expert about that might not be a bad idea; Cc'ed Daniel \n> Stenberg.\n\nIt is correct that libcurl needs a username to trigger the use of HTTP \nauthentication - any HTTP authentication - due to how we once designed the \ninternals for this - but when using GSS-Negotiate the actually provided user \nname isn't used by libcurl for anything so it could be a fixed string or \nrandom junk, it doesn't matter as long as a name is provided.\n\n-- \n\n / daniel.haxx.se\n"},{"id":"277716","messageId":"CAHdYDCq+MiAJoCPFd3Qn9VjAzoii8QgTOOV7HXEV8OdzW-dgPQ@mail.gmail.com","threadId":"41306","inReplyTo":"xmqq60y2dduw.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Dmitry Vilkov","fromEmail":"dmitry.a.vilkov@gmail.com","sentAt":"2016-02-08T09:11:57Z","receivedAt":"2016-02-08T09:11:57Z","isPatch":true,"sender":{"key":"dmitry.a.vilkov@gmail.com","avatar":null},"body":"2016-02-06 0:52 GMT+03:00 Junio C Hamano :\n> \"brian m. carlson\" writes:\n>\n>> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote:\n>>> Hmph, so documenting that :@\n>>> as a supported way might be an ugly-looking solution to the original\n>>> problem. A less ugly-looking solution might be a boolean that can\n>>> be set per URL (we already have urlmatch-config infrastructure to\n>>> help us do so) to tell us to pass the empty credential to lubCurl,\n>>> bypassing the step to ask the user for password that we do not use.\n>>>\n>>> The end-result of either of these solution would strictly be better\n>>> than the patch we discussed in that the end user will not have to\n>>> interact with the prompt at all, right?\n>>\n>> Yes, that's true. I'll try to come up with a patch this weekend that\n>> implements that (maybe remote.forceAuth = true or somesuch).\n>\n> Thanks.\n>\n> I think the configuration should live inside http.* namespace, as\n> there are already things like http[.].sslCert and friends.\n>\n> I do not have a good suggestion on the name of the leaf-level\n> variable. ForceAuth sounds as if you are forcing authentication\n> even when the other side does not require it, though.\n\nThat would be great! Definitely it will be much better solution than\npatch I've proposed.\n"},{"id":"278185","messageId":"1455561886-42028-1-git-send-email-sandals@crustytoothpaste.net","threadId":"41306","inReplyTo":"CAHdYDCq+MiAJoCPFd3Qn9VjAzoii8QgTOOV7HXEV8OdzW-dgPQ@mail.gmail.com","subject":"[PATCH] http: add option to try authentication without username","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-15T18:44:46Z","receivedAt":"2016-02-15T18:44:46Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Performing GSS-Negotiate authentication using Kerberos does not require\nspecifying a username or password, since that information is already\nincluded in the ticket itself. However, libcurl refuses to perform\nauthentication if it has not been provided with a username and password.\nAdd an option, http.emptyAuth, that provides libcurl with an empty\nusername and password to make it attempt authentication anyway.\n---\nI'm not super excited about this name, but I couldn't think of a better\none. Suggestions welcome.\n\n Documentation/config.txt | 6 ++++++\n http.c | 13 +++++++++++--\n 2 files changed, 17 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 27f02be3..f11de77e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1648,6 +1648,12 @@ http.proxyAuthMethod::\n * `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)\n --\n \n+http.emptyAuth::\n+\tAttempt authentication without seeking a username or password. This\n+\tcan be used to attempt GSS-Negotiate authentication without specifying\n+\ta username in the URL, as libcurl normally requires a username for\n+\tauthentication.\n+\n http.cookieFile::\n \tFile containing previously stored cookie lines which should be used\n \tin the Git http session, if they match the server. The file format\ndiff --git a/http.c b/http.c\nindex dfc53c1e..a12a804b 100644\n--- a/http.c\n+++ b/http.c\n@@ -87,6 +87,7 @@ static int curl_save_cookies;\n struct credential http_auth = CREDENTIAL_INIT;\n static int http_proactive_auth;\n static const char *user_agent;\n+static int curl_empty_auth;\n \n #if LIBCURL_VERSION_NUM >= 0x071700\n /* Use CURLOPT_KEYPASSWD as is */\n@@ -299,14 +300,22 @@ static int http_options(const char *var, const char *value, void *cb)\n \tif (!strcmp(\"http.useragent\", var))\n \t\treturn git_config_string(&user_agent, var, value);\n \n+\tif (!strcmp(\"http.emptyauth\", var)) {\n+\t\tcurl_empty_auth = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \t/* Fall back on the default ones */\n \treturn git_default_config(var, value, cb);\n }\n \n static void init_curl_http_auth(CURL *result)\n {\n-\tif (!http_auth.username)\n+\tif (!http_auth.username) {\n+\t\tif (curl_empty_auth)\n+\t\t\tcurl_easy_setopt(result, CURLOPT_USERPWD, \":\");\n \t\treturn;\n+\t}\n \n \tcredential_fill(&http_auth);\n \n@@ -827,7 +836,7 @@ struct active_request_slot *get_active_slot(void)\n #ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n \tcurl_easy_setopt(slot->curl, CURLOPT_HTTPAUTH, http_auth_methods);\n #endif\n-\tif (http_auth.password)\n+\tif (http_auth.password || curl_empty_auth)\n \t\tinit_curl_http_auth(slot->curl);\n \n \treturn slot;\n"},{"id":"278187","messageId":"CAPig+cTr1eW1KLsZGpY98hUhJ2EHdPopz9C_gTztZRdNPBQTmQ@mail.gmail.com","threadId":"41306","inReplyTo":"1455561886-42028-1-git-send-email-sandals@crustytoothpaste.net","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-02-15T20:19:25Z","receivedAt":"2016-02-15T20:19:25Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Feb 15, 2016 at 1:44 PM, brian m. carlson\n wrote:\n> Performing GSS-Negotiate authentication using Kerberos does not require\n> specifying a username or password, since that information is already\n> included in the ticket itself. However, libcurl refuses to perform\n> authentication if it has not been provided with a username and password.\n> Add an option, http.emptyAuth, that provides libcurl with an empty\n> username and password to make it attempt authentication anyway.\n\nI'm not familiar with this code, so let me know if my comments (below)\nare off the mark...\n\n> ---\n> diff --git a/http.c b/http.c\n> +++ b/http.c\n> @@ -299,14 +300,22 @@ static int http_options(const char *var, const char *value, void *cb)\n> static void init_curl_http_auth(CURL *result)\n> {\n> - if (!http_auth.username)\n> + if (!http_auth.username) {\n> + if (curl_empty_auth)\n> + curl_easy_setopt(result, CURLOPT_USERPWD, \":\");\n\nDoes this need to take LIBCURL_VERSION_NUM into account? Other code\nwhich uses CURLOPT_USERPWD only does so for certain versions of\nlibcurl, otherwise CURLOPT_USERNAME and CURLOPT_PASSWORD is used.\n\n> return;\n> + }\n>\n> credential_fill(&http_auth);\n>\n> @@ -827,7 +836,7 @@ struct active_request_slot *get_active_slot(void)\n> #ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n> curl_easy_setopt(slot->curl, CURLOPT_HTTPAUTH, http_auth_methods);\n> #endif\n> - if (http_auth.password)\n> + if (http_auth.password || curl_empty_auth)\n> init_curl_http_auth(slot->curl);\n>\n> return slot;\n\nRather than sprinkling curl_empty_auth special cases here and there,\nwould it be possible to simply set http_auth.username and\nhttp_auth.password to empty strings early on if they are not already\nset and curl_empty_auth is true, and then let the:\n\n strbuf_addf(&up, \"%s:%s\",\n http_auth.username, http_auth.password);\n\nin init_curl_http_auth() handle them in the normal fashion, with the\nend result being the same \":\" set explicitly by this patch?\n"},{"id":"278189","messageId":"20160215202937.GA57185@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"CAPig+cTr1eW1KLsZGpY98hUhJ2EHdPopz9C_gTztZRdNPBQTmQ@mail.gmail.com","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-15T20:29:37Z","receivedAt":"2016-02-15T20:29:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Feb 15, 2016 at 03:19:25PM -0500, Eric Sunshine wrote:\n> On Mon, Feb 15, 2016 at 1:44 PM, brian m. carlson\n> wrote:\n> > Performing GSS-Negotiate authentication using Kerberos does not require\n> > specifying a username or password, since that information is already\n> > included in the ticket itself. However, libcurl refuses to perform\n> > authentication if it has not been provided with a username and password.\n> > Add an option, http.emptyAuth, that provides libcurl with an empty\n> > username and password to make it attempt authentication anyway.\n> \n> I'm not familiar with this code, so let me know if my comments (below)\n> are off the mark...\n> \n> > ---\n> > diff --git a/http.c b/http.c\n> > +++ b/http.c\n> > @@ -299,14 +300,22 @@ static int http_options(const char *var, const char *value, void *cb)\n> > static void init_curl_http_auth(CURL *result)\n> > {\n> > - if (!http_auth.username)\n> > + if (!http_auth.username) {\n> > + if (curl_empty_auth)\n> > + curl_easy_setopt(result, CURLOPT_USERPWD, \":\");\n> \n> Does this need to take LIBCURL_VERSION_NUM into account? Other code\n> which uses CURLOPT_USERPWD only does so for certain versions of\n> libcurl, otherwise CURLOPT_USERNAME and CURLOPT_PASSWORD is used.\n\nThis is the oldest version, which means it's the most compatible. Since\nwe don't need to consider odd usernames, it seemed silly to have both\ncases present in the code. The benefit of using the pair of options is\nthat we don't leak memory in the non-empty auth case.\n\n> > return;\n> > + }\n> >\n> > credential_fill(&http_auth);\n> >\n> > @@ -827,7 +836,7 @@ struct active_request_slot *get_active_slot(void)\n> > #ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n> > curl_easy_setopt(slot->curl, CURLOPT_HTTPAUTH, http_auth_methods);\n> > #endif\n> > - if (http_auth.password)\n> > + if (http_auth.password || curl_empty_auth)\n> > init_curl_http_auth(slot->curl);\n> >\n> > return slot;\n> \n> Rather than sprinkling curl_empty_auth special cases here and there,\n> would it be possible to simply set http_auth.username and\n> http_auth.password to empty strings early on if they are not already\n> set and curl_empty_auth is true, and then let the:\n> \n> strbuf_addf(&up, \"%s:%s\",\n> http_auth.username, http_auth.password);\n> \n> in init_curl_http_auth() handle them in the normal fashion, with the\n> end result being the same \":\" set explicitly by this patch?\n\nThat would work. I was concerned about the credential_fill call\nactually prompting the user, but it appears that it doesn't do that if\nthe password already exists. I don't know if we want to rely on that\nfunctionality, though.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"278190","messageId":"20160215203451.GA29705@sigill.intra.peff.net","threadId":"41306","inReplyTo":"20160215202937.GA57185@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-15T20:34:51Z","receivedAt":"2016-02-15T20:34:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 15, 2016 at 08:29:37PM +0000, brian m. carlson wrote:\n\n> > Rather than sprinkling curl_empty_auth special cases here and there,\n> > would it be possible to simply set http_auth.username and\n> > http_auth.password to empty strings early on if they are not already\n> > set and curl_empty_auth is true, and then let the:\n> > \n> > strbuf_addf(&up, \"%s:%s\",\n> > http_auth.username, http_auth.password);\n> > \n> > in init_curl_http_auth() handle them in the normal fashion, with the\n> > end result being the same \":\" set explicitly by this patch?\n> \n> That would work. I was concerned about the credential_fill call\n> actually prompting the user, but it appears that it doesn't do that if\n> the password already exists. I don't know if we want to rely on that\n> functionality, though.\n\nYeah, credential_fill() will treat that as a noop, as it is no different\nthan getting \"https://user:pass@example.com\" in the URL in the first\nplace. But it will _also_ send the result to credential_approve() and\ncredential_reject(), which you probably don't want (because you do not\nwant to store these useless dummy credentials in your keystore).\n\nSo I think this hack should remain purely at the curl level, and never\ntouch the credential struct at all.\n\nWhich is a shame, because I think Eric's suggestion is otherwise much\nmore readable. :)\n\n-Peff\n"},{"id":"278191","messageId":"20160215203659.GB57185@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"20160215203451.GA29705@sigill.intra.peff.net","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-15T20:36:59Z","receivedAt":"2016-02-15T20:36:59Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Feb 15, 2016 at 03:34:51PM -0500, Jeff King wrote:\n> On Mon, Feb 15, 2016 at 08:29:37PM +0000, brian m. carlson wrote:\n> > That would work. I was concerned about the credential_fill call\n> > actually prompting the user, but it appears that it doesn't do that if\n> > the password already exists. I don't know if we want to rely on that\n> > functionality, though.\n> \n> Yeah, credential_fill() will treat that as a noop, as it is no different\n> than getting \"https://user:pass@example.com\" in the URL in the first\n> place. But it will _also_ send the result to credential_approve() and\n> credential_reject(), which you probably don't want (because you do not\n> want to store these useless dummy credentials in your keystore).\n\nCorrect.\n\n> So I think this hack should remain purely at the curl level, and never\n> touch the credential struct at all.\n> \n> Which is a shame, because I think Eric's suggestion is otherwise much\n> more readable. :)\n\nYes, I agree. That would have been a much nicer and smaller change.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"278204","messageId":"xmqqsi0tpsa5.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"20160215203659.GB57185@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-15T21:39:30Z","receivedAt":"2016-02-15T21:39:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On Mon, Feb 15, 2016 at 03:34:51PM -0500, Jeff King wrote:\n> ...\n>> So I think this hack should remain purely at the curl level, and never\n>> touch the credential struct at all.\n>> \n>> Which is a shame, because I think Eric's suggestion is otherwise much\n>> more readable. :)\n>\n> Yes, I agree. That would have been a much nicer and smaller change.\n\nAlright, reading all reviews and taking them into account, the\noriginal, when a Sign-off is added, would be acceptable, it seems.\n\nThanks.\n"},{"id":"278206","messageId":"20160215214110.GC57185@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"xmqqsi0tpsa5.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-15T21:41:10Z","receivedAt":"2016-02-15T21:41:10Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Feb 15, 2016 at 01:39:30PM -0800, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > On Mon, Feb 15, 2016 at 03:34:51PM -0500, Jeff King wrote:\n> > ...\n> >> So I think this hack should remain purely at the curl level, and never\n> >> touch the credential struct at all.\n> >> \n> >> Which is a shame, because I think Eric's suggestion is otherwise much\n> >> more readable. :)\n> >\n> > Yes, I agree. That would have been a much nicer and smaller change.\n> \n> Alright, reading all reviews and taking them into account, the\n> original, when a Sign-off is added, would be acceptable, it seems.\n\nSorry about that. Please add my\n\nSigned-off-by: brian m. carlson \n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"278210","messageId":"CAPig+cSphEu3iRJrkdBA+BRhi9HnopLJnKOHVuGhUqavtV1RXg@mail.gmail.com","threadId":"41306","inReplyTo":"xmqqsi0tpsa5.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-02-15T21:46:43Z","receivedAt":"2016-02-15T21:46:43Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Feb 15, 2016 at 4:39 PM, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n>> On Mon, Feb 15, 2016 at 03:34:51PM -0500, Jeff King wrote:\n>>> So I think this hack should remain purely at the curl level, and never\n>>> touch the credential struct at all.\n>>>\n>>> Which is a shame, because I think Eric's suggestion is otherwise much\n>>> more readable. :)\n>>\n>> Yes, I agree. That would have been a much nicer and smaller change.\n>\n> Alright, reading all reviews and taking them into account, the\n> original, when a Sign-off is added, would be acceptable, it seems.\n\nOne final question: Keeping in mind my lack of familiarity with this\nparticular use-case, would it be possible to infer the need to employ\nthis curl-specific workaround rather than making users tweak a config\nsetting? Or would that be a security risk or an otherwise stupid idea?\n"},{"id":"278216","messageId":"20160215215157.GD57185@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"CAPig+cSphEu3iRJrkdBA+BRhi9HnopLJnKOHVuGhUqavtV1RXg@mail.gmail.com","subject":"Re: [PATCH] http: add option to try authentication without username","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-15T21:51:57Z","receivedAt":"2016-02-15T21:51:57Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Feb 15, 2016 at 04:46:43PM -0500, Eric Sunshine wrote:\n> On Mon, Feb 15, 2016 at 4:39 PM, Junio C Hamano wrote:\n> > \"brian m. carlson\" writes:\n> >> On Mon, Feb 15, 2016 at 03:34:51PM -0500, Jeff King wrote:\n> >>> So I think this hack should remain purely at the curl level, and never\n> >>> touch the credential struct at all.\n> >>>\n> >>> Which is a shame, because I think Eric's suggestion is otherwise much\n> >>> more readable. :)\n> >>\n> >> Yes, I agree. That would have been a much nicer and smaller change.\n> >\n> > Alright, reading all reviews and taking them into account, the\n> > original, when a Sign-off is added, would be acceptable, it seems.\n> \n> One final question: Keeping in mind my lack of familiarity with this\n> particular use-case, would it be possible to infer the need to employ\n> this curl-specific workaround rather than making users tweak a config\n> setting? Or would that be a security risk or an otherwise stupid idea?\n\nIt's not very easy to infer whether it's needed. We'd need to know what\ntypes of authentication are offered, and somehow we'd have to intuit\nproper behavior when both GSS-Negotiate and Basic are enabled. Some\nsites do that because you can use Basic against the Kerberos database.\nOne user might legitimately want to always use Basic (e.g. with a\npassword manager) and another might always want to use Negotiate.\nSetting this option is one way to ensure the latter.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"278734","messageId":"CAHdYDCryaCbj-s6LG5fcDu115fi0k_uCawtus81PPbgyWpBTSA@mail.gmail.com","threadId":"41306","inReplyTo":"CAHdYDCq+MiAJoCPFd3Qn9VjAzoii8QgTOOV7HXEV8OdzW-dgPQ@mail.gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Dmitry Vilkov","fromEmail":"dmitry.a.vilkov@gmail.com","sentAt":"2016-02-20T14:35:19Z","receivedAt":"2016-02-20T14:35:19Z","isPatch":true,"sender":{"key":"dmitry.a.vilkov@gmail.com","avatar":null},"body":"Hi guys! Any luck with fixing this issue?\n\nI would like to draw your attention to the fact that Git starting from\nversion 2.3.1 is unusable with servers that support GSS-Negotiation\n(e.g. Microsoft TFS).\n\nSorry, english is not my native language and probably I was not clear\nenough when described the problem at first time.\n\nSo, let me try again. Algorithm of fetching data through HTTP(S)\nprotocol is as follows:\n1. Try to fetch data without any credentials.\n2. If first step failed\n 2.1. Disable GSS-Negotiation algorithm (this is the side effect\nwhich is fixed by my patch).\n 2.2. Read credentials from config files.\n 2.3. If there is no credentials then ask user for it.\n 2.4. Go to step one, but now try to fetch data with found/provided\ncredentials.\n\nAs you can see there is no other way to connect to server with\nGSS-Negotiation auth than use URLs like\n\"https://:@my-gss-git-server.com\" (because there is step zero where we\nare parsing URL which can contain credentials that we can use in step\none).\n\nMaybe you could accept my patch, so users would use\n\"credential.helper=store\" to avoid using \":@\" in remote URL? At least\nfor now, while there is no good solution to this issue? It would be\nvery helpful because now we have to have our own version of patched\nGit :(\n\nThanks in advance.\n\n\n2016-02-08 12:11 GMT+03:00 Dmitry Vilkov :\n> 2016-02-06 0:52 GMT+03:00 Junio C Hamano :\n>> \"brian m. carlson\" writes:\n>>\n>>> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote:\n>>>> Hmph, so documenting that :@\n>>>> as a supported way might be an ugly-looking solution to the original\n>>>> problem. A less ugly-looking solution might be a boolean that can\n>>>> be set per URL (we already have urlmatch-config infrastructure to\n>>>> help us do so) to tell us to pass the empty credential to lubCurl,\n>>>> bypassing the step to ask the user for password that we do not use.\n>>>>\n>>>> The end-result of either of these solution would strictly be better\n>>>> than the patch we discussed in that the end user will not have to\n>>>> interact with the prompt at all, right?\n>>>\n>>> Yes, that's true. I'll try to come up with a patch this weekend that\n>>> implements that (maybe remote.forceAuth = true or somesuch).\n>>\n>> Thanks.\n>>\n>> I think the configuration should live inside http.* namespace, as\n>> there are already things like http[.].sslCert and friends.\n>>\n>> I do not have a good suggestion on the name of the leaf-level\n>> variable. ForceAuth sounds as if you are forcing authentication\n>> even when the other side does not require it, though.\n>\n> That would be great! Definitely it will be much better solution than\n> patch I've proposed.\n"},{"id":"278736","messageId":"20160220152351.GD14569@vauxhall.crustytoothpaste.net","threadId":"41306","inReplyTo":"CAHdYDCryaCbj-s6LG5fcDu115fi0k_uCawtus81PPbgyWpBTSA@mail.gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2016-02-20T15:23:51Z","receivedAt":"2016-02-20T15:23:51Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sat, Feb 20, 2016 at 05:35:19PM +0300, Dmitry Vilkov wrote:\n> Maybe you could accept my patch, so users would use\n> \"credential.helper=store\" to avoid using \":@\" in remote URL? At least\n> for now, while there is no good solution to this issue? It would be\n> very helpful because now we have to have our own version of patched\n> Git :(\n\nI sent in a patch (and I believe I CC'd you) that adds an option\nhttp.emptyAuth that can be used in this case. It should make its way to\na future release.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"278741","messageId":"xmqqk2lz9i66.fsf@gitster.mtv.corp.google.com","threadId":"41306","inReplyTo":"CAHdYDCryaCbj-s6LG5fcDu115fi0k_uCawtus81PPbgyWpBTSA@mail.gmail.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-20T21:38:09Z","receivedAt":"2016-02-20T21:38:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Vilkov writes:\n\n> Hi guys! Any luck with fixing this issue?\n\nI think Brian suggested an alternative approach, to which you earler\nresponded\n\n>> That would be great! Definitely it will be much better solution than\n>> patch I've proposed.\n\nThe patch has been queued as 121061f6 (http: add option to try\nauthentication without username, 2016-02-15); perhaps you can help\nby trying it out in your installation before it hits a released\nversion of Git? That way, if the patch does not fix your problem,\nor it introduces an unexpected side effect, we would notice before\nwe include it in a future release.\n\nThanks.\n"},{"id":"279347","messageId":"CAHdYDCqM0dhjs0vYmuHmbU3Pr=Wmfp_7GbgXGsRcbT+TgX10vA@mail.gmail.com","threadId":"41306","inReplyTo":"xmqqk2lz9i66.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate","fromName":"Dmitry Vilkov","fromEmail":"dmitry.a.vilkov@gmail.com","sentAt":"2016-02-25T16:54:21Z","receivedAt":"2016-02-25T16:54:21Z","isPatch":true,"sender":{"key":"dmitry.a.vilkov@gmail.com","avatar":null},"body":"Hi, guys!\n\n> I sent in a patch (and I believe I CC'd you) that adds an option\n> http.emptyAuth that can be used in this case. It should make its way to\n> a future release.\n\nSomehow I've missed your letter...\n\n> The patch has been queued as 121061f6 (http: add option to try\n> authentication without username, 2016-02-15); perhaps you can help\n> by trying it out in your installation before it hits a released\n> version of Git? That way, if the patch does not fix your problem,\n> or it introduces an unexpected side effect, we would notice before\n> we include it in a future release.\n\nI've cherry-picked commit 121061f6 over version 2.4.10 and 2.7.1.\nIn both cases it works exactly as expected.\n\nPlease, let me know if I can help with something else regarding this issue.\n\n2016-02-21 0:38 GMT+03:00 Junio C Hamano :\n> Dmitry Vilkov writes:\n>\n>> Hi guys! Any luck with fixing this issue?\n>\n> I think Brian suggested an alternative approach, to which you earler\n> responded\n>\n>>> That would be great! Definitely it will be much better solution than\n>>> patch I've proposed.\n>\n> The patch has been queued as 121061f6 (http: add option to try\n> authentication without username, 2016-02-15); perhaps you can help\n> by trying it out in your installation before it hits a released\n> version of Git? That way, if the patch does not fix your problem,\n> or it introduces an unexpected side effect, we would notice before\n> we include it in a future release.\n>\n> Thanks.\n>\n"}]}