On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. > 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. :-( > 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] > 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 -- 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