{"thread":{"id":"29537","subject":"Push from an SSH Terminal","startedAt":"2012-02-03T15:50:02Z","lastAt":"2012-02-04T08:16:05Z","messageCount":12,"participants":["Feanil Patel","Neal Groothuis","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183739","messageId":"CAG94OYxX5foffvaFLQv7=wXguGC2TLgccdDFrC+ERzv_gXZ=ug@mail.gmail.com","threadId":"29537","inReplyTo":null,"subject":"Push from an SSH Terminal","fromName":"Feanil Patel","fromEmail":"feanil@gmail.com","sentAt":"2012-02-03T15:50:02Z","receivedAt":"2012-02-03T15:50:02Z","isPatch":false,"sender":{"key":"feanil@gmail.com","avatar":"https://gravatar.com/avatar/699979df6ea477a4bef95fa8595768623598afc6f0ba7f939015c3cf5cfc700c?d=mp&s=160"},"body":"Hi Everyone,\n\nI tried looking for an answer to my problem online without much luck,\nperhaps you can help me.  I'm SSHed from my laptop(Comp A) over to a\ncomputer(Comp B) that has my git repo on it. I made some changes and\ncomitted them. Now I want to push them to my other server(Comp C). The\nrepository is password protected so if I'm physically at Comp B, I get\na gui prompt for my username and password. However Comp A does not\nhave X Forwarding setup to Comp B so I can't get the gui interface for\nthe username and password when I try to do the push.  Is there an\nalternative way to provide my credentials when doing a git push that\ndoes not require a gui?\n\n--\nFeanil Patel\n"},{"id":"183740","messageId":"21607.38.96.167.131.1328286083.squirrel@mail.lo-cal.org","threadId":"29537","inReplyTo":"CAG94OYxX5foffvaFLQv7=wXguGC2TLgccdDFrC+ERzv_gXZ=ug@mail.gmail.com","subject":"Re: Push from an SSH Terminal","fromName":"Neal Groothuis","fromEmail":"ngroot@lo-cal.org","sentAt":"2012-02-03T16:21:23Z","receivedAt":"2012-02-03T16:21:23Z","isPatch":false,"sender":{"key":"ngroot@lo-cal.org","avatar":null},"body":"> The\n> repository is password protected so if I'm physically at Comp B, I get\n> a gui prompt for my username and password. However Comp A does not\n> have X Forwarding setup to Comp B so I can't get the gui interface for\n> the username and password when I try to do the push.  Is there an\n> alternative way to provide my credentials when doing a git push that\n> does not require a gui?\n\nWhat protocol are you using to access the repository on Comp C?\n\n- Neal\n"},{"id":"183741","messageId":"CAG94OYxbOYCjd5qNBh8EF2gyezHWMqX1-R2MYgk8gkFYcrMjuQ@mail.gmail.com","threadId":"29537","inReplyTo":"21607.38.96.167.131.1328286083.squirrel@mail.lo-cal.org","subject":"Re: Push from an SSH Terminal","fromName":"Feanil Patel","fromEmail":"feanil@gmail.com","sentAt":"2012-02-03T16:40:42Z","receivedAt":"2012-02-03T16:40:42Z","isPatch":false,"sender":{"key":"feanil@gmail.com","avatar":"https://gravatar.com/avatar/699979df6ea477a4bef95fa8595768623598afc6f0ba7f939015c3cf5cfc700c?d=mp&s=160"},"body":"On Fri, Feb 3, 2012 at 11:21 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:\n>> The\n>> repository is password protected so if I'm physically at Comp B, I get\n>> a gui prompt for my username and password. However Comp A does not\n>> have X Forwarding setup to Comp B so I can't get the gui interface for\n>> the username and password when I try to do the push.  Is there an\n>> alternative way to provide my credentials when doing a git push that\n>> does not require a gui?\n>\n> What protocol are you using to access the repository on Comp C?\n>\n> - Neal\n>\n\nI'm pulling and pushing over HTTP from Comp C.\n"},{"id":"183743","messageId":"34592.38.96.167.131.1328289027.squirrel@mail.lo-cal.org","threadId":"29537","inReplyTo":"CAG94OYxbOYCjd5qNBh8EF2gyezHWMqX1-R2MYgk8gkFYcrMjuQ@mail.gmail.com","subject":"Re: Push from an SSH Terminal","fromName":"Neal Groothuis","fromEmail":"ngroot@lo-cal.org","sentAt":"2012-02-03T17:10:27Z","receivedAt":"2012-02-03T17:10:27Z","isPatch":false,"sender":{"key":"ngroot@lo-cal.org","avatar":null},"body":"> On Fri, Feb 3, 2012 at 11:21 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:\n>>> The\n>>> repository is password protected so if I'm physically at Comp B, I get\n>>> a gui prompt for my username and password. However Comp A does not\n>>> have X Forwarding setup to Comp B so I can't get the gui interface for\n>>> the username and password when I try to do the push.  Is there an\n>>> alternative way to provide my credentials when doing a git push that\n>>> does not require a gui?\n>>\n>> What protocol are you using to access the repository on Comp C?\n>>\n> I'm pulling and pushing over HTTP from Comp C.\n\nCheck to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables\nare set, and if the core.askpass config variable is set.  If any of these\nare set, unset them.  Git should fall back to a simple password prompt.\n\n- Neal\n"},{"id":"183764","messageId":"20120203213508.GC1890@sigill.intra.peff.net","threadId":"29537","inReplyTo":"CAG94OYxX5foffvaFLQv7=wXguGC2TLgccdDFrC+ERzv_gXZ=ug@mail.gmail.com","subject":"Re: Push from an SSH Terminal","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T21:35:08Z","receivedAt":"2012-02-03T21:35:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 03, 2012 at 10:50:02AM -0500, Feanil Patel wrote:\n\n> I tried looking for an answer to my problem online without much luck,\n> perhaps you can help me.  I'm SSHed from my laptop(Comp A) over to a\n> computer(Comp B) that has my git repo on it. I made some changes and\n> comitted them. Now I want to push them to my other server(Comp C). The\n> repository is password protected so if I'm physically at Comp B, I get\n> a gui prompt for my username and password. However Comp A does not\n> have X Forwarding setup to Comp B so I can't get the gui interface for\n> the username and password when I try to do the push.  Is there an\n> alternative way to provide my credentials when doing a git push that\n> does not require a gui?\n\nGit should prompt you on the terminal (i.e., the ssh session) if it\nneeds credentials. If it is not, and the terminal is accessible, it\nmight be a bug. There were some fixes around this area that went into\n1.7.9; you might try using that version.\n\nAlso, 1.7.9 ships with support for credential helper scripts, which can\nhelp you avoid putting in your password less frequently (see \"git help\ncredentials\" in git 1.7.9).\n\n-Peff\n"},{"id":"183765","messageId":"20120203213654.GD1890@sigill.intra.peff.net","threadId":"29537","inReplyTo":"34592.38.96.167.131.1328289027.squirrel@mail.lo-cal.org","subject":"Re: Push from an SSH Terminal","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T21:36:55Z","receivedAt":"2012-02-03T21:36:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:\n\n> > On Fri, Feb 3, 2012 at 11:21 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:\n> >>> The\n> >>> repository is password protected so if I'm physically at Comp B, I get\n> >>> a gui prompt for my username and password. However Comp A does not\n> >>> have X Forwarding setup to Comp B so I can't get the gui interface for\n> >>> the username and password when I try to do the push.  Is there an\n> >>> alternative way to provide my credentials when doing a git push that\n> >>> does not require a gui?\n> >>\n> >> What protocol are you using to access the repository on Comp C?\n> >>\n> > I'm pulling and pushing over HTTP from Comp C.\n> \n> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables\n> are set, and if the core.askpass config variable is set.  If any of these\n> are set, unset them.  Git should fall back to a simple password prompt.\n\nHmm, yeah that is likely the problem. I was thinking git would fall back\nto asking on the terminal, but it does not. We probably should.\n\n-Peff\n"},{"id":"183772","messageId":"20120203221324.GA8048@sigill.intra.peff.net","threadId":"29537","inReplyTo":"20120203213654.GD1890@sigill.intra.peff.net","subject":"Re: Push from an SSH Terminal","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T22:13:24Z","receivedAt":"2012-02-03T22:13:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 03, 2012 at 04:36:54PM -0500, Jeff King wrote:\n\n> > Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables\n> > are set, and if the core.askpass config variable is set.  If any of these\n> > are set, unset them.  Git should fall back to a simple password prompt.\n> \n> Hmm, yeah that is likely the problem. I was thinking git would fall back\n> to asking on the terminal, but it does not. We probably should.\n\nWe should probably do this:\n\n  [1/2]: prompt: clean up strbuf usage\n  [2/2]: prompt: fall back to terminal if askpass fails\n\n-Peff\n"},{"id":"183773","messageId":"20120203221411.GA8065@sigill.intra.peff.net","threadId":"29537","inReplyTo":"20120203213654.GD1890@sigill.intra.peff.net","subject":"[PATCH 1/2] prompt: clean up strbuf usage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T22:14:11Z","receivedAt":"2012-02-03T22:14:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The do_askpass function inherited a few bad habits from the\noriginal git_getpass. One, there's no need to strbuf_reset a\nbuffer which was just initialized. And two, it's a good\nhabit to use strbuf_detach to claim ownership of a buffer's\nstring (even though in this case the owning buffer goes out\nof scope, so it's effectively the same thing).\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nNeither is a big deal, but just some style cleanups while I was in the\narea.\n\n prompt.c |    3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/prompt.c b/prompt.c\nindex 72ab9de..64f817b 100644\n--- a/prompt.c\n+++ b/prompt.c\n@@ -21,7 +21,6 @@ static char *do_askpass(const char *cmd, const char *prompt)\n \tif (start_command(&pass))\n \t\texit(1);\n \n-\tstrbuf_reset(&buffer);\n \tif (strbuf_read(&buffer, pass.out, 20) < 0)\n \t\tdie(\"failed to get '%s' from %s\\n\", prompt, cmd);\n \n@@ -32,7 +31,7 @@ static char *do_askpass(const char *cmd, const char *prompt)\n \n \tstrbuf_setlen(&buffer, strcspn(buffer.buf, \"\\r\\n\"));\n \n-\treturn buffer.buf;\n+\treturn strbuf_detach(&buffer, NULL);\n }\n \n char *git_prompt(const char *prompt, int flags)\n-- \n1.7.9.rc1.28.gf4be5\n"},{"id":"183774","messageId":"20120203221602.GB8065@sigill.intra.peff.net","threadId":"29537","inReplyTo":"20120203213654.GD1890@sigill.intra.peff.net","subject":"[PATCH 2/2] prompt: fall back to terminal if askpass fails","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-03T22:16:02Z","receivedAt":"2012-02-03T22:16:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The current askpass code simply dies if calling an askpass\nhelper fails. Worse, in some failure modes it doesn't even\nprint an error (if start_command fails, then it prints its\nown error; if reading fails, we print an error; but if the\ncommand exits non-zero, finish_command fails and we print\nnothing!).\n\nLet's be more kind to the user by printing an error message\nwhen askpass doesn't work out, and then falling back to the\nterminal (which also may fail, of course, but we die already\nthere with a nice message).\n\nWhile we're at it, let's clean up the existing error\nmessages a bit.  Now that our prompts are very long and\ncontain quotes and colons themselves, our error messages are\nhard to read.\n\nSo the new failure modes look like:\n\n  [before, with a terminal]\n  $ GIT_ASKPASS=false git push\n  $ echo $?\n  128\n\n  [before, with no terminal, and we must give up]\n  $ setsid git push\n  fatal: could not read 'Password for 'https://peff@github.com': ': No such device or address\n\n  [after, with a terminal]\n  $ GIT_ASKPASS=false git push\n  error: unable to read askpass response from 'false'\n  Password for 'https://peff@github.com':\n\n  [after, with no terminal, and we must give up]\n  $ GIT_ASKPASS=false setsid git push\n  error: unable to read askpass response from 'false'\n  fatal: could not read Password for 'https://peff@github.com': No such device or address\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nArguably, the terminal-failure error message shouldn't even bother\nreporting errno. I can't imagine it failing for any reason other than\nENODEV, and the message would probably be less confusing as:\n\n  fatal: could not prompt on terminal for Password for...\n\n prompt.c |   24 +++++++++++++++++-------\n 1 files changed, 17 insertions(+), 7 deletions(-)\n\ndiff --git a/prompt.c b/prompt.c\nindex 64f817b..d851807 100644\n--- a/prompt.c\n+++ b/prompt.c\n@@ -9,6 +9,7 @@ static char *do_askpass(const char *cmd, const char *prompt)\n \tstruct child_process pass;\n \tconst char *args[3];\n \tstatic struct strbuf buffer = STRBUF_INIT;\n+\tint err = 0;\n \n \targs[0] = cmd;\n \targs[1]\t= prompt;\n@@ -19,15 +20,21 @@ static char *do_askpass(const char *cmd, const char *prompt)\n \tpass.out = -1;\n \n \tif (start_command(&pass))\n-\t\texit(1);\n+\t\treturn NULL;\n \n \tif (strbuf_read(&buffer, pass.out, 20) < 0)\n-\t\tdie(\"failed to get '%s' from %s\\n\", prompt, cmd);\n+\t\terr = 1;\n \n \tclose(pass.out);\n \n \tif (finish_command(&pass))\n-\t\texit(1);\n+\t\terr = 1;\n+\n+\tif (err) {\n+\t\terror(\"unable to read askpass response from '%s'\", cmd);\n+\t\tstrbuf_release(&buffer);\n+\t\treturn NULL;\n+\t}\n \n \tstrbuf_setlen(&buffer, strcspn(buffer.buf, \"\\r\\n\"));\n \n@@ -36,7 +43,7 @@ static char *do_askpass(const char *cmd, const char *prompt)\n \n char *git_prompt(const char *prompt, int flags)\n {\n-\tchar *r;\n+\tchar *r = NULL;\n \n \tif (flags & PROMPT_ASKPASS) {\n \t\tconst char *askpass;\n@@ -47,12 +54,15 @@ char *git_prompt(const char *prompt, int flags)\n \t\tif (!askpass)\n \t\t\taskpass = getenv(\"SSH_ASKPASS\");\n \t\tif (askpass && *askpass)\n-\t\t\treturn do_askpass(askpass, prompt);\n+\t\t\tr = do_askpass(askpass, prompt);\n \t}\n \n-\tr = git_terminal_prompt(prompt, flags & PROMPT_ECHO);\n \tif (!r)\n-\t\tdie_errno(\"could not read '%s'\", prompt);\n+\t\tr = git_terminal_prompt(prompt, flags & PROMPT_ECHO);\n+\tif (!r) {\n+\t\t/* prompts already contain \": \" at the end */\n+\t\tdie(\"could not read %s%s\", prompt, strerror(errno));\n+\t}\n \treturn r;\n }\n \n-- \n1.7.9.rc1.28.gf4be5\n"},{"id":"183813","messageId":"7vwr83hwg0.fsf@alter.siamese.dyndns.org","threadId":"29537","inReplyTo":"20120203213654.GD1890@sigill.intra.peff.net","subject":"Re: Push from an SSH Terminal","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T07:47:11Z","receivedAt":"2012-02-04T07:47:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:\n> ...\n>> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables\n>> are set, and if the core.askpass config variable is set.  If any of these\n>> are set, unset them.  Git should fall back to a simple password prompt.\n>\n> Hmm, yeah that is likely the problem. I was thinking git would fall back\n> to asking on the terminal, but it does not. We probably should.\n\nHow well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal\ntopic, which is now stalled [*1*]?  I do not mean this change and the other\ntopic textually conflict with each other---but the philosophies of this\ntopic and the other one seem to conflict.  Not falling back to the terminal\nthat is not available and failing the command outright might make more\nsense.\n\nI dunno.\n\n[Footnote]\n\n*1* Will the topic see any action soon?  I am inclined to throw the topic\ninto \"not even the original author is not interested\" category otherwise.\n"},{"id":"183815","messageId":"20120204080910.GA28317@sigill.intra.peff.net","threadId":"29537","inReplyTo":"7vwr83hwg0.fsf@alter.siamese.dyndns.org","subject":"Re: Push from an SSH Terminal","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-04T08:09:10Z","receivedAt":"2012-02-04T08:09:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:\n> > ...\n> >> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables\n> >> are set, and if the core.askpass config variable is set.  If any of these\n> >> are set, unset them.  Git should fall back to a simple password prompt.\n> >\n> > Hmm, yeah that is likely the problem. I was thinking git would fall back\n> > to asking on the terminal, but it does not. We probably should.\n> \n> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal\n> topic, which is now stalled [*1*]?  I do not mean this change and the other\n> topic textually conflict with each other---but the philosophies of this\n> topic and the other one seem to conflict.  Not falling back to the terminal\n> that is not available and failing the command outright might make more\n> sense.\n\nI don't see a conflict in the two series. That one seems to do two\nthings for perl programs:\n\n  1. respect SSH_ASKPASS along with GIT_ASKPASS\n\n  2. prefer askpass over asking on the terminal\n\nBut both of those are already the case in the C code.\n\nIf you look into the original complaint mentioned in the commit\nmessages, though, you will see that the some GUIs will appear to hang\nwhen the terminal is prompted (because the prompt is reading from some\nlocation invisible to the user). So in that sense, my patches could be a\nregression for those users, as outright failing is better for them.\n\nBut I would argue that the bug is not prompting on the terminal, but\nrather that the terminal-prompting code does not recognize when there is\nno terminal connection to the user (and AFAICT, this is a Windows\nproblem). Any solution that doesn't fix that is really just papering\nover the problem, and hurting people[1] on sane systems.\n\nSo I'd rather see the version of getpass() in compat/mingw.c better\nlearn to realize when we aren't actually connected to a console.\n\n-Peff\n\n[1] The amount of hurt is relatively small, though. It only hurts people\n    who set GIT_ASKPASS but can't use it (e.g., you set it in your\n    .bashrc because you connect via \"ssh -X\", but this time you happen\n    to be ssh-ing from a Windows box). And you can generally fix that\n    outside of git (e.g., by checking $DISPLAY before setting the\n    variable).\n\n    So one one hand, I don't want to make a decision on behavior for\n    Unix users because we have to cater to Windows shortcomings. On the\n    other hand, while fixing the root problem is preferable, if\n    for whatever reason we can't reliably find out whether the user is\n    actually going to see and respond to the prompt on Windows, it may\n    be practical to just paper over the issue. On the gripping hand,\n    after the Sven's series, TortoiseGit users would see the hang\n    (instead of a failure) _only_ if their askpass command failed. Which\n    is also perhaps not that big a deal.\n"},{"id":"183817","messageId":"7vhaz7hv3u.fsf@alter.siamese.dyndns.org","threadId":"29537","inReplyTo":"20120204080910.GA28317@sigill.intra.peff.net","subject":"Re: Push from an SSH Terminal","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T08:16:05Z","receivedAt":"2012-02-04T08:16:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>>  ...\n>> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal\n>> topic, which is now stalled [*1*]?  I do not mean this change and the other\n>> topic textually conflict with each other---but the philosophies of this\n>> topic and the other one seem to conflict.\n>\n> I don't see a conflict in the two series. That one seems to do two\n> things for perl programs ...\n\nThat is the \"[not] textually conflict\" part of my message.\n\n> If you look into the original complaint mentioned in the commit\n> messages, though, you will see that the some GUIs will appear to hang\n> when the terminal is prompted (because the prompt is reading from some\n> location invisible to the user). So in that sense, my patches could be a\n> regression for those users, as outright failing is better for them.\n\nYes, that is what I meant by \"philosophies conflict\".\n\n> But I would argue that the bug is not prompting on the terminal, but\n> rather that the terminal-prompting code does not recognize when there is\n> no terminal connection to the user (and AFAICT, this is a Windows\n> problem). Any solution that doesn't fix that is really just papering\n> over the problem, and hurting people[1] on sane systems.\n>\n> So I'd rather see the version of getpass() in compat/mingw.c better\n> learn to realize when we aren't actually connected to a console.\n\nThat is a sane diagnosis, I'd have to agree.\n\nThanks for a dose of sanity.\n\n> [1] The amount of hurt is relatively small, though. It only hurts people\n>     who set GIT_ASKPASS but can't use it (e.g., you set it in your\n>     .bashrc because you connect via \"ssh -X\", but this time you happen\n>     to be ssh-ing from a Windows box). And you can generally fix that\n>     outside of git (e.g., by checking $DISPLAY before setting the\n>     variable).\n>\n>     So one one hand, I don't want to make a decision on behavior for\n>     Unix users because we have to cater to Windows shortcomings. On the\n>     other hand, while fixing the root problem is preferable, if\n>     for whatever reason we can't reliably find out whether the user is\n>     actually going to see and respond to the prompt on Windows, it may\n>     be practical to just paper over the issue. On the gripping hand,\n>     after the Sven's series, TortoiseGit users would see the hang\n>     (instead of a failure) _only_ if their askpass command failed. Which\n>     is also perhaps not that big a deal.\n\nWow, you do have many hands ;-).\n"}]}