{"thread":{"id":"28321","subject":"The imporantance of including http credential caching in 1.7.7","startedAt":"2011-09-07T05:33:35Z","lastAt":"2011-09-09T18:34:24Z","messageCount":24,"participants":["Kyle Neath","Junio C Hamano","Michael J Gruber","Sverre Rabbelier","Philip Oakley","John Szakmeister","Jeff King","Miles Bader","Ted Zlatanov","Erik Faye-Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174977","messageId":"CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com","threadId":"28321","inReplyTo":null,"subject":"The imporantance of including http credential caching in 1.7.7","fromName":"Kyle Neath","fromEmail":"kneath@gmail.com","sentAt":"2011-09-07T05:33:35Z","receivedAt":"2011-09-07T05:33:35Z","isPatch":false,"sender":{"key":"kneath@gmail.com","avatar":"https://gravatar.com/avatar/a6d0b8d64be4426d382790bb2ff3853548e62d395c1217d421be952bad360e5c?d=mp&s=160"},"body":"Earlier today, Scott Chacon alerted me to this email thread:\nhttp://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I\nam not sure how to properly reference this email or reply to it since I have\nnot been subscribed until today).\n\n> * jk/http-auth-keyring (2011-08-03) 13 commits\n> (merged to 'next' on 2011-08-03 at b06e80e)\n> + credentials: add \"getpass\" helper\n> + credentials: add \"store\" helper\n> + credentials: add \"cache\" helper\n> + docs: end-user documentation for the credential subsystem\n> + http: use hostname in credential description\n> + allow the user to configure credential helpers\n> + look for credentials in config before prompting\n> + http: use credential API to get passwords\n> + introduce credentials API\n> + http: retry authentication failures for all http requests\n> + remote-curl: don't retry auth failures with dumb protocol\n> + improve httpd auth tests\n> + url: decode buffers that are not NUL-terminated\n>\n> Looked mostly reasonable except for the limitation that it is not clear\n> how to deal with a site at which a user needs to use different passwords\n> for different repositories. Will keep it in \"next\" at least for one cycle,\n> until we start hearing real-world success reports on the list.\n>\n> Not urgent; will not be in 1.7.7.\n\nThis is very disheartening to hear. Of all the minor changes, bugs, and\npotential features, I believe that http credential caching is the absolute\nmost important thing that git core can do to promote adoption. I've believed\nthis for more than a year now and I'm incredibly disappointed that it's being\nshelved for yet another release.\n\nOver the past two years as a designer for GitHub, I've answered ~thousands of\nsupport requests and talked face to face with ~thousands of developers of\nvarying git skill levels. Once a month our company does online git training\nfor newbies - https://github.com/training/online and I've had many discussions\nabout newcomer's struggles with Matthew McCullough and Scott Chacon.\nPreviously, I worked at ENTP where I helped polish the very popular \"Git for\nDesigners\" guide http://hoth.entp.com/output/git_for_designers.html based on\nfeedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at\npeople less familiar with the command line.\n\nI bring all of this up because I'd like to think I have a good handle on\ncommon problems that git newcomers or people resisting git adoption run into.\nI've been deeply involved in spreading git adoption full time for nearly 3\nyears - it's something that's incredibly important to me professionally and\npersonally. And the number one problem that *always* comes up is SSH key\ncomplexity.\n\nA lot of these problems surface themselves in people saying it's hard to setup\ngit on Windows. When I push these people to explain further, it turns out that\nthe problem is always setting up SSH key authentication on Windows, not\nnecessarily git.\n\nIt's incredibly frustrating that git's biggest roadblock has nothing to do\nwith version control at all, but rather network authentication. Just as I\nbelieve only *you* can own your availability, I believe git should do it's\nbest to own authentication.\n\nHTTP credential caching combined with Smart HTTP make git one hell of an\namazing tool for newcomers and experts alike. I like to envision a world in\nwhich git with both these features shipped with the latest OSX install.\nDevelopers, designers, or anyone with an inkling for code would have exactly\ntwo steps to get started with any given git host:\n\n 1. Set your git config email / username\n 2. git clone https://example.com/repository\n\nContrast this to our current help page for OSX:\nhttp://help.github.com/mac-set-up-git/ or worse yet, our Windows setup page\nwith all of it's yelling about what kind of SSH keys to setup:\nhttp://help.github.com/win-set-up-git/\n\nPlease note that I am not arguing against the merits of SSH keys - for those\ndevelopers who understand them, they're fantastic. But the reality is the\ngreat majority of people who interact with version control do not understand\nthem at all. This results in passwordless SSH keys, confusion, and\nfrustration.\n\nIf another git version comes and goes without http credential caching, I fear\nwe as a community have purposefully ignored the largest potential for git\nadoption currently available. This is important enough for me that I believe\nit would be in git's best interest to delay the release of 1.7.7 until this\nfeature has been patched to the core team's standards.\n\nI'll summarize with a graph of my opinion of where git's potential for\nadoption lies:\n\n------------------------------------------------------------------------------\n OPPORTUNITY FOR GIT ADOPTION ACCORDING TO KYLE NEATH\n\n Caching of http credentials\n |\n[=====================================================================||=====]\n |\n Everything else in the universe\n\n------------------------------------------------------------------------------\n\nWith hopes and butterflies,\n\nKyle Neath\nDirector of Design at GitHub\n"},{"id":"174998","messageId":"CAGdFq_h3KNuGuhhY2Zv-dHWqAY4Wq3HHBGh2f53rWzDT9PzSgQ@mail.gmail.com","threadId":"28321","inReplyTo":"CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-09-07T07:46:35Z","receivedAt":"2011-09-07T07:46:35Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Sep 7, 2011 at 07:33, Kyle Neath wrote:\n> I'll summarize with a graph of my opinion of where git's potential for\n> adoption lies:\n>\n> ------------------------------------------------------------------------------\n>            OPPORTUNITY FOR GIT ADOPTION ACCORDING TO KYLE NEATH\n>\n>                      Caching of http credentials\n>                                  |\n> [=====================================================================||=====]\n>                                                                          |\n>                                               Everything else in the universe\n>\n> ------------------------------------------------------------------------------\n\nI, personally, find the graph very convincing :).\n\nJunio mentioned in WC that he wants to see some feedback on it's\nusage, perhaps that you can help provide this by providing a git\npatched with this functionality to some of your users and see how they\nrespond?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"175001","messageId":"CAFcyEtihOVz17-3QRZLSNE-4yS2vBHaaUzHng+ciwK0usSm1dA@mail.gmail.com","threadId":"28321","inReplyTo":"CAGdFq_h3KNuGuhhY2Zv-dHWqAY4Wq3HHBGh2f53rWzDT9PzSgQ@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Kyle Neath","fromEmail":"kneath@gmail.com","sentAt":"2011-09-07T08:11:19Z","receivedAt":"2011-09-07T08:11:19Z","isPatch":false,"sender":{"key":"kneath@gmail.com","avatar":"https://gravatar.com/avatar/a6d0b8d64be4426d382790bb2ff3853548e62d395c1217d421be952bad360e5c?d=mp&s=160"},"body":"On Wed, Sep 7, 2011 at 12:46 AM, Sverre Rabbelier wrote:\n> Junio mentioned in WC that he wants to see some feedback on it's\n> usage, perhaps that you can help provide this by providing a git\n> patched with this functionality to some of your users and see how they\n> respond?\n\nPerhaps this is where things get complicated. Due to the nature of the people\nI'm discussing (people afraid of SSH keys), getting them to run a custom\nversion of git is pretty far out of the question. Peff alluded to this in his\nreply.\n\nI think the best evidence I can provide is in context of GitHub for Mac.\nGitHub for Mac defaults to Smart HTTP, with the credentials cached in OSX's\nKeychain. Effectively, it functions as a patched git with credential caching.\n\nTwo months after shipping, we have around 20,000 people that use the\napplication regularly. In that time, we've gotten a ton of positive feedback.\nSo there is a great number of people interested in a git client that uses\nSmart HTTP. One of the bigger complaints we get is that people constantly have\nto enter their username & password if they choose to drop to the command line.\n\nOf course, this is all fuzzy data since it's not really comparable with git\ncore. But it's the only data I have.\n\nThen again, perhaps the fact that we spent development time hacking around\ngit's limitation is a data point in itself. Git GUI developers are spending\ndevelopment time to fill a hole in git core.\n\nKyle\n"},{"id":"174986","messageId":"7vwrdk4mzj.fsf@alter.siamese.dyndns.org","threadId":"28321","inReplyTo":"CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-07T11:21:04Z","receivedAt":"2011-09-07T11:21:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kyle Neath writes:\n\n>> * jk/http-auth-keyring (2011-08-03) 13 commits\n>> ...\n>>\n>> Looked mostly reasonable except for the limitation that it is not clear\n>> how to deal with a site at which a user needs to use different passwords\n>> for different repositories. Will keep it in \"next\" at least for one cycle,\n>> until we start hearing real-world success reports on the list.\n>>\n>> Not urgent; will not be in 1.7.7.\n>\n> This is very disheartening to hear. Of all the minor changes, bugs, and\n> potential features, I believe that http credential caching is the absolute\n> most important thing that git core can do to promote adoption. I've believed\n> this for more than a year now and I'm incredibly disappointed that it's being\n> shelved for yet another release.\n\nYou are misreading the message utterly wrong that it is not even funny.\n\nIf this were a new, insignificant, and obscure feature in a piece of\nsoftware with mere 20k users, it may be OK to release a new version with\nthe feature in an uncooked shape. The feature may turn out to work only in\na very limited scope but not general enough to accomodate other needs you\ndid not anticipate, and your next version may have to fix it in a backward\nincompatible way, forcing existing users to unlearn what the initial\nuncooked design and implementation gave them, but by definition such an\ninsignificant and obscure new feature in a system with a small userbase\nwouldn't have been used by too many people by the time you have to fix it,\nand the extent of the damage is limited.\n\nGit is not that piece of software with only 20k users, and a lot more\nimportantly, credential caching API is not a feature in an insignificant\nand obscure corner of the user experience. We have to have at least a warm\nfuzzy feeling that the API is right from the start so the plug-ins people\nwrite for our initial version and the data its users will accumulate with\nit will not go to waste by hastily releasing a version with an uncooked\ndesign and implementation.\n\n\"Not urgent\" is not \"Not important\". Quite the contrary, it is important\nenough that we cannot afford to be hasty.\n\nSee http://thread.gmane.org/gmane.comp.version-control.git/180245 for an\nexample of how a discussion can be done to help us get closer to the warm\nfuzzy feeling of getting the API right in a more mature manner. Don't feel\ntoo bad if you become ashamed of the rant you wrote contrasting with that\nexchange. It is a sign that you are learning.\n\n> Then again, perhaps the fact that we spent development time hacking around\n> git's limitation is a data point in itself. Git GUI developers are spending\n> development time to fill a hole in git core.\n\nWelcome to open source. Do not expect others to scratch every itch of your\nniche. Think of it as an opportunity granted to you to make a difference,\nnot as a roadblock somebody else threw at you because they hate you.\n\nBe thankful, not whiny.\n\nBe good.\n\nHave fun.\n"},{"id":"174989","messageId":"4E6769E3.4070003@drmicha.warpmail.net","threadId":"28321","inReplyTo":"CAFcyEthzW1AY4uXgpsVxjyWCDXAJ6=GdWGqLFO6Acm1ovJJVaw@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-07T12:56:03Z","receivedAt":"2011-09-07T12:56:03Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Kyle Neath venit, vidit, dixit 07.09.2011 07:33:\n> Earlier today, Scott Chacon alerted me to this email thread:\n> http://www.spinics.net/lists/git/msg164192.html (many apologies to the list, I\n> am not sure how to properly reference this email or reply to it since I have\n> not been subscribed until today).\n> \n>> * jk/http-auth-keyring (2011-08-03) 13 commits\n>> (merged to 'next' on 2011-08-03 at b06e80e)\n>> + credentials: add \"getpass\" helper\n>> + credentials: add \"store\" helper\n>> + credentials: add \"cache\" helper\n>> + docs: end-user documentation for the credential subsystem\n>> + http: use hostname in credential description\n>> + allow the user to configure credential helpers\n>> + look for credentials in config before prompting\n>> + http: use credential API to get passwords\n>> + introduce credentials API\n>> + http: retry authentication failures for all http requests\n>> + remote-curl: don't retry auth failures with dumb protocol\n>> + improve httpd auth tests\n>> + url: decode buffers that are not NUL-terminated\n>>\n>> Looked mostly reasonable except for the limitation that it is not clear\n>> how to deal with a site at which a user needs to use different passwords\n>> for different repositories. Will keep it in \"next\" at least for one cycle,\n>> until we start hearing real-world success reports on the list.\n>>\n>> Not urgent; will not be in 1.7.7.\n> \n> This is very disheartening to hear. Of all the minor changes, bugs, and\n> potential features, I believe that http credential caching is the absolute\n> most important thing that git core can do to promote adoption. I've believed\n> this for more than a year now and I'm incredibly disappointed that it's being\n> shelved for yet another release.\n> \n> Over the past two years as a designer for GitHub, I've answered ~thousands of\n> support requests and talked face to face with ~thousands of developers of\n> varying git skill levels. Once a month our company does online git training\n> for newbies - https://github.com/training/online and I've had many discussions\n> about newcomer's struggles with Matthew McCullough and Scott Chacon.\n> Previously, I worked at ENTP where I helped polish the very popular \"Git for\n> Designers\" guide http://hoth.entp.com/output/git_for_designers.html based on\n> feedback. I was also lead designer for GitHub for Mac - an OSX GUI aimed at\n> people less familiar with the command line.\n\nSo, it's been a year or more that you've been aware of the importance of\nthis issue (from your/github's perspective), and we hear about it now,\nat the end of the rc phase. I don't know whether jk/http-auth-keyring\nhas been done on github payroll or during spare time. But as you can\nsee, all that is missing is real-world success reports, along with the\nsingle-user-multiple-passwords issue which is probably answered best\nfrom the real-world perspective (how common is it, do we even need to\naddress it now). So, given the importance this has for you and the\ncompany, you sure can help out with what is still left to do, can you?\n\nBut note that the credential api is only as good a solution as the\nhelpers. Do we really want all users to employ credential-store because\nit is \"much simpler than ssh\"? Deploying what we have now and advocating\nit as a solution for the ssh-challenged (which will happen whether we,\nyou or someone else advocates it) could easily mean telling people to\nstore their credentials unencrypted. The slash-dot story will be \"git\nsecurity hole\", \"git stores passwords unencrypted\" and so on. And I\ndon't care as much about the PR as about the users whom we'd be serving\nbadly.\n\nSo, for the ssh-challenged, we really should make sure that secure\nhelpers are in their hand when the credential api hits a released\nversion (or revert the insecure store helper). There's a KDE attempt on\nthe list. Gnome, Win, Mac helpers anyone? Win version of the cache helper?\n\nMichael\n"},{"id":"175028","messageId":"CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com","threadId":"28321","inReplyTo":"4E6769E3.4070003@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Kyle Neath","fromEmail":"kneath@gmail.com","sentAt":"2011-09-07T20:14:01Z","receivedAt":"2011-09-07T20:14:01Z","isPatch":false,"sender":{"key":"kneath@gmail.com","avatar":"https://gravatar.com/avatar/a6d0b8d64be4426d382790bb2ff3853548e62d395c1217d421be952bad360e5c?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> If this were a new, insignificant, and obscure feature in a piece of\n> software with mere 20k users, it may be OK to release a new version with\n> the feature in an uncooked shape.\n\nFor the sake of my paycheck, I should certainly hope not! I'm not at all\nsuggesting we merge what we have in. However, I do think this feature is\nimportant enough to delay the release. I trust in the judgement of the core\nmembers to know when something is ready for inclusion in master.\n\nMichael J Gruber wrote:\n> So, it's been a year or more that you've been aware of the importance of\n> this issue (from your/github's perspective), and we hear about it now,\n> at the end of the rc phase.\n\nI apologize if it sounds like that. I've been discussing this situation with\nmany people (including Jeff King) for a very long time now, and it was my\nunderstanding that the credential caching was done and simply waiting for a\nnew release. This is the first I've heard that it will not be included in\n1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I\napologize for that.\n\nI'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, and\nI've accepted that as a character flaw (it's something I'm working on). I'm\nafraid I can't be of much help with the actual code. What I can provide is an\nalternate viewpoint to the core team. A viewpoint of someone who's spent 3\nyears trying to make git easier for newcomers.\n\nI urge the core team to think about what kind of opportunity we have here.\nCredential caching isn't some minor feature. It's the last piece of the puzzle\nthat promotes Smart HTTP to a viable alternative over the git & ssh protocols.\nSmart HTTP solves an huge collection of problems people have with using git\nday to day. One URL to push privately and pull anonymously. No firewall\nrestrictions at universities or workplaces. Username & password\nauthentication. I get kind of turned on just thinking about it.\n\nKyle\n"},{"id":"175036","messageId":"7v39g82h8s.fsf@alter.siamese.dyndns.org","threadId":"28321","inReplyTo":"CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-07T21:08:03Z","receivedAt":"2011-09-07T21:08:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kyle Neath writes:\n\n> ... However, I do think this feature is\n> important enough to delay the release. I trust in the judgement of the core\n> members to know when something is ready for inclusion in master.\n\nWe do not delay a release for any new feature, as we shoot for 8 to 10\nweek release cycle these days. For an important feature that we must avoid\npainting ourselves into a corner that we cannot get out of if we screw up\nthe initial design due to possible backward compatibility issues, it is\neven more true than other minor features.\n\nThis cycle is being delayed longer than anybody wishes for an external\nreason, and unfortunately it does not mean we have longer period to\neyeball the topics in cooking due to that same external reason.\n"},{"id":"175051","messageId":"33309DB6F935472497D9790A26046452@PhilipOakley","threadId":"28321","inReplyTo":"CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-09-07T23:01:45Z","receivedAt":"2011-09-07T23:01:45Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Kyle Neath\" \n> Junio C Hamano wrote:\n>> If this were a new, insignificant, and obscure feature in a piece of\n>> software with mere 20k users, it may be OK to release a new version with\n>> the feature in an uncooked shape.\n>\n> Michael J Gruber wrote:\n>> So, it's been a year or more that you've been aware of the importance of\n>> this issue (from your/github's perspective), and we hear about it now,\n>> at the end of the rc phase.\n>\n> I apologize if it sounds like that. I've been discussing this situation \n> with\n> many people (including Jeff King) for a very long time now, and it was my\n> understanding that the credential caching was done and simply waiting for \n> a\n> new release. This is the first I've heard that it will not be included in\n> 1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I\n> apologize for that.\n>\n> I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, \n> and\n> I've accepted that as a character flaw (it's something I'm working on). \n> I'm\n> afraid I can't be of much help with the actual code. What I can provide is \n> an\n> alternate viewpoint to the core team. A viewpoint of someone who's spent 3\n> years trying to make git easier for newcomers.\n\nHelp in any capacity :\nWould it not be possible for GitHub to provide for those key users such a \ntrial version\nthat includes the patches identified to obtain the \"real-world success \nreports\" that\nare needed, as mentioned in the \"Re: What's cooking in git.git (Aug 2011, \n#07; Wed, 24)\"\n\nThis should help satisfy the needs from both sides, even if you can only \npush it to a few clients.\n\n>>What's cooking in git.git (Aug 2011, #07; Wed, 24)\n>> Looked mostly reasonable except for the limitation that it is not clear\n>> how to deal with a site at which a user needs to use different passwords\n>> for different repositories. Will keep it in \"next\" at least for one \n>> cycle,\n>> until we start hearing real-world success reports on the list.\n"},{"id":"175054","messageId":"7v7h5j2aas.fsf@alter.siamese.dyndns.org","threadId":"28321","inReplyTo":"33309DB6F935472497D9790A26046452@PhilipOakley","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-07T23:38:03Z","receivedAt":"2011-09-07T23:38:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n> Would it not be possible for GitHub to provide for those key users such\n> a trial version that includes the patches identified to obtain the\n> \"real-world success reports\" that are needed, as mentioned in the \"Re:\n> What's cooking in git.git (Aug 2011, #07; Wed, 24)\"\n>\n> This should help satisfy the needs from both sides, even if you can\n> only push it to a few clients.\n\nThat would not help very much, as (1) we know what Jeff included as sample\nkeystores are more or less cooked and good, but (2) nobody in your style\nof trial will come up with different keystore to exercise the API to make\nsure that will not paint us into a corner we cannot upgrade without major\npain in the backward compatibility area. The \"real-world success reports\"\nyou can generate would only for (1) but at this point we are not worried\nabout that. We are more (much more) worried about (2).\n"},{"id":"175092","messageId":"4E68C04F.9060804@drmicha.warpmail.net","threadId":"28321","inReplyTo":"CAFcyEthuf49_kOmoLmoSSbNJN+iOBpicP4-eFAV5wL5_RffwGg@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-08T13:17:03Z","receivedAt":"2011-09-08T13:17:03Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Kyle Neath venit, vidit, dixit 07.09.2011 22:14:\n> Junio C Hamano wrote:\n>> If this were a new, insignificant, and obscure feature in a piece of\n>> software with mere 20k users, it may be OK to release a new version with\n>> the feature in an uncooked shape.\n> \n> For the sake of my paycheck, I should certainly hope not! I'm not at all\n> suggesting we merge what we have in. However, I do think this feature is\n> important enough to delay the release. I trust in the judgement of the core\n> members to know when something is ready for inclusion in master.\n> \n> Michael J Gruber wrote:\n>> So, it's been a year or more that you've been aware of the importance of\n>> this issue (from your/github's perspective), and we hear about it now,\n>> at the end of the rc phase.\n> \n> I apologize if it sounds like that. I've been discussing this situation with\n> many people (including Jeff King) for a very long time now, and it was my\n> understanding that the credential caching was done and simply waiting for a\n> new release. This is the first I've heard that it will not be included in\n> 1.7.7, so I'm voicing my opinion now. Admittedly, late in the game - and I\n> apologize for that.\n\nOK, I've calmed down :)\n\n> I'd be happy to help in any capacity I can. Unfortunately I'm no C hacker, and\n> I've accepted that as a character flaw (it's something I'm working on). I'm\n> afraid I can't be of much help with the actual code. What I can provide is an\n> alternate viewpoint to the core team. A viewpoint of someone who's spent 3\n> years trying to make git easier for newcomers.\n\nIt would be interesting to know what we can rely on in the user group\nyou're thinking about (which I called ssh-challenged). Setting up ssh\nkeys is too complicated. Can we require a working gpg setup? They do\nwant to check sigs, don't they?\n\nWhat I have in mind is a very simple, but secure version of Jeff's\ncredential-store, respectively his example, somewhat like:\n\n---%<---\nSTORAGE=$HOME/.credentials\n\nfor i in \"$@\"; do\n\tcase \"$i\" in\n\t--unique=*)\n\t\tunique=${i#--unique=} ;;\n\tesac\ndone\n\nkey=$(git config get credential.gpgkey) # or error out\n\nif ! test -e \"$STORAGE/$unique\"; then\n\tmkdir -m 0700 \"$STORAGE\"\n\tgit credential-getpass \"$@\" | gpg -ear $key >\"$STORAGE/$unique\"\nfi\n\ngpg <\"$STORAGE/$unique\"\n---%<---\n\nOr that in C, probably using Junio's gpg-lib. That would be secure and\nuseful *if* we can rely on people having a convenient gpg setup\n(gpg-agent or such).\n\nSo: What credential store/password wallet/etc. can we rely on for this\ngroup? Is gpg fair game?\n\nMichael\n"},{"id":"175100","messageId":"CAEBDL5VAFaWYctJotxTA8ajy_0KtR8H_4SoDHK29Ofd65mYdKw@mail.gmail.com","threadId":"28321","inReplyTo":"4E68C04F.9060804@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-08T15:02:11Z","receivedAt":"2011-09-08T15:02:11Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber\n wrote:\n[snip]\n> It would be interesting to know what we can rely on in the user group\n> you're thinking about (which I called ssh-challenged). Setting up ssh\n> keys is too complicated. Can we require a working gpg setup? They do\n> want to check sigs, don't they?\n\nI don't think you can require a working gpg setup (at least for not\naddressing the ssh-challenged group).\n\n[snip]\n> Or that in C, probably using Junio's gpg-lib. That would be secure and\n> useful *if* we can rely on people having a convenient gpg setup\n> (gpg-agent or such).\n>\n> So: What credential store/password wallet/etc. can we rely on for this\n> group? Is gpg fair game?\n\nI think there probably need to be providers for using Keychain under\nthe Mac, gnome-keyring and kwallet under Linux, and probably something\nusing the wincrypt API under Windows. I don't think there's a\none-store-fits-all solution here, unfortunately. :-(\n\nI'm actually tempted try and work on a couple of those myself.\n\n-John\n"},{"id":"175121","messageId":"20110908191053.GA16064@sigill.intra.peff.net","threadId":"28321","inReplyTo":"4E6769E3.4070003@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-08T19:10:53Z","receivedAt":"2011-09-08T19:10:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 07, 2011 at 02:56:03PM +0200, Michael J Gruber wrote:\n\n> So, it's been a year or more that you've been aware of the importance\n> of this issue (from your/github's perspective), and we hear about it\n> now, at the end of the rc phase. I don't know whether\n> jk/http-auth-keyring has been done on github payroll or during spare\n> time.\n\nTo be absolutely clear here, this feature was 100% paid for by GitHub\n(which isn't to say that I don't think it's a good idea. On the\ncontrary, I think it's awesome; but GitHub money is what provided the\ntime for me to work on it).\n\nWhen I started at GitHub in January, I was given a giant list of things\nthat GitHub felt would make core git better, but that they hadn't the\npersonnel to improve. And I was told to use my own judgement in adding\nor removing items from the list based on what I thought git needed, and\nto prioritize as I saw fit. The fact that it took six months for me to\ncome up with credential patches is because that's how long it took me to\nfigure out what I wanted to write, and to clear my backlog of other git\ntasks.\n\nSo I think the wheels have been turning on this for quite a while from\nGitHub's perspective.\n\nAt the same time, I agree very much with Junio; releasing something with\na bad API and then having to fix it later is much worse than delaying\nthe release of a feature by a little bit. And we have very little data\non whether the API is \"right\" at this point. Initially I was concerned\nthat there wasn't going to be enough interest while the patches were in\n'next', and that we would have to make a release in order to get people\ninterested enough in writing helpers. But right after I said that, Lukas\nSandström showed up with a kdewallet helper. And Ted Zlatanov is working\non something for the freedesktop secrets API.\n\nAnd already there's been some discussion that perhaps the current\ninterface isn't quite what we want and is going to need tweaking.\nSo we are moving forward, and I still hope that we can target the next\nrelease of \"master\" in 8-10 weeks. But this time with more confidence\nthat what's being released is actually right.\n\nIn the meantime, the best thing we can do to push it forward is to write\nhelpers. I implemented some basic ones that should work anywhere, but\naren't as nice as integration with existing keychains. Some people are\nworking on Linux ones. The single best thing GitHub can do to push this\nforward right now is to provide a well-written OS X Keychain helper, and\nto provide feedback on whether git's end of the API is good enough.\n\n-Peff\n"},{"id":"175126","messageId":"20110908191842.GB16064@sigill.intra.peff.net","threadId":"28321","inReplyTo":"CAEBDL5VAFaWYctJotxTA8ajy_0KtR8H_4SoDHK29Ofd65mYdKw@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-08T19:18:42Z","receivedAt":"2011-09-08T19:18:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 08, 2011 at 11:02:11AM -0400, John Szakmeister wrote:\n\n> On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber\n> wrote:\n> [snip]\n> > It would be interesting to know what we can rely on in the user group\n> > you're thinking about (which I called ssh-challenged). Setting up ssh\n> > keys is too complicated. Can we require a working gpg setup? They do\n> > want to check sigs, don't they?\n> \n> I don't think you can require a working gpg setup (at least for not\n> addressing the ssh-challenged group).\n\nAgreed. Anything harder than ssh keys is right out the window, because\nthey're always the alternative these people could be using (but can't or\ndon't want to).\n\nWe could make our own gpg-based password wallet system, but I think it's\na really bad idea, for two reasons:\n\n 1. It's reinventing the wheel. Which is bad enough as it is, but is\n doubly bad with security-related code, because it's very easy to\n screw something up when you're writing a lot of new code.\n\n 2. It's inconvenient for users. Nobody wants a separate wallet system\n with its own master password. They want to integrate with the\n wallet system they're already using. Which is generally going to be\n way nicer _anyway_, because it's going to be part of the OS and do\n helpful things like unlock the secret store using their login\n credentials.\n\n> > So: What credential store/password wallet/etc. can we rely on for this\n> > group? Is gpg fair game?\n> \n> I think there probably need to be providers for using Keychain under\n> the Mac, gnome-keyring and kwallet under Linux, and probably something\n> using the wincrypt API under Windows. I don't think there's a\n> one-store-fits-all solution here, unfortunately. :-(\n\nExactly. That's why the helpers communicate via pipes. They don't have\nto be included with core git at all; you should be able to just drop a\nthird-party git-credential-foo into your PATH.\n\n> I'm actually tempted try and work on a couple of those myself.\n\nPlease do! I mentioned a few people working on helpers elsewhere in this\nthread, so you may want to see what they've done and/or coordinate to\navoid duplicate effort. Let me know if you have trouble finding the\nappropriate threads in the list archive.\n\n-Peff\n"},{"id":"175152","messageId":"4E69C8DC.7060008@drmicha.warpmail.net","threadId":"28321","inReplyTo":"20110908191842.GB16064@sigill.intra.peff.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-09T08:05:48Z","receivedAt":"2011-09-09T08:05:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 08.09.2011 21:18:\n> On Thu, Sep 08, 2011 at 11:02:11AM -0400, John Szakmeister wrote:\n> \n>> On Thu, Sep 8, 2011 at 9:17 AM, Michael J Gruber\n>> wrote:\n>> [snip]\n>>> It would be interesting to know what we can rely on in the user group\n>>> you're thinking about (which I called ssh-challenged). Setting up ssh\n>>> keys is too complicated. Can we require a working gpg setup? They do\n>>> want to check sigs, don't they?\n>>\n>> I don't think you can require a working gpg setup (at least for not\n>> addressing the ssh-challenged group).\n> \n> Agreed. Anything harder than ssh keys is right out the window, because\n> they're always the alternative these people could be using (but can't or\n> don't want to).\n\nSue, the question was: What is easy enough? I hoped that people would be\nusing gpg to check signed tags, and that there might be a simple,\nconvenient gnupg installer for Win and Mac which ties into the\nrespective wallet systems or provides one they use already.\n\n> We could make our own gpg-based password wallet system, but I think it's\n> a really bad idea, for two reasons:\n> \n> 1. It's reinventing the wheel. Which is bad enough as it is, but is\n> doubly bad with security-related code, because it's very easy to\n> screw something up when you're writing a lot of new code.\n\nSo please let's not deploy credential-store...\n\n> 2. It's inconvenient for users. Nobody wants a separate wallet system\n> with its own master password. They want to integrate with the\n> wallet system they're already using. Which is generally going to be\n> way nicer _anyway_, because it's going to be part of the OS and do\n> helpful things like unlock the secret store using their login\n> credentials.\n\nOn 1.+2.: The idea/hope was to use an existing wallet system which\npeople use for gnupg already to store their passphrase. If that is not\nused then my suggestion does not help much (the issue of widespread\ndeployment), though it still is a secure version of credential-store for\nthose who want a desktop-independent secure credential store.\n\n>>> So: What credential store/password wallet/etc. can we rely on for this\n>>> group? Is gpg fair game?\n>>\n>> I think there probably need to be providers for using Keychain under\n>> the Mac, gnome-keyring and kwallet under Linux, and probably something\n>> using the wincrypt API under Windows. I don't think there's a\n>> one-store-fits-all solution here, unfortunately. :-(\n> \n> Exactly. That's why the helpers communicate via pipes. They don't have\n> to be included with core git at all; you should be able to just drop a\n> third-party git-credential-foo into your PATH.\n> \n>> I'm actually tempted try and work on a couple of those myself.\n> \n> Please do! I mentioned a few people working on helpers elsewhere in this\n> thread, so you may want to see what they've done and/or coordinate to\n> avoid duplicate effort. Let me know if you have trouble finding the\n> appropriate threads in the list archive.\n\nIt seemed appropriate to leverage GitHub for this:\n\nhttps://github.com/gitigit/git/wiki/Git-Credentials-Hub\n\nFeel free to add!\n\nCheers,\nMichael\n"},{"id":"175153","messageId":"4E69C8F0.9070204@drmicha.warpmail.net","threadId":"28321","inReplyTo":"20110908191053.GA16064@sigill.intra.peff.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-09T08:06:08Z","receivedAt":"2011-09-09T08:06:08Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 08.09.2011 21:10:\n> On Wed, Sep 07, 2011 at 02:56:03PM +0200, Michael J Gruber wrote:\n> \n>> So, it's been a year or more that you've been aware of the importance\n>> of this issue (from your/github's perspective), and we hear about it\n>> now, at the end of the rc phase. I don't know whether\n>> jk/http-auth-keyring has been done on github payroll or during spare\n>> time.\n> \n> To be absolutely clear here, this feature was 100% paid for by GitHub\n> (which isn't to say that I don't think it's a good idea. On the\n> contrary, I think it's awesome; but GitHub money is what provided the\n> time for me to work on it).\n> \n> When I started at GitHub in January, I was given a giant list of things\n> that GitHub felt would make core git better, but that they hadn't the\n> personnel to improve. And I was told to use my own judgement in adding\n> or removing items from the list based on what I thought git needed, and\n> to prioritize as I saw fit. The fact that it took six months for me to\n> come up with credential patches is because that's how long it took me to\n> figure out what I wanted to write, and to clear my backlog of other git\n> tasks.\n> \n> So I think the wheels have been turning on this for quite a while from\n> GitHub's perspective.\n\nThanks for clarifying. While it should make no difference for the\nacceptance of patches, it's great to see GitHub invest into scratching\ntheir Git itches, and thus contribute back. That's how open source works\nas a business model :)\n\n...\n> In the meantime, the best thing we can do to push it forward is to write\n> helpers. I implemented some basic ones that should work anywhere, but\n> aren't as nice as integration with existing keychains. Some people are\n> working on Linux ones. The single best thing GitHub can do to push this\n> forward right now is to provide a well-written OS X Keychain helper, and\n> to provide feedback on whether git's end of the API is good enough.\n\n... and one for Git on Windows? It seems we're lacking both Win and OS X\ndevelopers here.\n\n... continuing in the other subthread...\n"},{"id":"175154","messageId":"buopqjaw2vc.fsf@dhlpc061.dev.necel.com","threadId":"28321","inReplyTo":"4E69C8DC.7060008@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-09-09T08:12:39Z","receivedAt":"2011-09-09T08:12:39Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Michael J Gruber writes:\n>> Agreed. Anything harder than ssh keys is right out the window,\n>> because they're always the alternative these people could be using\n>> (but can't or don't want to).\n>\n> Sue, the question was: What is easy enough? I hoped that people\n> would be using gpg to check signed tags, and that there might be a\n> simple, convenient gnupg installer for Win and Mac which ties into\n> the respective wallet systems or provides one they use already.\n\nI wouldn't be surprised if many people just don't check signed tags at\nall -- if the repositories they're using even have them in the first\nplace -- particularly amongst the audience in question.\n\n-miles\n\n-- \nWhat the fuck do white people have to be blue about!? Banana Republic ran\nout of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish\nare breaking up??! Shit, white people oughtta understand, their job is to\nGIVE people the blues, not to get them! -- George Carlin\n"},{"id":"175165","messageId":"87pqjaxbrm.fsf@lifelogs.com","threadId":"28321","inReplyTo":"4E69C8F0.9070204@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-09-09T10:15:09Z","receivedAt":"2011-09-09T10:15:09Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 09 Sep 2011 10:06:08 +0200 Michael J Gruber wrote: \n\n>> In the meantime, the best thing we can do to push it forward is to write\n>> helpers. I implemented some basic ones that should work anywhere, but\n>> aren't as nice as integration with existing keychains. Some people are\n>> working on Linux ones. The single best thing GitHub can do to push this\n>> forward right now is to provide a well-written OS X Keychain helper, and\n>> to provide feedback on whether git's end of the API is good enough.\n\nMJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X\nMJG> developers here.\n\nWindows doesn't have a standard keychain service, does it?\n\nThe OS X Keychain helper should be pretty easy in terms of the system\ncalls (he says after a quick Google search), the hard part IMHO is\nfiguring out the right way to store credentials in it. There are\nseveral ways to structure the schema.\n\nFor modern Linux systems it's best to target the Secrets API, which is\nDBUS and XML-based and works with both the KDE and GNOME keychains. I\nonly know about it what I have learned from Michael Albinus' interface\nin the Emacs source tree, but it certainly seems capable enough. This\nis what Jeff King was alluding to, I think, about what I'm working on.\nI have not been able to work on it so far, not for lack of trying.\n\nMy #1 target is to implement a GPG-based credential helper using a\nnetrc-style file. I believe that would be the most useful one, though\nnot the easiest one to set up for inexperienced users.\n\nTed\n"},{"id":"175167","messageId":"CAEBDL5VtVZcmQnj2CH7XzZ0YV_X61gO69-dXriGiYsAqk=NLPg@mail.gmail.com","threadId":"28321","inReplyTo":"87pqjaxbrm.fsf@lifelogs.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-09T10:32:25Z","receivedAt":"2011-09-09T10:32:25Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"[Added back some of the CC's]\n\nTed: we don't usually cull the CC list on the git mailing list.\n\n2011/9/9 Ted Zlatanov :\n[snip]\n> MJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X\n> MJG> developers here.\n>\n> Windows doesn't have a standard keychain service, does it?\n\nNo, it doesn't, but you can use the wincrypt API which allows you to\nat least encrypt the password from the user's login credentials. In\nparticular, CryptProtectData() and CryptUnprotectData(). That way you\ncan at least have the password stored encrypted on disk.\n\n-John\n"},{"id":"175169","messageId":"CABPQNSbrjNR73GxE4xXFPqaVSUOaa5Drt4Je+zGY82rzajQxuw@mail.gmail.com","threadId":"28321","inReplyTo":"CAEBDL5VtVZcmQnj2CH7XzZ0YV_X61gO69-dXriGiYsAqk=NLPg@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-09-09T10:48:48Z","receivedAt":"2011-09-09T10:48:48Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Sep 9, 2011 at 12:32 PM, John Szakmeister wrote:\n> [Added back some of the CC's]\n>\n> Ted: we don't usually cull the CC list on the git mailing list.\n>\n> 2011/9/9 Ted Zlatanov :\n> [snip]\n>> MJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X\n>> MJG> developers here.\n>>\n>> Windows doesn't have a standard keychain service, does it?\n>\n> No, it doesn't, but you can use the wincrypt API which allows you to\n> at least encrypt the password from the user's login credentials.  In\n> particular, CryptProtectData() and CryptUnprotectData().  That way you\n> can at least have the password stored encrypted on disk.\n\nActually, it seems recent Windows versions does have a credential\nmanager, including an API:\n\nhttp://www.yanzzee.com/2009/09/windows-keychain.html\nhttp://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx#credentials_management_functions\n"},{"id":"175170","messageId":"CAEBDL5UymsgsQnE9t121omGkR3Zw9BsFqOinTshxEN4WDcOdeA@mail.gmail.com","threadId":"28321","inReplyTo":"CABPQNSbrjNR73GxE4xXFPqaVSUOaa5Drt4Je+zGY82rzajQxuw@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-09T10:54:15Z","receivedAt":"2011-09-09T10:54:15Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Fri, Sep 9, 2011 at 6:48 AM, Erik Faye-Lund wrote:\n[snip]\n> Actually, it seems recent Windows versions does have a credential\n> manager, including an API:\n>\n> http://www.yanzzee.com/2009/09/windows-keychain.html\n> http://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx#credentials_management_functions\n\nYay! It's about time they grew that feature. :-)\n\n-John\n"},{"id":"175186","messageId":"87boutx2on.fsf@lifelogs.com","threadId":"28321","inReplyTo":"CAEBDL5VtVZcmQnj2CH7XzZ0YV_X61gO69-dXriGiYsAqk=NLPg@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-09-09T13:31:20Z","receivedAt":"2011-09-09T13:31:20Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 9 Sep 2011 06:32:25 -0400 John Szakmeister wrote: \n\nJS> [Added back some of the CC's]\nJS> Ted: we don't usually cull the CC list on the git mailing list.\n\nSorry, I followed up via GMane (a NNTP interface to the mailing list).\nI'll use `r'eply instead of `f'ollowup.\n\nI actually set\n\nMail-Copies-To: never\nGmane-Reply-To-List: yes\n\nbecause I hate getting CC'd on discussions I already follow via GMane.\nBut that's just my preference :)\n\nJS> 2011/9/9 Ted Zlatanov :\nJS> [snip]\nMJG> ... and one for Git on Windows? It seems we're lacking both Win and OS X\nMJG> developers here.\n>> \n>> Windows doesn't have a standard keychain service, does it?\n\nJS> No, it doesn't, but you can use the wincrypt API which allows you to\nJS> at least encrypt the password from the user's login credentials. In\nJS> particular, CryptProtectData() and CryptUnprotectData(). That way you\nJS> can at least have the password stored encrypted on disk.\n\nI don't think that's sufficient but could be wrong.\n\nTed\n"},{"id":"175185","messageId":"877h5hx2l7.fsf@lifelogs.com","threadId":"28321","inReplyTo":"CAEBDL5UymsgsQnE9t121omGkR3Zw9BsFqOinTshxEN4WDcOdeA@mail.gmail.com","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-09-09T13:33:24Z","receivedAt":"2011-09-09T13:33:24Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 9 Sep 2011 06:54:15 -0400 John Szakmeister wrote: \n\nJS> On Fri, Sep 9, 2011 at 6:48 AM, Erik Faye-Lund wrote:\nJS> [snip]\n>> Actually, it seems recent Windows versions does have a credential\n>> manager, including an API:\n>> \n>> http://www.yanzzee.com/2009/09/windows-keychain.html\n>> http://msdn.microsoft.com/en-us/library/aa374731(v=VS.85).aspx#credentials_management_functions\n\nJS> Yay! It's about time they grew that feature. :-)\n\nThat could work. I hope a Windows developer can take a look. That\nleaves VMS credential support... Come on guys!\n\nTed\n"},{"id":"175223","messageId":"20110909182714.GC28480@sigill.intra.peff.net","threadId":"28321","inReplyTo":"4E69C8DC.7060008@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-09T18:27:14Z","receivedAt":"2011-09-09T18:27:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 09, 2011 at 10:05:48AM +0200, Michael J Gruber wrote:\n\n> > Agreed. Anything harder than ssh keys is right out the window, because\n> > they're always the alternative these people could be using (but can't or\n> > don't want to).\n> \n> Sue, the question was: What is easy enough? I hoped that people would be\n> using gpg to check signed tags, and that there might be a simple,\n> convenient gnupg installer for Win and Mac which ties into the\n> respective wallet systems or provides one they use already.\n\nI suspect most people aren't checking signed tags. And even if they did\nhave gpg installed, most people aren't going to want a new password\nwallet. They're going to want integration with what they're already\nusing.\n\nWhich isn't to say that a gpg-based wallet is wrong, it's just that I\ndon't think it's filling the role that really needs filled. If you want\nto make such a wallet helper, you're welcome to. But it doesn't\nnecessarily need to be a part of git core, and if it's not, then maybe\nit's worth looking at the zillion other password wallet programs that\nexist.\n\nFWIW, I keep my passwords in a gpg-encrypted file and wrote a 10-line\nshell script helper to do lookups for git. :)\n\n> > We could make our own gpg-based password wallet system, but I think it's\n> > a really bad idea, for two reasons:\n> > \n> > 1. It's reinventing the wheel. Which is bad enough as it is, but is\n> > doubly bad with security-related code, because it's very easy to\n> > screw something up when you're writing a lot of new code.\n> \n> So please let's not deploy credential-store...\n\nI'm tempted to agree. But I also think it represents a nice lowest\ncommon denominator. No hassle, no setup, but no security either. And\nthere are situations where that's appropriate (e.g., for unattended\ncron operation, it's not much different than an unencrypted ssh key on\ndisk). My compromise was to put a big warning at the top of the\ndocumentation. Maybe that's not enough, though.\n\nAnd as far as reinventing the wheel with security code, I don't think\ngit-credential-store counts. It's not secure at all, so there's very\nlittle to screw up. :)\n\n> On 1.+2.: The idea/hope was to use an existing wallet system which\n> people use for gnupg already to store their passphrase. If that is not\n> used then my suggestion does not help much (the issue of widespread\n> deployment), though it still is a secure version of credential-store for\n> those who want a desktop-independent secure credential store.\n\nYeah, if there is an existing wallet system based around gpg, then\nabsolutely there should be a helper for it. But I don't know that there\nis such a widely deployed system. And the helper for it doesn't need to\nship with git-core; anybody who uses their wallet system is free to\nwrite and distribute the helper.\n\n-Peff\n"},{"id":"175224","messageId":"20110909183424.GD28480@sigill.intra.peff.net","threadId":"28321","inReplyTo":"4E69C8F0.9070204@drmicha.warpmail.net","subject":"Re: The imporantance of including http credential caching in 1.7.7","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-09T18:34:24Z","receivedAt":"2011-09-09T18:34:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 09, 2011 at 10:06:08AM +0200, Michael J Gruber wrote:\n\n> > So I think the wheels have been turning on this for quite a while from\n> > GitHub's perspective.\n> \n> Thanks for clarifying. While it should make no difference for the\n> acceptance of patches, it's great to see GitHub invest into scratching\n> their Git itches, and thus contribute back. That's how open source works\n> as a business model :)\n\nYes. I don't often enough mention how awesome GitHub is for funding me\nand giving me a free hand to improve git. They're doing everything\nright. So let me mention it here one more time. :)\n\n> > In the meantime, the best thing we can do to push it forward is to write\n> > helpers. I implemented some basic ones that should work anywhere, but\n> > aren't as nice as integration with existing keychains. Some people are\n> > working on Linux ones. The single best thing GitHub can do to push this\n> > forward right now is to provide a well-written OS X Keychain helper, and\n> > to provide feedback on whether git's end of the API is good enough.\n> \n> ... and one for Git on Windows? It seems we're lacking both Win and OS X\n> developers here.\n\nI mentioned OS X because of Kyle's mention of the GitHub for Mac client.\nBut yes, I do think in the long term we want something similar on\nWindows. GitHub recently hired a developer with some Windows experience;\nI'll try to see if he's interested in writing a credential helper.\n\n-Peff\n"}]}