git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/6] echo usernames as they are typed

From
Erik Faye-Lund <kusmabite@gmail.com>
Date
Nov 28, 2011, 12:59 UTC
Message-ID
<CABPQNSYd8PFsoRi6NtjQYNQzM+NHv_aRCLRWQ=XsFuw2gGWAng@mail.gmail.com>
In-Reply-To
<20111128113127.GA23408@sigill.intra.peff.net>
On Mon, Nov 28, 2011 at 12:31 PM, Jeff King <peff@peff.net> wrote:
Show 45 quoted lines
> On Mon, Nov 28, 2011 at 10:36:21AM +0100, Erik Faye-Lund wrote:
>
>> > You really want to open "/dev/tty" on most Unix systems (which is what
>> > getpass() does).
>>
>> Yes, you're right. Opening "/dev/tty" is much better. But what happens
>> for processes started by GUI applications (with no easily observable
>> tty, if any)? Does open simply fail? If so, is it desirable for us to
>> fail in that case?
>
> Yes, the open will fail (on Linux, I get ENXIO).
>
> And yes, we should fail in that case. getpass() will generally return
> NULL in that instance, and the current implementation of git_getpass()
> will die(), explaining that we could not get the password.
>
>> > I have no idea what would be appropriate on Windows.
>>
>> It's pretty similar, but not exactly: CreateFile("CONIN$", ...) or
>> CreateFile("CONOUT$", ...), depending on if you want the read-handle
>> or the write-handle... I can probably cook up something a bit more
>> concrete, though.
>
> OK, that maps to the /dev/tty concept quite well. Though I suspect the
> code for turning off character echo-ing is going to also be different.
>
>> But _getch() that we already use always reads from the console
>> (according to MSDN, I haven't actually tested this myself:
>> http://msdn.microsoft.com/en-us/library/078sfkak%28v=VS.80%29.aspx).
>> But I don't think this allows us to fail when no console is attached.
>> Question is, should we fail in such cases? Windows does have an API to
>> prompt for passwords in a GUI window... Perhaps fallbacking to those
>> are the way to go? Something like:
>>
>> if (GetConsoleWindow()) {
>>       /*  normal console-stuff */
>> } else {
>>       /* call CredUIPromptForWindowsCredentials(...) instead */
>> }
>
> Certainly on non-Windows something like that would not be welcome. The
> user can already have specified GIT_ASKPASS if they don't have a
> terminal. And once the credential-helper code is in, they can use a
> platform-specific helper that provides a nice dialog if they want it.
>

Yes, that's certainly cleaner implementation-wise. But didn't you change it to only do the storage-part in the last round, or did I misunderstand the updated series?

> So I would say trying to do something graphical would be surprising and
> unwelcome. But then, I am a very Unix-y kind of guy. Maybe on Windows
> something like that would be more favorable. I'll leave that decision to
> people who know more.

Windows doesn't really have that strict norms when it comes to console applications, but it'd be nice if it didn't do anything obviously wrong when the GUI isn't available (non-interactive sessions, PowerShell remote commands, CopSSH, etc). So I guess this is yet another argument to stay with the credential-helper instead, if possible...

Previous: Frans KlaverNext: Jeff King
Message 48 of 49 in “credential helpers, take two”
  1. 0/13 credential helpers, take twoJeff King, Nov 24, 2011
  2. 01/13 test-lib: add test_config_global variantJeff King, Nov 24, 2011
  3. 02/13 t5550: fix typoJeff King, Nov 24, 2011
  4. 03/13 introduce credentials APIJeff King, Nov 24, 2011
  5. Junio C HamanoNov 28, 2011
  6. Jeff KingNov 29, 2011
  7. Junio C HamanoNov 29, 2011
  8. Jeff KingNov 29, 2011
  9. 04/13 credential: add function for parsing url componentsJeff King, Nov 24, 2011
  10. 05/13 http: use credential API to get passwordsJeff King, Nov 24, 2011
  11. 06/13 credential: apply helper configJeff King, Nov 24, 2011
  12. 07/13 credential: add credential.*.usernameJeff King, Nov 24, 2011
  13. 08/13 credential: make relevance of http path configurableJeff King, Nov 24, 2011
  14. 09/13 docs: end-user documentation for the credential subsystemJeff King, Nov 24, 2011
  15. 10/13 credentials: add "cache" helperJeff King, Nov 24, 2011
  16. Eric SunshineNov 24, 2011
  17. Junio C HamanoNov 29, 2011
  18. Jeff KingNov 29, 2011
  19. 11/13 strbuf: add strbuf_add*_urlencodeJeff King, Nov 24, 2011
  20. Junio C HamanoNov 29, 2011
  21. Jeff KingNov 29, 2011
  22. René ScharfeNov 29, 2011
  23. Jeff KingNov 30, 2011
  24. Junio C HamanoNov 30, 2011
  25. René ScharfeNov 30, 2011
  26. 12/13 credentials: add "store" helperJeff King, Nov 24, 2011
  27. Eric SunshineNov 24, 2011
  28. Jeff KingNov 24, 2011
  29. Junio C HamanoNov 29, 2011
  30. Jeff KingNov 29, 2011
  31. 13/13 t: add test harness for external credential helpersJeff King, Nov 24, 2011
  32. Erik Faye-LundNov 24, 2011
  33. Jeff KingNov 24, 2011
  34. Erik Faye-LundNov 24, 2011
  35. 0/6 echo usernames as they are typedJeff King, Nov 27, 2011
  36. 1/6 move git_getpass to its own source fileJeff King, Nov 27, 2011
  37. 2/6 refactor git_getpass into generic prompt functionJeff King, Nov 27, 2011
  38. 3/6 stub out getpass_echo functionJeff King, Nov 27, 2011
  39. 4/6 prompt: add PROMPT_ECHO flagJeff King, Nov 27, 2011
  40. 5/6 credential: use git_prompt instead of git_getpassJeff King, Nov 27, 2011
  41. 6/6 compat/getpass: add a /dev/tty implementationJeff King, Nov 27, 2011
  42. Junio C HamanoNov 27, 2011
  43. Erik Faye-LundNov 27, 2011
  44. Jeff KingNov 28, 2011
  45. Erik Faye-LundNov 28, 2011
  46. Jeff KingNov 28, 2011
  47. Frans KlaverNov 28, 2011
  48. Erik Faye-LundNov 28, 2011
  49. Jeff KingNov 28, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.