Kyle Neath venit, vidit, dixit 07.09.2011 07:33: > Earlier today, Scott Chacon alerted me to this email thread: > http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I > am not sure how to properly reference this email or reply to it since I have > not been subscribed until today). > >> * jk/http-auth-keyring (2011-08-03) 13 commits >> (merged to 'next' on 2011-08-03 at b06e80e) >> + credentials: add "getpass" helper >> + credentials: add "store" helper >> + credentials: add "cache" helper >> + docs: end-user documentation for the credential subsystem >> + http: use hostname in credential description >> + allow the user to configure credential helpers >> + look for credentials in config before prompting >> + http: use credential API to get passwords >> + introduce credentials API >> + http: retry authentication failures for all http requests >> + remote-curl: don't retry auth failures with dumb protocol >> + improve httpd auth tests >> + url: decode buffers that are not NUL-terminated >> >> Looked mostly reasonable except for the limitation that it is not clear >> how to deal with a site at which a user needs to use different passwords >> for different repositories. Will keep it in "next" at least for one cycle, >> until we start hearing real-world success reports on the list. >> >> Not urgent; will not be in 1.7.7. > > This is very disheartening to hear. Of all the minor changes, bugs, and > potential features, I believe that http credential caching is the absolute > most important thing that git core can do to promote adoption. I've believed > this for more than a year now and I'm incredibly disappointed that it's being > shelved for yet another release. > > Over the past two years as a designer for GitHub, I've answered ~thousands of > support requests and talked face to face with ~thousands of developers of > varying git skill levels. Once a month our company does online git training > for newbies - https://github.com/training/online and I've had many discussions > about newcomer's struggles with Matthew McCullough and Scott Chacon. > Previously, I worked at ENTP where I helped polish the very popular "Git for > Designers" guide http://hoth.entp.com/output/git_for_designers.html based on > feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at > people less familiar with the command line. So, it's been a year or more that you've been aware of the importance of this issue (from your/github's perspective), and we hear about it now, at the end of the rc phase. I don't know whether jk/http-auth-keyring has been done on github payroll or during spare time. But as you can see, all that is missing is real-world success reports, along with the single-user-multiple-passwords issue which is probably answered best from the real-world perspective (how common is it, do we even need to address it now). So, given the importance this has for you and the company, you sure can help out with what is still left to do, can you? But note that the credential api is only as good a solution as the helpers. Do we really want all users to employ credential-store because it is "much simpler than ssh"? Deploying what we have now and advocating it as a solution for the ssh-challenged (which will happen whether we, you or someone else advocates it) could easily mean telling people to store their credentials unencrypted. The slash-dot story will be "git security hole", "git stores passwords unencrypted" and so on. And I don't care as much about the PR as about the users whom we'd be serving badly. So, for the ssh-challenged, we really should make sure that secure helpers are in their hand when the credential api hits a released version (or revert the insecure store helper). There's a KDE attempt on the list. Gnome, Win, Mac helpers anyone? Win version of the cache helper? Michael -- 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