Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]

From: John Szakmeister <john@szakmeister.net>
Date: Sep 13, 2011, 08:29 UTC
Message-ID: <CAEBDL5UGhanJboiT2SppeXa6UaKbE1MOpajf9wSaQCkR9EdRYw@mail.gmail.com>
In-Reply-To: <20110910065332.GA10935@sigill.intra.peff.net>

On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@peff.net> wrote:

Show 10 quoted lines

> On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:
>
>> A little feedback here: I do look into my keychain on Mac OS X.  I
>> tend to keep most of my credentials in a separate keychain that gets
>> whenever my computer sleeps or the screen saver kicks on.  So that
>> blob ends up being user-visible to some degree.  Could I munge it into
>> something else?  Sure.  But I do wonder if it might be better to make
>> it something closer to what the user expects to see.
>
> Sure, I agree. I guess my question is: what does the user expect to see?

Originally I was going to use SecKeychainFindGenericPassword(), and the token would have been the "serviceName". However, SecKeychainFindInternetPassword() is clearly the better fit, which means busting out the individual bits.

[snip]

> Perhaps it's worth providing the information in two forms: parsed and
> broken out by individual pieces, and as a more opaque blob. Then systems
> which care can use the pieces, and systems which are trying to be as
> simple as possible can use the blob.

That would be useful.  Right now, it looks like I'll be parsing the token.

Show 7 quoted lines

> That still leaves the question of how the user specifies policy about
> which parts of the blob are relevant. That is, how do they say that only
> the "domain" portion of the hostname is relevant? Or that the path is or
> is not relevant?
>
> I was really hoping for the user to be able to specify this at the git
> level, to give each storage helper roughly the same feature set.

Ooh... yeah, I'm not sure. :-(

Show 9 quoted lines

> Maybe it would be enough to do something like:
>
>  1. Assemble all of the parts (protocol, username (if any), hostname,
>     path) into a canonicalized URL representing the authentication
>     context.
>
>  2. Look for git config matching the context URL, and allow
>     transformations (e.g., match and replace the whole thing, or even
>     regexp-style substitution).

That seems burdensome.  There is a method in HTTP/HTTPS for saying
"use this set of credentials".  You'd do that via the security domain.
 That doesn't necessarily apply to other urls (ssh, for example), but
it would allow a storage backend to cache it for a specific path, but
fallback to looking up the credential using the security domain.

[snip]

Show 10 quoted lines

> I think this is somewhat outside the boundaries of what git can provide.
> We don't know whether we are interactive or not; we can only make
> guesses based on things like whether there is a terminal available. The
> helper should be able to make an even better guess, because it can ask
> for system-specific things (e.g., a Linux one might check whether
> $DISPLAY is set before trying to pop up a dialog). And helpers are free
> to simply return nothing. Even though most people will only configure a
> single helper, there is actually a stack, and git will try the next one,
> and so on until it gets an answer (or if it hits the end without an
> answer, will complain).

Okay, I won't worry about it then.  Thanks Jeff!

-John