Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Hi, guys! > I sent in a patch (and I believe I CC'd you) that adds an option > http.emptyAuth that can be used in this case. It should make its way to > a future release. Somehow I've missed your letter... > The patch has been queued as 121061f6 (http: add option to try > authentication

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Dmitry Vilkov writes: > Hi guys! Any luck with fixing this issue? I think Brian suggested an alternative approach, to which you earler responded >> That would be great! Definitely it will be much better solution than >> patch I've proposed. The patch has been queued

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Sat, Feb 20, 2016 at 05:35:19PM +0300, Dmitry Vilkov wrote: > Maybe you could accept my patch, so users would use > "credential.helper=store" to avoid using ":@" in remote URL? At least > for now, while there is no good solution to this issue? It would be > very helpful because now we have to

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Hi guys! Any luck with fixing this issue? I would like to draw your attention to the fact that Git starting from version 2.3.1 is unusable with servers that support GSS-Negotiation (e.g. Microsoft TFS). Sorry, english is not my native language and probably I was not clear enough when described

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

2016-02-06 0:52 GMT+03:00 Junio C Hamano : > "brian m. carlson" writes: > >> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: >>> Hmph, so documenting that :@ >>> as a supported way might be an ugly-looking solution to the original

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

"brian m. carlson" writes: > On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: >> Hmph, so documenting that :@ >> as a supported way might be an ugly-looking solution to the original >> problem. A less ugly-looking solution might be a boolean that can

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Dmitry Vilkov writes: > 2016-02-03 2:29 GMT+03:00 brian m. carlson : >> 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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

"brian m. carlson" writes: > On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote: >> 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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: > Hmph, so documenting that :@ > as a supported way might be an ugly-looking solution to the original > problem. A less ugly-looking solution might be a boolean that can > be set per URL (we already have urlmatch-config

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote: > 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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

2016-02-03 2:29 GMT+03:00 brian m. carlson : > 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

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Dmitry Vilkov writes: > This is fix of bug introduced by 4dbe66464 commit. That would be 4dbe6646 (remote-curl: fall back to Basic auth if Negotiate fails, 2015-01-08) that appears in v2.3.1 and onward. > The problem is that when username/password combination was not

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Tue, Feb 02, 2016 at 12:37:19PM -0800, Junio C Hamano wrote: > Dmitry Vilkov writes: > > > This is fix of bug introduced by 4dbe66464 commit. > > That would be 4dbe6646 (remote-curl: fall back to Basic auth if > Negotiate fails, 2015-01-08) that appears in v2.3.1

[PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

This is fix of bug introduced by 4dbe66464 commit. The problem is that when username/password combination was not set, the first HTTP(S) request will fail and user will be asked for credentials. As a side effect of first HTTP(S) request, libcurl auth method GSS-Negotiate will be disabled