All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Git ksshaskpass to play nice with https and kwallet
Date: Tue, 04 Oct 2011 14:12:02 +0200	[thread overview]
Message-ID: <4E8AF812.5090906@drmicha.warpmail.net> (raw)
In-Reply-To: <20111004113713.GA19171@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 04.10.2011 13:37:
> On Tue, Oct 04, 2011 at 01:27:57PM +0200, Michael J Gruber wrote:
> 
>> Still, ksshaskpass's trying to guess a unique key from the prompt text
>> seems quite hackish to me. But many people will have a Git without
>> credential-helpers, and a KDE default setup, so hope my post helps
>> someone besides myself.
> 
> Hmm. I don't think that pre-credential-helper git actually puts the
> hostname in the prompt, though. It just says "Username:". So your trick
> wouldn't work then, would it?
> 
>> Note that git-credentials-askpass would have a fair chance of doing
>> better: credential_askpass() knows the username and could pass it to
>> credential_ask_one(), e.g. by amending the description field, or setting
>> the first field to "Password for user %(user)". Do you think that would
>> be worth deviating from the default behavior (i.e. compared to no helper)?
> 
> I think that git should do that by default. v1.7.7 (and earlier) does:
> 
>   $ git push https://example.com/foo.git
>   Username:
>   Password:
> 
> With my patches in 'next', it does:
> 
>   $ git push https://example.com/foo.git
>   Username for 'example.com':
>   Password for 'example.com':
>

Sheesh. I'm too used to using next(+) to even think of that! You're
completely right: My trick only works with next's additions.

> But it would probably be better to say:
> 
>   $ git push https://example.com/foo.git
>   Username for 'example.com':
>   Password for 'user@example.com':

Yes, exactly. credential_askpass() knows what it needs for that.

> The latter is especially useful if you have put a username in your
> ~/.gitconfig, in which case you get:

I'm actually wondering why git can't infer the user from

https://user@host.com

with last week's next, at least.
> 
>   $ git push https://example.com/foo.git
>   Password for 'user@example.com':
> 
> which is a nice reminder. And it would happen to work with your askpass
> magic (I also wonder if it should mention the protocol and the repo, but
> most of the time that isn't relevant, and it does make the prompt harder
> to read).

With the above, I can probably do without any magic: 'example.com' would
be the wallet key for the username (if I let the wallet store it) and
'user@example.com' the key for the password, whether the username comes
from the wallet or from the config. (Again, why not from the URL?)

Michael

  reply	other threads:[~2011-10-04 12:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-04 10:19 Git ksshaskpass to play nice with https and kwallet Michael J Gruber
2011-10-04 10:50 ` Jeff King
2011-10-04 11:27   ` Michael J Gruber
2011-10-04 11:37     ` Jeff King
2011-10-04 12:12       ` Michael J Gruber [this message]
2011-10-04 12:43         ` Jeff King
2011-10-04 18:49           ` Michael J Gruber
2011-10-05 17:55             ` Jeff King
2011-10-05 18:01               ` Jeff King
2011-10-06  6:33                 ` Michael J Gruber
2011-10-06 13:15                   ` [RFC/PATCH] remote-curl: Obey passed URL Michael J Gruber
2011-10-06 13:25                     ` Jeff King
2011-10-06 13:37                       ` Jeff King
2011-10-12 20:51                         ` Michael J Gruber
2011-10-12 21:43                           ` [PATCH] http_init: accept separate URL parameter Jeff King
2011-10-12 21:46                             ` Jeff King
2011-10-12 22:38                               ` Junio C Hamano
2011-10-12 22:46                                 ` Jeff King
2011-10-13  7:26                                   ` Michael J Gruber
2011-10-14  7:40                                     ` [PATCH 0/6] http-auth-early Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 1/6] url: decode buffers that are not NUL-terminated Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 2/6] improve httpd auth tests Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 3/6] remote-curl: don't retry auth failures with dumb protocol Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 4/6] http: retry authentication failures for all http requests Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 5/6] http: use hostname in credential description Michael J Gruber
2011-10-14  7:40                                       ` [PATCH 6/6] http_init: accept separate URL parameter Michael J Gruber
2011-10-14 13:19                                       ` [PATCH 0/6] http-auth-early Jeff King
2011-10-14 13:24                                         ` Michael J Gruber
2011-10-14 18:59                                         ` Junio C Hamano
2011-10-13  2:06                             ` [PATCH] http_init: accept separate URL parameter Tay Ray Chuan

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=4E8AF812.5090906@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.