public inbox for git@vger.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 13:27:57 +0200	[thread overview]
Message-ID: <4E8AEDBD.4070404@drmicha.warpmail.net> (raw)
In-Reply-To: <20111004105008.GA11789@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 04.10.2011 12:50:
> On Tue, Oct 04, 2011 at 12:19:59PM +0200, Michael J Gruber wrote:
> 
>> But Git calls the askpass helper with a command line like
>> /usr/bin/ksshaskpass Username for 'bitbucket.org':
>> and once again with
>> /usr/bin/ksshaskpass Password for 'bitbucket.org':
>> So far so good.
>>
>> But when asked to store the credentials in the KDE wallet, ksshaskpass
>> tries (too) hard to guess a good key from that line. And for both
>> invocations, it comes up with the same key (the URL), so that when the
>> password info is needed, the username info from the wallet is returned.
>> Authentication fails.
>> Far from good.
> 
> Neat. I didn't know ksshaskpass would do that. I wondered for a minute
> if all of the credential helper stuff could have gone through the
> askpass interface. But I don't think so.

Don't worry ;)

> One problem is that the askpass interface only lets us ask for one thing
> at a time. So even with your clever hack, it will end up storing two
> separate keys: Username@host and Password@host. But it has no idea
> they're connected. So if you store "user1 / pass1", then try to push to
> "user2@host", we would silently use the password for user1.
> 
> On top of that, there isn't much contextual information. I guess they
> assumed the guessing would be used for "ssh". But it means that a stored
> ssh password could potentially be used for git, and vice versa. I guess
> you could get around that by making the host field longer and more
> descriptive (i.e., a full url).

I think it's really meant for ssh keys only, where the keyid identifies
the key uniquely.

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.

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)?

Cheers,
Michael

  reply	other threads:[~2011-10-04 11:28 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 [this message]
2011-10-04 11:37     ` Jeff King
2011-10-04 12:12       ` Michael J Gruber
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=4E8AEDBD.4070404@drmicha.warpmail.net \
    --to=git@drmicha$(echo .)warpmail.net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=peff@peff$(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