Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain

From: Jeff King <peff@peff.net>
Date: Oct 4, 2011, 17:48 UTC
Message-ID: <20111004174840.GA31558@sigill.intra.peff.net>
In-Reply-To: <7v39f8d6iq.fsf@alter.siamese.dyndns.org>

On Tue, Oct 04, 2011 at 10:13:33AM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> Now, I would like to start moving the core part of the credential helper
> series to 'master'. Could people summarize what the current status of
> various moving parts are?
> 
> Here is an example of write-up, based on my understanding (I said it
> should be pretty-much ready, but please correct me if I am mistaken).
> 
>  - The core part have seen some updates while it was cooking in 'next',
>    with help from inputs by credential plug-in authors. The API and the
>    sample implementation should be stable enough that it can be given to
>    people who follow 'master' perhaps with 'experimental, minor details
>    still subject to change' label attached.

No, sadly I don't think we're there yet. The two big open questions are:

  1. Should we be giving more context details to the helpers, and/or
     should we be breaking down the information into pieces?

     I think the answer is probably yes. Certainly OS X would benefit
     from the broken-down pieces. My feeling is that we could hand
     helpers both broken-down pieces as well as an inclusive URL. So
     something like:

       git credential-foo \
         --type=network --protocol=https --host=example.com \
         --username=user1 --path=repo.git \
         --url=https://user1@example.com/repo.git

     and then the helper can pick what it likes from there.

     One thing I haven't figured out is how the user would tell git "no,
     the repo path is not relevant for determining the auth domain".
     That feature can come later, but I want to make sure that helpers
     know they might or might not get the "--path" option. I guess that
     is just a matter of documentation; I'm just a little nervous
     committing to it without having figured out the details.

  2. There has been some talk that the helper interface should perhaps
     be vastly simplified from "get the credentials and give them to
     git" to merely being a store/retrieve system, where the invocations
     would be something like (pretend git is the shell):

       # git asks if we have a stored credential
       git credential-foo --get --url=...,etc | read password

       # we had a successful authentication; ask the helper to store it;
       echo password | git credential-foo --put --url=...,etc

     That makes the helpers much simpler, and makes interacting with the
     user more uniform across helpers.

     It disallows helpers doing specialized interactions or dialogs. I'm
     not sure how much we want that. I thought some systems might find
     that more natural, but that's debatable. Jay implemented a git-like
     pure-terminal prompt in his helper. Lukas used the kde
     password-dialog for the KDE helper. I'm not sure what people really want.

I can produce patches for both if we want to see what they would look like. But I kind of think it's not a matter of "what will the code look like" (both of them are pretty straightforward to implement), but "what do we want the interface to look like". And that is really as much up to me as to people who are going to write and use the helpers.

-Peff