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

[Jeff King <peff@peff.net>]

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?

> >  https://foo@example.com/specific-repo.git
> >
> > if the user wants a repo-specific authentication context.
> 
> Or pass that the information via --domain and --path parameters.  It'd
> be nice to keep most credential backends from having to parse urls.
> Not that its hard, just cumbersome.  But the keychain implementation
> and the gnome-keyring implementation could both benefit from having
> the pieces broken out separately.  Likewise, it's probably not
> difficult to parse it out of the token if we needed to.

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 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.

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

  3. Break the resulting context URL back into constituent parts.

  4. Give the helper the context URL, and the broken down parts from
     (3). It chooses which to use.

> One thing that crossed my mind while looking at this: what happens
> when a command is meant to be non-interactive?  Looking at the
> kdewallet implementation, it appears that not only is the credential
> helper intended to help do the lookup, but also ask the user for a
> password, if it doesn't find anything.  That doesn't seem like it
> would play well in a non-interactive environment.  Additionally, the
> act of looking up the entry could pop up a dialog in most
> keychain-like applications.  Is there a need to be sensitive to the
> fact that we may be run non-interactively?

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

-Peff