Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jan 5, 2015, at 6:53 PM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Mon, Jan 05, 2015 at 09:23:32PM +0000, Dan Langille (dalangil) wrote:
>> I have tried both patches.  Neither succeeds here.  I patched git version 2.2.1 but I don’t think that affects this.
> 
> You are patching the client side, correct?  That's the side that needs patching here.

Yes, I am.

> Just so the list knows, I will be sending a reroll to the existing patch, but the patches I've posted do indeed work in my testing.

I appreciate the patches.  I blame something here.

The patches don’t t apply cleanly to git-2.2.1 or to the latest git source I just cloned.  I had to copy/paste some two chunks in http.c and everything in remote-curl.c.

Looking at the source, the place to patch is there, just on a different line number.

[dvl@porter93 /usr/ports/devel/git/work/git-2.2.1]$ sudo patch < ~dvl/patch2.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/http.c b/http.c
|index 040f362..815194d 100644
|--- a/http.c
|+++ b/http.c
--------------------------
Patching file http.c using Plan A...
Hunk #1 succeeded at 62.
Hunk #2 succeeded at 988 with fuzz 2.
Hunk #3 failed at 1047.
Hunk #4 failed at 1154.
2 out of 4 hunks failed--saving rejects to http.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/http.h b/http.h
|index 473179b..71943d3 100644
|--- a/http.h
|+++ b/http.h
--------------------------
Patching file http.h using Plan A...
Hunk #1 succeeded at 98 with fuzz 2.
Hunk #2 succeeded at 114.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/remote-curl.c b/remote-curl.c
|index dd63bc2..4ca5447 100644
|--- a/remote-curl.c
|+++ b/remote-curl.c
--------------------------
Patching file remote-curl.c using Plan A...
Hunk #1 failed at 467.
Hunk #2 failed at 513.
Hunk #3 failed at 538.
Hunk #4 failed at 625.
4 out of 4 hunks failed--saving rejects to remote-curl.c.rej
done


>> Before I flood the list with debug runs, I wanted to make sure I was testing with an appropriate configuration:
>> 
>> <Location /git>
>> SSLOptions +StdenvVars
>> Options +ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
>> 
>>  # By default, allow access to anyone.
>>  Order allow,deny
>>  Allow from All
>> 
>>  # Enable Kerberos authentication using mod_auth_kerb.
>> AuthType           Kerberos
>> AuthName           “us.example.org"
>> KrbAuthRealms      us.example.org
>> # I have tried both with and without the following line:
>> KrbServiceName     HTTP/us.example.org
>> Krb5Keytab         /usr/local/etc/apache22/repo-test.keytab
>>  KrbMethodNegotiate on
>>  KrbSaveCredentials on
>>  KrbVerifyKDC on
>>  KrbServiceName Any
>> # I have tried with and without this line:
>> KrbMethodk5Passwd  on
>>  Require valid-user
>> </Location>
> 
> I'm not sure why it's not working for you.  Here's a snippet from my config:
> 
> SetEnv GIT_HTTP_EXPORT_ALL 1
> SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
> AuthType Kerberos
> AuthName "Kerberos Login"
> KrbMethodNegotiate on
> KrbMethodK5Passwd off
> KrbAuthRealms CRUSTYTOOTHPASTE.NET
> Krb5Keytab /etc/krb5.apache.keytab
> 
> When I was testing, I set KrbMethodK5Passwd to on and it did in fact work.  I'm using Debian's Apache 2.4.10-9 with mod_auth_kerb 5.4-2.2.

That didn’t seem to help, but perhaps the patching is the issue.



��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]