Re: The imporantance of including http credential caching in 1.7.7

[Michael J Gruber <git@drmicha.warpmail.net>]

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