Environment

• Git Extensions 4.2.0.17591
• Build bf814d4
• Git 2.42.0.windows.2
• Microsoft Windows NT 10.0.19045.0
• .NET 6.0.25
• DPI 96dpi (no scaling)
• Portable: False
• Microsoft.WindowsDesktop.App Versions

    Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Issue description

In previous versions, when we opened Git bash from within Git Extensions, and worked in Git bash with remote repositories via SSH, we were asked the passphrases for the respective SSH keys directly in the Git bash terminal. Once we had typed the passphrase into the terminal, or had copied it from a password manager to there, the respective SSH keys were unlocked, and the operation in question was carried out. That worked reliably.

Since the upgrade to the version indicated above, we can't type passphrases for the SSH keys directly in the terminal any more, or copy them to there from our password manager. Instead, a GUI dialog box opens where we should type (or copy) our passphrase into. Apart from the fact that this is worrying and superfluous, the real problem is that this git cli command stdin wrapper does not process our passphrases correctly.

That is, even if we type the passphrase correctly in that GUI dialog, the respective SSH key is not unlocked, claiming that the passphrase is wrong. Of course, this has disabled our access to all our remote repositories.

Steps to reproduce

• Create a remote repository that can be reached via SSH.
• Protect the private SSH key with a long and complex passphrase that contains special characters (*).
• Open Git bash from within Git Extensions.
• From within Git bash, try to access the remote repository (e.g. clone it), which will make the Git cli stdin wrapper appear.
• Type your passphrase into the Git command line stdin wrapper.
• Observe that it claims that your passphrase is wrong and that the SSH key cannot be unlocked, although you have entered the passphrase correctly. This prevents you from accessing your remote repositories.

(*) I can't tell how the passphrase must be crafted to reproduce the problem. Unfortunately, I cannot provide the passphrases that I am using, because they are used in production. However, I believe that German umlauts in the passphrase are enough to trigger the problem.

Did this work in previous version of GitExtensions?

Ambiguous answer: Yes and no.

Yes, entering the passphrase worked in all previous versions, because the previous versions did not feature that Git cli command line stdin wrapper. Typing or copying the passphrase into the Git bash terminal has always worked like a charm.

But no, the command line stdin wrapper did not work in previous versions, because it didn't exist yet (at least it wasn't active by default).

Diagnostics

I apologize that I don't have the time to generate diagnostics or to answer further questions right now. However, I believe that the problem can easily be reproduced.

Finally, two hints:

• It is obvious that the stdin wrapper does not handle character encodings correctly. Either the conversion from the source encoding (Windows) to the internal encoding (if any) works incorrectly, or the conversion from the internal encoding to the Git bash encoding works incorrectly.
• If code from the Putty project has been used to implement that stdin wrapper: We had exactly the same problem with Putty's passphrase converter (which is the reason why we stopped using Putty a while ago).

Thank you very much,

Binarus