From: Junio C Hamano <hidden> Date: 2016-06-15 23:03:51
"Dan Langille (dalangil)" [off-list ref] writes:
quoted
On Jan 20, 2015, at 7:22 PM, Junio C Hamano [off-list ref] wrote:
"Dan Langille (dalangil)" [off-list ref] writes:
quoted
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.
From: Dan Langille (dalangil) <hidden> Date: 2016-06-15 23:03:51
On Feb 17, 2015, at 6:36 PM, Junio C Hamano [off-list ref] wrote:
"Dan Langille (dalangil)" [off-list ref] writes:
quoted
quoted
On Jan 20, 2015, at 7:22 PM, Junio C Hamano [off-list ref] wrote:
"Dan Langille (dalangil)" [off-list ref] writes:
quoted
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.
From: brian m. carlson <hidden> Date: 2016-06-15 23:03:52
On Wed, Feb 18, 2015 at 04:17:46PM +0000, 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
From: Dan Langille (dalangil) <hidden> Date: 2016-06-15 23:03:54
On Feb 19, 2015, at 3:35 PM, brian m. carlson [off-list ref] wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +0000, Dan Langille (dalangil) wrote:
quoted
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.
From: Dan Langille (dalangil) <hidden> Date: 2016-06-15 23:03:55
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) [off-list ref] wrote:
quoted
On Feb 19, 2015, at 3:35 PM, brian m. carlson [off-list ref] wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +0000, Dan Langille (dalangil) wrote:
quoted
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
$
From: Dan Langille (dalangil) <hidden> Date: 2016-06-15 23:04:07
On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil) [off-list ref] wrote:
quoted
On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) [off-list ref] wrote:
quoted
On Feb 19, 2015, at 3:35 PM, brian m. carlson [off-list ref] wrote:
On Wed, Feb 18, 2015 at 04:17:46PM +0000, Dan Langille (dalangil) wrote:
quoted
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.
From: brian m. carlson <hidden> Date: 2016-06-15 23:04:07
On Tue, Mar 10, 2015 at 06:05:46PM +0000, Dan Langille (dalangil) wrote:
quoted
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://bmc@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
From: Dan Langille (dalangil) <hidden> Date: 2016-06-15 23:04:08
On Mar 10, 2015, at 6:29 PM, brian m. carlson [off-list ref] wrote:
On Tue, Mar 10, 2015 at 06:05:46PM +0000, Dan Langille (dalangil) wrote:
quoted
quoted
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
quoted
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://bmc@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.
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
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.