Git: askpass Git GUI in CLI

[CodeGuro]

• [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.12.2.windows.2
built from commit: 7723f38cfb0e80f010afaebdd9fec4d0822fd2e1
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 7 64-bit

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Defaults

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git push origin master # or any variation thereof

• What did you expect to occur after running these commands?

A CLI password prompt, similar to that when using ssh, or Git v1.9.4

• What actually happened instead?

A graphical password prompt, "mingw64/libexec/git-core/git-gui--askpass"
Aggh.
Nothing irritates me more than if some new feature is pushed down without being thought out clearly.
So, it looks like sometime within the last couple months someone thought it would be a good idea to integrate git (yes, regular CLI git) with Kwallet, and now it's likely an update has been pushed down that does this. Who's brilliant idea was it to integrate git-gui to the core CLI?
Problem though is that CLI git unlike any of the Git viewers, regular git is not a GUI app so now is complaining about the usual dbus errors associated with launching a KDE app from the CLI.

These days Linux systems tend to open graphical password prompts when a CLI application needs user authentication. I don't know about you but I really don't like that.
Thankfully you can tell git not to use it:

git config --global core.askpass ""

Or

unset SSH_ASKPASS

But those above are hacks. There should be a way to configure Git core from setup to not use this ssh askpass garbage.

[shiftkey]

So, it looks like sometime within the last couple months someone thought it would be a good idea to integrate git (yes, regular CLI git) with Kwallet, and now it's likely an update has been pushed down that does this. Who's brilliant idea was it to integrate git-gui to the core CLI?

I'm not sure why you're seeing Kwallet here. Could you provide some screenshots of what you're seeing, to ensure we're not looking at Git Credential Manager for Windows.

Problem though is that CLI git unlike any of the Git viewers, regular git is not a GUI app so now is complaining about the usual dbus errors associated with launching a KDE app from the CLI.

I'm very curious what you're seeing here because this doesn't quite feel like the Git for Windows experience...

[shiftkey]

Oh, and what sort of remote repository are you trying to push to (GitHub/Bitbucket/GitLab/VSTS/???)?

[CodeGuro]

@shiftkey What I'm getting at is that I'm getting a GUI prompt when I expect a CLI prompt and there's no way to disable it. The following screenshots are taken after a fresh install of Git and no "Git Credential Manager for Windows" is checked.

The remote repository I'm trying to push to is my own company's (I can't say which due to my company policy, but I can tell you I'm pushing to a bare Git repository).

The following are screenshots. I had to censor the details, but they may as well be foo/bar for the scope of this issue.
This is what I'm getting:

This is what I'm getting when I cancel it and get a proper CLI passwd prompt:

[whoisj]

@CodeGuro is there an environment variable registering the askpass executable?

GIT_ASKPASS or SSH_ASKPASS perhaps? Even then, OpenSSH usually will not invoke the askpass application unless it believes that there's no tty available.

[dscho]

Nothing irritates me more than if some new feature is pushed down without being thought out clearly.

For the record, whenever I read a statement like this in a bug report during busy times, I have to stay away from this issue.

Pro-Tip: If you want me to help, avoid discouraging me from doing so.

[dscho]

here should be a way to configure Git core from setup to not use this ssh askpass garbage.

Okay, so here goes: That kind of statement is not welcome here. If you disagree with any decision others made, you can do so respectfully, and indeed, this is what I ask you to do.

I understand that you are frustrated, but that does not give you license to make this project less fun for those who actually make all the little gears turn in the background.

There is a good opportunity here to redeem yourself: as you already suggested a good solution, and as this solution is not even technically challenging, I would like to encourage you to implement it.

The first step is to make a Git for Windows installer in your setup.

Once you have that, you will want to patch the file /usr/src/build-extra/installer/install.iss to implement that option. The easiest way would be to search for GP_GCM (i.e. for the parts of the code that enable/disable the use of the Git Credential Manager) and imitate the code, up to and including the call to git config.

[landstander668]

@CodeGuro Are you absolutely certain that core.askpass wasn't inadvertently set at some point before encountering this issue? The only time I've ever seen that behaviour is when it's explicitly configured, which doesn't appear to be part of a stock installation... here's everything I had configured following a fresh install (previous version uninstalled, and all configuration files verified to be removed) of 2.13.0 64-bit on Windows 10.

$ git config --list --show-origin file:"C:\\ProgramData/Git/config" core.symlinks=false file:"C:\\ProgramData/Git/config" core.autocrlf=true file:"C:\\ProgramData/Git/config" core.fscache=true file:"C:\\ProgramData/Git/config" color.diff=auto file:"C:\\ProgramData/Git/config" color.status=auto file:"C:\\ProgramData/Git/config" color.branch=auto file:"C:\\ProgramData/Git/config" color.interactive=true file:"C:\\ProgramData/Git/config" help.format=html file:"C:\\ProgramData/Git/config" rebase.autosquash=true file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" diff.astextplain.textconv=astextplain file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" filter.lfs.clean=git-lfs clean -- %f file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" filter.lfs.smudge=git-lfs smudge -- %f file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" filter.lfs.required=true file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" filter.lfs.process=git-lfs filter-process file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig" credential.helper=manager
The output from a fresh install of 2.12.2.2 was effectively identical.

[whoisj]

@CodeGuro any chance you have a DISPLAY environment variable set? That can get OpenSSH to display the authentication dialog in certain circumstances.

[CodeGuro]

@whoisj
Apologies for the late response. Yes, your input was helpful - SSH_ASKPASS was being set. I'd like to reiterate that 'Git Credential Manager for Windows' was not checked for that installation.

@landstander668
I'm fairly certain that core.askpass was being set, somewhere. I had a previous installation where 'Git Credential Manager' was checked, then I did an uninstall, then a re-install it with with that check-mark omitted. I'm suspecting there was an artifact left behind from the previous installation, but I don't know what or where.

@dscho
I didn't realize the community here was so sensitive. I think I see why Linus Torvalds doesn't like being associated with it very much. I think we can be civil to one another without policing each other's language, hmm? As for the solution, thanks for the challenge, but I think I'll pass. My job keeps me fairly busy so I don't have the time. I resolved my problem with a quick hack by editing the script that sets the SSH_ASKPASS environment variable, but others who use this installer may not have that skill or luxury. That's why I opened this issue.

[dscho]

I think we can be civil to one another

That was all I asked for.

As for the solution, thanks for the challenge, but I think I'll pass.

Okay, let's close this ticket, then.