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@xxxxxxxxxxx/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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html