public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Dmitry Vilkov <dmitry.a.vilkov@gmail•com>
Cc: "brian m. carlson" <sandals@crustytoothpaste•net>,
	git@vger•kernel.org, daniel@haxx•se
Subject: Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate
Date: Fri, 05 Feb 2016 09:54:50 -0800	[thread overview]
Message-ID: <xmqq60y3dout.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAHdYDCqtNQMoU3Gu2AcSEWM5wA0SbaMrivu3WV_-N+B-F67v1Q@mail.gmail.com> (Dmitry Vilkov's message of "Fri, 5 Feb 2016 12:18:22 +0300")

Dmitry Vilkov <dmitry.a.vilkov@gmail•com> writes:

> 2016-02-03 2:29 GMT+03:00 brian m. carlson <sandals@crustytoothpaste•net>:
>> 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 to do authentication.
>>
>> Are you basically using a bare URL (without a username component) and
>> waiting for git to prompt you for the username, so that it will then
>> enable authentication?  If so, this patch looks fine for that, although
>> I'd expand on the commit message.  If not, could you provide an example
>> of what you're trying to do?
>
> 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 prohibits doing such thing.
>
> Anyway, as you said libcurl needs valid (not NULL) username/password
> to do GSS-Negotiate, so there is nothing wrong if I set empty
> username/password combination when git prompts for creds. 

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 how this would work in that use case, but I haven't
convinced myself that the change would not affect other existing use
cases that are supported--do you think of any that would negatively
affect the user expeerience?

> Even more,
> there is no other way to let libcurl to use GSS-Negotiate without
> username in URL.

Asking lubcurl expert about that might not be a bad idea; Cc'ed
Daniel Stenberg.

  reply	other threads:[~2016-02-05 17:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-02  9:11 [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate Dmitry Vilkov
2016-02-02 20:37 ` Junio C Hamano
2016-02-02 23:29   ` brian m. carlson
2016-02-05  9:18     ` Dmitry Vilkov
2016-02-05 17:54       ` Junio C Hamano [this message]
2016-02-05 20:58         ` brian m. carlson
2016-02-06 17:53         ` Daniel Stenberg
2016-02-05 20:46       ` brian m. carlson
2016-02-05 21:02         ` Junio C Hamano
2016-02-05 21:06           ` brian m. carlson
2016-02-05 21:52             ` Junio C Hamano
2016-02-08  9:11               ` Dmitry Vilkov
2016-02-15 18:44                 ` [PATCH] http: add option to try authentication without username brian m. carlson
2016-02-15 20:19                   ` Eric Sunshine
2016-02-15 20:29                     ` brian m. carlson
2016-02-15 20:34                       ` Jeff King
2016-02-15 20:36                         ` brian m. carlson
2016-02-15 21:39                           ` Junio C Hamano
2016-02-15 21:41                             ` brian m. carlson
2016-02-15 21:46                             ` Eric Sunshine
2016-02-15 21:51                               ` brian m. carlson
2016-02-20 14:35                 ` [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate Dmitry Vilkov
2016-02-20 15:23                   ` brian m. carlson
2016-02-20 21:38                   ` Junio C Hamano
2016-02-25 16:54                     ` Dmitry Vilkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq60y3dout.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=daniel@haxx$(echo .)se \
    --cc=dmitry.a.vilkov@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=sandals@crustytoothpaste$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox