{"thread":{"id":"27741","subject":"[Wishlist] could git tell which password it is asking when asking a password.","startedAt":"2011-07-01T13:59:09Z","lastAt":"2011-07-15T21:05:41Z","messageCount":15,"participants":["Rémi Vanicat","Junio C Hamano","Shawn Pearce","Ted Zlatanov","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170742","messageId":"877h82nlua.dlv@debian.org","threadId":"27741","inReplyTo":null,"subject":"[Wishlist] could git tell which password it is asking when asking a password.","fromName":"Rémi Vanicat","fromEmail":"vanicat@debian.org","sentAt":"2011-07-01T13:59:09Z","receivedAt":"2011-07-01T13:59:09Z","isPatch":false,"sender":{"key":"vanicat@debian.org","avatar":"https://gravatar.com/avatar/cd491a7f4c221349809a60f88fc21326b97cce2a705e318898aa74851db92409?d=mp&s=160"},"body":"Hello,\n\nWhen git is asking for a password (for example for pushing over https)\nit call the $GIT_ASKPASS script with only \"Password: \" as a an argument,\nso when one have several remote, it might not know which one is asking\nthe password. \n\nIt would be interesting also to plug some sort of password-safe unto\ngit, or some \"git-agent\". \n-- \nRémi Vanicat\n"},{"id":"170744","messageId":"7v62nmos0k.fsf@alter.siamese.dyndns.org","threadId":"27741","inReplyTo":"877h82nlua.dlv@debian.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-01T17:00:27Z","receivedAt":"2011-07-01T17:00:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rémi Vanicat writes:\n\n> When git is asking for a password (for example for pushing over https)\n> it call the $GIT_ASKPASS script with only \"Password: \" as a an argument,\n> so when one have several remote, it might not know which one is asking\n> the password. \n\nOn the C side, git_getpass() is the function to touch. It has only three\ncallers.\n\nIn init_curl_http_auth() in http.c, we know \"user_name\" but we do not give\nit as a hint when coming up with a prompt. A possible update to the\ngit_getpass() API would be to make the call look like this:\n\ndiff --git a/http.c b/http.c\nindex a1ea3db..ee3e821 100644\n--- a/http.c\n+++ b/http.c\n@@ -214,7 +214,7 @@ static void init_curl_http_auth(CURL *result)\n \tif (user_name) {\n \t\tstruct strbuf up = STRBUF_INIT;\n \t\tif (!user_pass)\n-\t\t\tuser_pass = xstrdup(git_getpass(\"Password: \"));\n+\t\t\tuser_pass = git_getpass(_(\"Password for %s: \"), user_name);\n \t\tstrbuf_addf(&up, \"%s:%s\", user_name, user_pass);\n \t\tcurl_easy_setopt(result, CURLOPT_USERPWD,\n \t\t\t\t strbuf_detach(&up, NULL));\n\nThe points are\n\n (1) to show identity for which the password is being asked for;\n (2) to give a fresh and stable memory, making it unnecessary to\n xstrdup() while at it.\n\nThe same thing for the call in has_cert_password(), which may want to use ssl_cert\nas the identifier.\n\nThere is an abuse of git_getpass() in http_request() to ask for the\nusername. It inherits the \"noecho\"-ness of git_getpass() which gives a\nbad user experience. We _may_ want to give another parameter to git_getpass()\nto specify if we want noecho.\n\nThe other call is from imap-send.c that knows srvc->user and srvc->host\nand formulates the prompt including the identity. So an alternative route\nmay be to keep git_getpass() as-is, and update the init_curl_http_auth()\ncallsite to include the username (but imap-send assumes that user and host\nare relatively short without verifying that assumption, and should not be\nused as a model of good existing code).\n\n> It would be interesting also to plug some sort of password-safe unto\n> git, or some \"git-agent\". \n\nI am not particularly interested in seeing git specific agent. Something\nthat can be called as an external process that talks with existing\npractices (gpg agent and friends) would be nice.\n"},{"id":"170749","messageId":"87aacygcfx.fsf@lifelogs.com","threadId":"27741","inReplyTo":"877h82nlua.dlv@debian.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-07-01T17:04:02Z","receivedAt":"2011-07-01T17:04:02Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat wrote: \n\nRV> When git is asking for a password (for example for pushing over https)\nRV> it call the $GIT_ASKPASS script with only \"Password: \" as a an argument,\nRV> so when one have several remote, it might not know which one is asking\nRV> the password. \n\nSeconded, I run into this all the time. A configurable prompt with %h\nfor the host, etc. would be really nice.\n\nRV> It would be interesting also to plug some sort of password-safe unto\nRV> git, or some \"git-agent\". \n\nThis would also be really nice. ~/.netrc is not a great place to put\npasswords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg\nwith the same content as ~/.netrc but encrypted by GPG and thus more\nsecure (the user is either prompted for the password, if the file is\nencrypted symmetrically, or the user simply loads their private key into\nthe GPG agent). I believe all this can be done with the GPGME library.\nThere's also the Secrets API on newer Gnome and KDE installs, which has\na pretty nice D-Bus interface.\n\nBut is this a libcurl feature request? Or can a Git plugin (an\nalternate HTTPS transport maybe?) handle it?\n\nThanks\nTed\n"},{"id":"170745","messageId":"7v1uy9q5v1.fsf@alter.siamese.dyndns.org","threadId":"27741","inReplyTo":"7v62nmos0k.fsf@alter.siamese.dyndns.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-01T17:16:02Z","receivedAt":"2011-07-01T17:16:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ... So an alternative route\n> may be to keep git_getpass() as-is, and update the init_curl_http_auth()\n> callsite to include the username (but imap-send assumes that user and host\n> are relatively short without verifying that assumption, and should not be\n> used as a model of good existing code).\n\nAnd here is such a lazy patch, completely untested, of course ;-).\n\n http.c | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/http.c b/http.c\nindex b2ae8de..44948a7 100644\n--- a/http.c\n+++ b/http.c\n@@ -209,8 +209,11 @@ static void init_curl_http_auth(CURL *result)\n {\n \tif (user_name) {\n \t\tstruct strbuf up = STRBUF_INIT;\n-\t\tif (!user_pass)\n-\t\t\tuser_pass = xstrdup(git_getpass(\"Password: \"));\n+\t\tif (!user_pass) {\n+\t\t\tstrbuf_addf(&up, \"Password for %s: \", user_name);\n+\t\t\tuser_pass = xstrdup(git_getpass(up.buf));\n+\t\t\tstrbuf_reset(&up);\n+\t\t}\n \t\tstrbuf_addf(&up, \"%s:%s\", user_name, user_pass);\n \t\tcurl_easy_setopt(result, CURLOPT_USERPWD,\n \t\t\t\t strbuf_detach(&up, NULL));\n"},{"id":"170746","messageId":"BANLkTi=aAinh=0jxb5MoqVOdUB7zxoy2XdSqk+pdsewLXU62ZA@mail.gmail.com","threadId":"27741","inReplyTo":"7v1uy9q5v1.fsf@alter.siamese.dyndns.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-07-01T17:18:15Z","receivedAt":"2011-07-01T17:18:15Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Fri, Jul 1, 2011 at 10:16, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> diff --git a/http.c b/http.c\n> index b2ae8de..44948a7 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -209,8 +209,11 @@ static void init_curl_http_auth(CURL *result)\n>  {\n>        if (user_name) {\n>                struct strbuf up = STRBUF_INIT;\n> -               if (!user_pass)\n> -                       user_pass = xstrdup(git_getpass(\"Password: \"));\n> +               if (!user_pass) {\n> +                       strbuf_addf(&up, \"Password for %s: \", user_name);\n\nThe user_name by itself may not be sufficient. I may also need the URL\nto correctly answer the question. I don't always use the same password\non every website. :-)\n\nAs a human sure, I know what URL I asked Git to poke for me. But if I\nwant to write a script that looks this up in a password manager for\nme, that script needs the URL.\n\nFood for thought.\n\n-- \nShawn.\n"},{"id":"170747","messageId":"7vwrg1opov.fsf@alter.siamese.dyndns.org","threadId":"27741","inReplyTo":"BANLkTi=aAinh=0jxb5MoqVOdUB7zxoy2XdSqk+pdsewLXU62ZA@mail.gmail.com","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-01T17:50:40Z","receivedAt":"2011-07-01T17:50:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> On Fri, Jul 1, 2011 at 10:16, Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>> diff --git a/http.c b/http.c\n>> index b2ae8de..44948a7 100644\n>> --- a/http.c\n>> +++ b/http.c\n>> @@ -209,8 +209,11 @@ static void init_curl_http_auth(CURL *result)\n>>  {\n>>        if (user_name) {\n>>                struct strbuf up = STRBUF_INIT;\n>> -               if (!user_pass)\n>> -                       user_pass = xstrdup(git_getpass(\"Password: \"));\n>> +               if (!user_pass) {\n>> +                       strbuf_addf(&up, \"Password for %s: \", user_name);\n>\n> The user_name by itself may not be sufficient. I may also need the URL\n> to correctly answer the question. I don't always use the same password\n> on every website. :-)\n>\n> As a human sure, I know what URL I asked Git to poke for me.\n\nI was wondering about that when I gave that quick patch. And \"as a human\"\nmay not necessarily apply when you are letting submodule fetch to recurse.\n"},{"id":"170751","messageId":"87tyb5n6pk.dlv@debian.org","threadId":"27741","inReplyTo":"7vwrg1opov.fsf@alter.siamese.dyndns.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Rémi Vanicat","fromEmail":"vanicat@debian.org","sentAt":"2011-07-01T19:25:59Z","receivedAt":"2011-07-01T19:25:59Z","isPatch":false,"sender":{"key":"vanicat@debian.org","avatar":"https://gravatar.com/avatar/cd491a7f4c221349809a60f88fc21326b97cce2a705e318898aa74851db92409?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Shawn Pearce writes:\n>\n>> On Fri, Jul 1, 2011 at 10:16, Junio C Hamano wrote:\n>>> Junio C Hamano writes:\n>>> diff --git a/http.c b/http.c\n>>> index b2ae8de..44948a7 100644\n>>> --- a/http.c\n>>> +++ b/http.c\n>>> @@ -209,8 +209,11 @@ static void init_curl_http_auth(CURL *result)\n>>>  {\n>>>        if (user_name) {\n>>>                struct strbuf up = STRBUF_INIT;\n>>> -               if (!user_pass)\n>>> -                       user_pass = xstrdup(git_getpass(\"Password: \"));\n>>> +               if (!user_pass) {\n>>> +                       strbuf_addf(&up, \"Password for %s: \", user_name);\n>>\n>> The user_name by itself may not be sufficient. I may also need the URL\n>> to correctly answer the question. I don't always use the same password\n>> on every website. :-)\n>>\n>> As a human sure, I know what URL I asked Git to poke for me.\n>\n> I was wondering about that when I gave that quick patch. And \"as a human\"\n> may not necessarily apply when you are letting submodule fetch to recurse.\n\nI also believe that having the host name would be useful, both for human\n(another example would be git remote update when there are several\nremote) and script. \n\n-- \nRémi Vanicat\n"},{"id":"170752","messageId":"87aacxepnm.fsf@lifelogs.com","threadId":"27741","inReplyTo":"87tyb5n6pk.dlv@debian.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-07-01T20:01:33Z","receivedAt":"2011-07-01T20:01:33Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 01 Jul 2011 21:25:59 +0200 Rémi Vanicat wrote: \n\nRV> Junio C Hamano writes:\n>> I was wondering about that when I gave that quick patch. And \"as a human\"\n>> may not necessarily apply when you are letting submodule fetch to recurse.\n\nRV> I also believe that having the host name would be useful, both for human\nRV> (another example would be git remote update when there are several\nRV> remote) and script. \n\nMaybe (using %U for the URL, %h for the host, %u for the user name):\n\n\"User name for %h: \" OR \"User name for %h (%U): \"\n\n\"Password for %u@%h: \" OR \"Password for %u@%h (%U): \"\n\nwith some way to switch between the two styles?\n\nTed\n"},{"id":"170753","messageId":"7vfwmpoi9y.fsf@alter.siamese.dyndns.org","threadId":"27741","inReplyTo":"87tyb5n6pk.dlv@debian.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-01T20:30:49Z","receivedAt":"2011-07-01T20:30:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rémi Vanicat writes:\n\n> I also believe that having the host name would be useful, both for human\n> (another example would be git remote update when there are several\n> remote) and script. \n\nPatches welcome, but I have to warn you that the code may _not_ know the\nURL at that point in the callchain.\n"},{"id":"170754","messageId":"20110701204624.GA32731@sigill.intra.peff.net","threadId":"27741","inReplyTo":"7v62nmos0k.fsf@alter.siamese.dyndns.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-01T20:46:24Z","receivedAt":"2011-07-01T20:46:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 01, 2011 at 10:00:27AM -0700, Junio C Hamano wrote:\n\n> > It would be interesting also to plug some sort of password-safe unto\n> > git, or some \"git-agent\". \n> \n> I am not particularly interested in seeing git specific agent. Something\n> that can be called as an external process that talks with existing\n> practices (gpg agent and friends) would be nice.\n\nCoincidentally, I am working on a big patch series for exactly this.\n\nIt is still lacking some docs and tests, but if you want to take a peek,\nit's at:\n\n https://github.com/peff/git.git jk/http-auth\n\nIt runs external credential helpers, giving them a unique context (like\nthe protocol and hostname for http connections), as well as a username,\nif we already have one. The goal is two-fold:\n\n 1. Plug into existing password wallets that are going to be\n user- and OS- specific.\n\n 2. Provide a few stock helpers to implement simple policies in a\n pluggable way.\n\nRight now I have two helpers: \"store\", and \"cache\". Both will check\ninternal storage for a password; if we don't have one, they will prompt\nand put the result in internal storage. In either case, the password is\nsent back to git. They differ in what \"internal storage\" means.\n\nIn the case of \"store\", it is a mode 600 ~/.git-credentials file. Yes,\nthis is horribly insecure. But it's what some people want, it's no worse\nthan .netrc, and it's what svn does (and what gitter wouldn't be swayed\nby that last argument? :) ). It's a little more friendly than netrc\nbecause the storage happens transparently. I think the docs for this\nshould discourage it because of the security implications, and it should\ndefinitely never become the default.\n\nFor \"cache\", we fork off a storage daemon which keeps the password in\nmemory for a specified period of time. The password never touches the\ndisk. It doesn't mlock() right now, but it could on platforms that\nsupport it.\n\nBoth are obviously mediocre solutions in comparison to a real password\nwallet[1]. But they're really simple to implement and give us a better\nbaseline to ship with git. I'm hoping users of individual keychains will\nimplement helpers to use them. Somebody from GitHub is going to work on\nan OS X keychain helper. I personally use a home-grown password safe;\nwriting a read-only helper was about 10 lines of shell code.\n\nAnyway, if people want to try it out, build the branch I mentioned above\nand configure it like:\n\n # horribly insecure\n git config http.credentialhelper store\n\nor\n\n # a little better\n git config http.credentialhelper cache\n\n # we will now cache results for 15 minutes, but there's no reason not\n # to store the username all the time, to avoid having to type it on a\n # cache miss\n git config credential.https:github.com.username peff\n\nI've been using it for the past week or so, but I'm sure there are\nlurking bugs. If you run into any, let me know.\n\n-Peff\n\n[1] Obviously this entire exercise is an attempt to make https\nauthentication as nice a user-experience as ssh with keys and ssh-agent.\nSo it's tempting to say \"just use ssh with keys\". But I think the\nreality is that ssh and keys are just too challenging for a subset of\nthe user population (especially ones on operating systems without good\nsupport). Apparently GitHub's most common tech support issues are people\nunable to figure out how to make ssh keys, set up an agent, etc.\n"},{"id":"170755","messageId":"20110701204823.GB32731@sigill.intra.peff.net","threadId":"27741","inReplyTo":"7vfwmpoi9y.fsf@alter.siamese.dyndns.org","subject":"Re: [Wishlist] could git tell which password it is asking when asking a password.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-01T20:48:23Z","receivedAt":"2011-07-01T20:48:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 01, 2011 at 01:30:49PM -0700, Junio C Hamano wrote:\n\n> Rémi Vanicat writes:\n> \n> > I also believe that having the host name would be useful, both for human\n> > (another example would be git remote update when there are several\n> > remote) and script. \n> \n> Patches welcome, but I have to warn you that the code may _not_ know the\n> URL at that point in the callchain.\n\nYeah, you have to save it; the simplest time is when we parse the\nusername+password bits out of the URL during http_auth_init, and then\npass it through to git_getpass.\n\nBut see the patch series I just mentioned elsewhere in the thread. Right\nnow it still uses \"Password:\" for http authentication, but it would be a\none-liner to have it use \"Password for 'user@example.com':\".\n\n-Peff\n"},{"id":"171336","messageId":"87bowxt0sh.fsf_-_@lifelogs.com","threadId":"27741","inReplyTo":"87aacygcfx.fsf@lifelogs.com","subject":"encrypted netrc for Git (was: [Wishlist] could git tell which password it is asking when asking a password.)","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-07-14T14:05:50Z","receivedAt":"2011-07-14T14:05:50Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Fri, 01 Jul 2011 12:04:02 -0500 Ted Zlatanov wrote: \n\nTZ> On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat wrote: \n\nRV> It would be interesting also to plug some sort of password-safe unto\nRV> git, or some \"git-agent\". \n\nTZ> This would also be really nice. ~/.netrc is not a great place to put\nTZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg\nTZ> with the same content as ~/.netrc but encrypted by GPG and thus more\nTZ> secure (the user is either prompted for the password, if the file is\nTZ> encrypted symmetrically, or the user simply loads their private key into\nTZ> the GPG agent). I believe all this can be done with the GPGME library.\nTZ> There's also the Secrets API on newer Gnome and KDE installs, which has\nTZ> a pretty nice D-Bus interface.\n\nTZ> But is this a libcurl feature request? Or can a Git plugin (an\nTZ> alternate HTTPS transport maybe?) handle it?\n\nPing? I'd like to work on this if it seems like a feasible feature.\n\nThanks\nTed\n"},{"id":"171337","messageId":"20110714150033.GA6797@sigill.intra.peff.net","threadId":"27741","inReplyTo":"87bowxt0sh.fsf_-_@lifelogs.com","subject":"Re: encrypted netrc for Git (was: [Wishlist] could git tell which password it is asking when asking a password.)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-14T15:00:33Z","receivedAt":"2011-07-14T15:00:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 14, 2011 at 09:05:50AM -0500, Ted Zlatanov wrote:\n\n> On Fri, 01 Jul 2011 12:04:02 -0500 Ted Zlatanov wrote: \n> \n> TZ> On Fri, 01 Jul 2011 15:59:09 +0200 Rémi Vanicat wrote: \n> \n> RV> It would be interesting also to plug some sort of password-safe unto\n> RV> git, or some \"git-agent\". \n> \n> TZ> This would also be really nice. ~/.netrc is not a great place to put\n> TZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg\n> TZ> with the same content as ~/.netrc but encrypted by GPG and thus more\n> TZ> secure (the user is either prompted for the password, if the file is\n> TZ> encrypted symmetrically, or the user simply loads their private key into\n> TZ> the GPG agent). I believe all this can be done with the GPGME library.\n> TZ> There's also the Secrets API on newer Gnome and KDE installs, which has\n> TZ> a pretty nice D-Bus interface.\n> \n> TZ> But is this a libcurl feature request? Or can a Git plugin (an\n> TZ> alternate HTTPS transport maybe?) handle it?\n> \n> Ping? I'd like to work on this if it seems like a feasible feature.\n\nCheck out:\n\n https://github.com/peff/git/commits/jk/http-auth\n\nwhich provides an interface for getting credentials from external\nhelpers.\n\nI need to write docs for a few of the top commits before posting the\npatches to the list, but other than that, it should be fairly solid and\nusable. And I'd love to get feedback from somebody trying to write a new\nhelper for it (i.e., to tell if the interface to the helpers is good\nenough).\n\n-Peff\n"},{"id":"171411","messageId":"8762n379pa.fsf@lifelogs.com","threadId":"27741","inReplyTo":"20110714150033.GA6797@sigill.intra.peff.net","subject":"Re: encrypted netrc for Git","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-07-15T17:08:49Z","receivedAt":"2011-07-15T17:08:49Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Thu, 14 Jul 2011 11:00:33 -0400 Jeff King wrote: \n\nJK> On Thu, Jul 14, 2011 at 09:05:50AM -0500, Ted Zlatanov wrote:\n\nTZ> This would also be really nice. ~/.netrc is not a great place to put\nTZ> passwords for the HTTP transport. In GNU Emacs we have ~/.authinfo.gpg\nTZ> with the same content as ~/.netrc but encrypted by GPG and thus more\nTZ> secure (the user is either prompted for the password, if the file is\nTZ> encrypted symmetrically, or the user simply loads their private key into\nTZ> the GPG agent). I believe all this can be done with the GPGME library.\nTZ> There's also the Secrets API on newer Gnome and KDE installs, which has\nTZ> a pretty nice D-Bus interface.\n\nJK> Check out:\n\nJK> https://github.com/peff/git/commits/jk/http-auth\n\nJK> which provides an interface for getting credentials from external\nJK> helpers.\n\nThe API is good, but it's not clear from the docs how to configure\ncredential helpers from the user side. From the tests it looks like you\nset GIT_ASKPASS to them, is that right? And you can also set\ncredential.helper?\n\nWhere do those helpers fit with the .netrc file? Are they called before\nor after or instead of the .netrc parse?\n\nLinking these with external libraries like GPGME and the Secrets API\nwill be pretty easy and improve the user experience. So I'll be glad to\nwork on it and provide you with feedback. Would you be interested in\npushing your patches further after the testing? They seem pretty\ncomplete.\n\nI'm off-line for the next 10 days or so; I'll start testing when I get\nback.\n\nThanks for your help\nTed\n"},{"id":"171438","messageId":"20110715210541.GD356@sigill.intra.peff.net","threadId":"27741","inReplyTo":"8762n379pa.fsf@lifelogs.com","subject":"Re: encrypted netrc for Git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-15T21:05:41Z","receivedAt":"2011-07-15T21:05:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 15, 2011 at 12:08:49PM -0500, Ted Zlatanov wrote:\n\n> JK> Check out:\n> \n> JK> https://github.com/peff/git/commits/jk/http-auth\n> \n> JK> which provides an interface for getting credentials from external\n> JK> helpers.\n> \n> The API is good, but it's not clear from the docs how to configure\n> credential helpers from the user side. From the tests it looks like you\n> set GIT_ASKPASS to them, is that right? And you can also set\n> credential.helper?\n\nYes, that is the documentation I need to write before I can send in the\npatches. :)\n\nThe answer is that you use \"credential.helper\". For example:\n\n $ git config credential.helper cache\n\n $ git push https://your.server/repo.git\n Username: \n Password: \n ... push happens ...\n\n [five minutes pass]\n $ git push https://your.server/repo.git\n ... push happens, no auth required ...\n\n> Where do those helpers fit with the .netrc file? Are they called before\n> or after or instead of the .netrc parse?\n\nThey are what git provides to curl, either because we have \"user@\" in\nthe URL, or because we tried curl once and got an HTTP 401. Curl uses\nnetrc automagically behind the scenes.\n\nSo for a URL without \"user@\" I believe the order would be:\n\n 1. Curl tries the request with what's in your netrc (or maybe it\n transparently requests and uses the netrc after getting a 401; I'm\n not sure).\n\n 2. Curl gives us a 401, and we ask for credentials via getpass(). Or a\n credential helper, if defined. Any username given in netrc will not\n be considered a partial credential (i.e., you will be prompted for\n username and password as if netrc didn't exist).\n\n 3. If those credentials fail (i.e., we get a 401 again), we quit.\n\n> Linking these with external libraries like GPGME and the Secrets API\n> will be pretty easy and improve the user experience. So I'll be glad to\n> work on it and provide you with feedback.\n\nYes, exactly. I think somebody at GitHub will probably work on OS X\nKeychain integration, too.\n\nI personally use a home-grown password safe that is a searchable\ngpg-encrypted file (which then gets unlocked by gpg-agent). My helper is\nmore or less:\n\n-- >8 --\n#!/bin/sh\n\nunique=\nfor i in \"$@\"; do\n case \"$i\" in\n --unique=*) unique=${i#--unique=} ;;\n esac\ndone\n\n# find lines of the form\n# example.com.username=me\n# example.com.password=mypass\ngpg -qd --no-tty $HOME/.pass.gpg |\nsed -n 's/^$unique.//p\n-- >8 --\n\n(actually, my file format is quite a bit more complex and robust than\nthat, and I use a perl script to parse it instead of sed, but this was\nmeant to be illustrative of how simple it could be).\n\nObviously something integrated with the secrets API would be way nicer,\nif you are running GNOME Keyring (that's part of why I pushed it out to\nan external helper; there are nearly as many password wallet solutions\nas there are users, and everybody will have their favorite).\n\n> Would you be interested in pushing your patches further after the\n> testing? They seem pretty complete.\n\nAbsolutely. I'm planning on finishing up the docs and posting the\npatches in the next couple days, so hopefully they will get more\nfeedback and testing there, too.\n\n-Peff\n"}]}