On Tue, 13 Sep 2011 04:29:30 -0400 John Szakmeister <john@xxxxxxxxxxxxxxx> wrote: JS> 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? JS> Originally I was going to use SecKeychainFindGenericPassword(), and JS> the token would have been the "serviceName". However, JS> SecKeychainFindInternetPassword() is clearly the better fit, which JS> means busting out the individual bits. I would make it work like Safari, period. JS> [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. JS> 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. JS> Ooh... yeah, I'm not sure. :-( I posted a simple proposal for auth domains, which would introduce an extra abstraction layer between the URL and the credential helper. I think that would help. >> 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). JS> That seems burdensome. There is a method in HTTP/HTTPS for saying JS> "use this set of credentials". You'd do that via the security domain. JS> That doesn't necessarily apply to other urls (ssh, for example), but JS> it would allow a storage backend to cache it for a specific path, but JS> fallback to looking up the credential using the security domain. The HTTP security domain is set by the remote, not the Git user, and so is neither customizable nor reliable, unfortunately. Also as you mentioned it won't work for non-HTTP URLs, and it is determined late in the process, perhaps too late for some helpers. Ted -- 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