[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From:       Jay Soffian <jaysoffian () gmail ! com>
Date:       2011-09-30 22:42:22
Message-ID: CAG+J_Dww1yOeq1LHQYMiObPKqrWbk4t8Hn=G9WpYWXFBbHiuhQ () mail ! gmail ! com
[Download RAW message or body]

On Fri, Sep 30, 2011 at 6:11 PM, Jeff King <peff@peff.net> wrote:
> Because security prompts sometimes are out of band. In particular,
> you're already interacting with the user outside of the terminal;
> opening the keychain will get you an "allow git to open the keychain"
> dialog.

Usually it won't. In the default case, the keychain is unlocked and no
permission is needed to add an entry, nor to retrieve that entry by
the application which added it. The prompt will only occur if the
credential helper is not on the entry's ACL, or if the keychain is
locked.

> Another example: if you're running gpg-agent, and you run "git tag -s",
> you'll be prompted for your key passphrase in an out-of-band dialog.
>
> Maybe it doesn't make sense for the actual username/password, though.

Personally, it made sense to me do it at the CLI (obviously). But the
source code in in contrib now. :-)

> I meant running sshd on OS X, and then ssh-ing in from some other box.
> Your credential helper doesn't seem to work at all (I guess because it
> has no access to the keychains). I don't think it's a big deal, though.
> It's the minority case, and if somebody wants to figure out how to make
> it work later, they can.

As far as I know there's no way to make this work. When you login over
ssh, it's a different security context, and there is no access to the
password field of keychain entries.

>> I found it ugly that git's native getpass doesn't echo the username
>> back, and it seems hackish to me for the credential helper to turn
>> back around and invoke it in any case. :-(
>
> Yes, but I think that's a bug that should be fixed in git. :)

Yes it should. :-)

> As far as being hack-ish, the original design was that you could chain
> these things if you wanted. But in practice, I don't know how useful
> that is. In fact, after all of this discussion, I'm wondering how useful
> it is that the helpers are allowed to prompt themselves at all.
>
> The KDE one does it. But would people be happier if git simply did:
>
>  1. ask the helper for a credential. if we get it, done
>
>  2. prompt the user
>
>  3. if the credential is valid, ask the helper to store
>
> That's way less flexible. But it also makes the helpers really simple.

I think that actually makes more sense. There's already an existing
mechanism to customized (2) via GIT_ASKPASS, right? So it overlaps for
the credential helper to do that doesn't it?

> Because the helper might have an alternate way of asking for the
> password (e.g., the KDE helper has its own dialog). Maybe it will never
> be useful. I just wanted to future-proof helpers by giving them sane
> behavior for this case, on the off chance that future versions of git do
> actually do this.
>>
> Don't get me wrong; I think you did the only sane thing. It was more
> "Hmm, I was hoping that the right way to use the various security APIs
> wouldn't need to...". And clearly my hope was wrong. :)
>
> But this is exactly the sort of feedback I was hoping for; the interface
> to the helpers could be better, and we are catching it now.

Okay, the more I think about this, the more I think the existing
design is both too much (asking the credential helper to do anything
other than store/retrieve passwords) and too little (not breaking out
the fields distinctly).

> That's not an unreasonable attitude. I mostly let the browser store
> passwords, but sometimes override it for specific sites. But in this
> case, I think it would be more per-repo. And you can turn off the helper
> for a particular repo (actually, I'm not sure you can, but you probably
> should be able to).

If the credential helper becomes no more than a store/retrieve, it's
git that would do the prompting "Store credentials via
git-osxkeychain?" after logging in successfully with the credentials.

>> It is for security reasons. 99% of users will probably just click

> Anyway, that's neither here nor there. It would be nice if we could set
> the text, but if we can't, then we'll have to live with it.

The C version of the helper will use the name of the helper binary.

j.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]