credential: do not mask the username

When a user is asked for credentials there is no need to mask the username, so the PROMPT_ASKPASS flag on calling credential_ask_one for login is unnecessary.

The credential_ask_one() function internally uses git_prompt() which in case it is given the flag PROMPT_ASKPASS uses masked input method instead of git_terminal_prompt, which does not mask user input.

This fixes https://github.com/git-for-windows/git/issue/675

Signed-off-by Jarosław Honkis <[email protected]>

Signed-off-by Johannes Schindelin <[email protected]>

Quoted 4 lines · Jarosław Honkis via GitGitGadget

When a user is asked for credentials there is no need to mask the username, so the PROMPT_ASKPASS flag on calling credential_ask_one for login is unnecessary.

Quoted 5 lines

The credential_ask_one() function internally uses git_prompt() which in case it is given the flag PROMPT_ASKPASS uses masked input method instead of git_terminal_prompt, which does not mask user input.

This fixes https://github.com/git-for-windows/git/issue/675

This link is dead. Is there a more modern URL to which this can point?

Quoted 2 lines

Signed-off-by Jarosław Honkis <[email protected]>

Signed-off-by Johannes Schindelin <[email protected]>

From: =?UTF-8?q?Jaros=C5=82aw=20Honkis?= <[email protected]>

When a user is asked for credentials there is no need to mask the username, so the PROMPT_ASKPASS flag on calling credential_ask_one for login is unnecessary.

The credential_ask_one() function internally uses git_prompt() which in case it is given the flag PROMPT_ASKPASS uses masked input method instead of git_terminal_prompt, which does not mask user input.

Quoted 6 lines · Jarosław Honkis via GitGitGadget

From: =?UTF-8?q?Jaros=C5=82aw=20Honkis?= <[email protected]>

When a user is asked for credentials there is no need to mask the username, so the PROMPT_ASKPASS flag on calling credential_ask_one for login is unnecessary.

Quoted 3 lines

The credential_ask_one() function internally uses git_prompt() which in case it is given the flag PROMPT_ASKPASS uses masked input method instead of git_terminal_prompt, which does not mask user input.

This description (and the patch) doesn't make sense to me. The PROMPT_ASKPASS flag is just about whether we would trigger the askpass tool (e.g., if the user does not have a terminal).

The PROMPT_ECHO flag is what you want to tell the underlying code that the value can be shown to the user. And that's already set.

Now there is a slight issue, which is that the askpass tool has no way for us to tell it to show the contents to the user. There's no way around that without disabling askpass entirely, which I guess is the strategy this patch is trying to do.

But in doing so it's going to break anybody who _doesn't_ have a terminal, because now we have no way to prompt there for their username!

So I think our options are:

1. Leave it. If people don't want askpass to prompt them, they should not set up askpass.

2. Use another tool besides askpass. I don't know of any askpass implementations that take something like our ECHO flag, but there are lots of other tools. I doubt there's any easy portable solution, though. And anyway, credential helpers are a much more advanced version of this anyway, so I'd probably steer people in that direction.

3. If we really want to try to try to avoid using askpass for usernames we can, but I don't think the logic in this patch is right.

If we want to avoid regressing existing cases, then we'd have to first check if there's a usable terminal. And only if _that_ fails, try askpass. And then give up if neither work. I.e., invert the order in git_prompt() when both ASKPASS and ECHO are set.

I think I'd still favor option 1 over this, though. Configuring askpass has always overridden the terminal for usernames, and this would change that. I come back to: if you don't want to use askpass, then why are you configuring it?

credential.c static void credential_getpass(struct credential *c) · line 141

Quoted 5 lines

credential.c +3 -1

 		c->username = credential_ask_one("Username", c,
-						 PROMPT_ASKPASS|PROMPT_ECHO);
+						 (getenv("GIT_ASKPASS") ?
+						  PROMPT_ASKPASS : 0) |
+						 PROMPT_ECHO);

This logic is weird. It still uses askpass if GIT_ASKPASS isn't set. But _doesn't_ if it's set elsewhere, e.g. in core.askPass. Which makes little sense to me.

Maybe the intent was that the original user has SSH_ASKPASS set, and that is kicking in (which would also explain why "if you don't like it, don't configure it" didn't work). You can get around that by setting GIT_ASKPASS (or core.askPass) to the empty string (I don't think that's documented anywhere, and I don't recall it being intentional, but it does look like that's how the code works).

Quoted 6 lines

2. Use another tool besides askpass. I don't know of any askpass implementations that take something like our ECHO flag, but there are lots of other tools. I doubt there's any easy portable solution, though. And anyway, credential helpers are a much more advanced version of this anyway, so I'd probably steer people in that direction.

[...]

How about inventing a new convention: we could set GIT_ASKPASS_FLAGS as an environment variable that contains whitespace-delimited flags, in the current instance just "echo"?

We could then teach git-gui--askpass to heed that.

Mind you, these days, this patch is a lot less necessary because Git for Windows (which is *the* platform where you'd expect no terminal to be available when fetching/pushing, right?) defaults to using the Git Credential Manager [*1*].

What do you think about the GIT_ASKPASS_FLAGS thing? It is not perfect, but it could be used at least in conjunction with git-gui--askpass (or with other helpers that would make use of this side channel to receive more information about the way they should present the question to the user)?

Alternatively, I could simply drop that patch from Git for Windows, as it really only concerns users who override the default, opting out of using Git Credential Manager.

Quoted 3 lines · Johannes Schindelin

Alternatively, I could simply drop that patch from Git for Windows, as it really only concerns users who override the default, opting out of using Git Credential Manager.

would be the path I would take.