Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com
wrote:
On Feb 19, 2015, at 3:35 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
I just built from ‘master’, on FreeBSD 9.3:
cd ~/src
git clone https://github.com/git/git.git
cd git
gmake
Then tried ~/src/git/git clone https://OUR_REPO
It cores too, and I see: git-remote-https.core
Can you compile with debugging symbols and provide a backtrace? I'm not
seeing any such behavior on my end, and I'm not sure whether it's my
patch or something else that might be present in master.
The problem originally occurred under VMware Fusion and I’m unable to get a
backtrace from it.
I suspect memory constraints are a factor. There’s only 5GB RAM available
to this VM.
I have tried in another VM and that succeeds. All good there. It has 40GB
RAM.
I am going to try this on a third system. At present, we’re just 50/50 on
success.
We have made progress I think.
With stock git:
tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds.
2 - without a ticket, nothing works
With patched git:
tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter,
failure
If I have a valid ticket, why am I being prompted for credentials?
It appears patched git always wants credentials entered and ignores the valid
ticket.
2 - without a ticket, entering credentials, SUCCEEDS
Here is my test, with a valid kerberos ticket:
$ git clone https://git.example.com/git/clamav-bytecode-compiler
Cloning into 'clamav-bytecode-compiler'...
Username for 'https://git.example.com':
Password for 'https://git.example.com':
^Cmote: Counting objects: 224546
$
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Tue, Mar 10, 2015 at 06:05:46PM +, Dan Langille (dalangil) wrote: We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure If I have a valid ticket, why am I being prompted for credentials? libcurl won't even attempt authentication if you don't have a username specified. I know that the web server should be able to figure it out from your credentials, so it shouldn't matter what username you provide. This is an unfortuate quirk of lib curl. I understand. Also, are you using 2.3.0, or one of the earlier patched versions? That might affect how it works. I am using git-2.3.0 It appears patched git always wants credentials entered and ignores the valid ticket. So what I think is happening is that you didn't specify a username, but git got a 401, so it prompted. Now it actually attempts to use the password you provided, whereas before it did not. Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? Thank you for your help in getting us this far. This helps us tremendously. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Mar 11, 2015, at 5:59 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? You might try looking at git config --help. It looks like there's a credential.username option that might do what you want. Brian et al, Thank you for your help and patience with this. It is appreciated. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git Yes, that does work. Our project is 98% of the way there now. I looked at both libcurl and git environment variables to see if there was a way to specify the user without putting it in the URL. I didn’t see one. My next step is the git configuration, either server or client. Do you know if I should stop looking now because it’s not there? You might try looking at git config --help. It looks like there's a credential.username option that might do what you want. -- 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
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Tue, Mar 10, 2015 at 06:05:46PM +, Dan Langille (dalangil) wrote: We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure If I have a valid ticket, why am I being prompted for credentials? libcurl won't even attempt authentication if you don't have a username specified. I know that the web server should be able to figure it out from your credentials, so it shouldn't matter what username you provide. This is an unfortuate quirk of libcurl. Also, are you using 2.3.0, or one of the earlier patched versions? That might affect how it works. It appears patched git always wants credentials entered and ignores the valid ticket. So what I think is happening is that you didn't specify a username, but git got a 401, so it prompted. Now it actually attempts to use the password you provided, whereas before it did not. Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git -- 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
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. The problem originally occurred under VMware Fusion and I’m unable to get a backtrace from it. I suspect memory constraints are a factor. There’s only 5GB RAM available to this VM. I have tried in another VM and that succeeds. All good there. It has 40GB RAM. I am going to try this on a third system. At present, we’re just 50/50 on success. We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering credentials, SUCCEEDS; just hit enter, failure 2 - without a ticket, entering credentials, SUCCEEDS Here is my test, with a valid kerberos ticket: $ git clone https://git.example.com/git/clamav-bytecode-compiler Cloning into 'clamav-bytecode-compiler'... Username for 'https://git.example.com': Password for 'https://git.example.com': ^Cmote: Counting objects: 224546 $
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. The problem originally occurred under VMware Fusion and I’m unable to get a backtrace from it. I suspect memory constraints are a factor. There’s only 5GB RAM available to this VM. I have tried in another VM and that succeeds. All good there. It has 40GB RAM. I am going to try this on a third system. At present, we’re just 50/50 on success. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you compile with debugging symbols and provide a backtrace? I'm not seeing any such behavior on my end, and I'm not sure whether it's my patch or something else that might be present in master. -- 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
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Feb 17, 2015, at 6:36 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Is this the patch in question? https://github.com/git/git/commit/4dbe66464b4fd695c5989cc272fa0edd6475037c I ask because previous versions of the patch acted against http.h as well and my failure with it. Could I expect that patch work against 2.3.0? It applies cleanly, compiles, but cores when I try a ‘git clone’. Unmatched 2.3.0 succeeds. It already is in 'master', so please holler if things break with that version. I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Is this the patch in question? https://github.com/git/git/commit/4dbe66464b4fd695c5989cc272fa0edd6475037c I ask because previous versions of the patch acted against http.h as well and my failure with it. Could I expect that patch work against 2.3.0? It applies cleanly, compiles, but cores when I try a ‘git clone’. Unmatched 2.3.0 succeeds.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
Dan Langille (dalangil) dalan...@cisco.com writes: On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Is this the patch in question? https://github.com/git/git/commit/4dbe66464b4fd695c5989cc272fa0edd6475037c I ask because previous versions of the patch acted against http.h as well and my failure with it. Could I expect that patch work against 2.3.0? It applies cleanly, compiles, but cores when I try a ‘git clone’. Unmatched 2.3.0 succeeds. It already is in 'master', so please holler if things break with that version. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) Patch v2 has been used in our test environment with success. I got diverted to other projects before I could test Patch v3. I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Thank you. — Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc.
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
I did not test this patch. Is that holding up a commit?
—
Dan Langille
Infrastructure Operations
Talos Group
Sourcefire, Inc.
On Jan 7, 2015, at 7:29 PM, brian m. carlson sand...@crustytoothpaste.net
wrote:
Apache servers using mod_auth_kerb can be configured to allow the user
to authenticate either using Negotiate (using the Kerberos ticket) or
Basic authentication (using the Kerberos password). Often, one will
want to use Negotiate authentication if it is available, but fall back
to Basic authentication if the ticket is missing or expired.
However, libcurl will try very hard to use something other than Basic
auth, even over HTTPS. If Basic and something else are offered, libcurl
will never attempt to use Basic, even if the other option fails.
Teach the HTTP client code to stop trying authentication mechanisms that
don't use a password (currently Negotiate) after the first failure,
since if they failed the first time, they will never succeed.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
Signed-off-by: Jeff King p...@peff.net
---
Peff's original change was to get_curl_handle; however, we retry the
second time with the same slot and we may not call get_curl_handle
again, so I had to move that change to get_active_slot. This has been
tested pushing with both Negotiate and Basic against an HTTPS server
both when info/refs was protected and when it was not.
http.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/http.c b/http.c
index 040f362..44b130c 100644
--- a/http.c
+++ b/http.c
@@ -62,6 +62,9 @@ static const char *user_agent;
static struct credential cert_auth = CREDENTIAL_INIT;
static int ssl_cert_password_required;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+static unsigned long http_auth_methods = CURLAUTH_ANY;
+#endif
static struct curl_slist *pragma_header;
static struct curl_slist *no_pragma_header;
@@ -580,6 +583,9 @@ struct active_request_slot *get_active_slot(void)
curl_easy_setopt(slot-curl, CURLOPT_UPLOAD, 0);
curl_easy_setopt(slot-curl, CURLOPT_HTTPGET, 1);
curl_easy_setopt(slot-curl, CURLOPT_FAILONERROR, 1);
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, http_auth_methods);
+#endif
if (http_auth.password)
init_curl_http_auth(slot-curl);
@@ -870,6 +876,9 @@ int handle_curl_result(struct slot_results *results)
credential_reject(http_auth);
return HTTP_NOAUTH;
} else {
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ http_auth_methods = ~CURLAUTH_GSSNEGOTIATE;
+#endif
return HTTP_REAUTH;
}
} else {
@@ -986,6 +995,7 @@ static void extract_content_type(struct strbuf *raw,
struct strbuf *type,
strbuf_addstr(charset, ISO-8859-1);
}
+
/* http_request() targets */
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
--
2.2.1.209.g41e5f3a
Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails
Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is queued on the 'next' branch so that others like you who need the change can verify the improvements, and others unlike you who do not need the change can make sure the change does not cause unintended consequences. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
