ssh.exe not found after update to 3.5.2

[tomas-laubr-smart-software]

Current behaviour

Cannot git push. When pushing to repository, an error appeared. See screenshot.

Expected behaviour

Git push works

Steps to reproduce

1. Have properly configured git extensions.
2. I had set SSH "Other ssh client", path C:\Program Files\Git\usr\bin\ssh.exe
3. Perform automatic update to latest 3.5.2 version

Screenshots

There should be a screenshot

Did this work in previous version of GitExtensions

Environment

• GitExtensions version:
• GIT version:
• OS version: Windows 10/x64
• .NET version:

Diagnostics

[tomas-laubr-smart-software]

[gerhardol]

What is the value in Settings?

With the OpenSSH in Git the value uses empty value for the corresponding backing registry key gitssh in [HKEY_USERS\SOFTWARE\GitExtensions]

[tomas-laubr-smart-software]

Right after the update, it was set to C:\Program Files (x86)\Git\usr\bin\ssh.exe See the screenshot. Then I had to change it to C:\Program Files\Git\usr\bin\ssh.exe in order to make it work. That is the correct path and I believe it was set in settings before update.

[RussKie]

@mstv did you work in this area lately?

[mstv]

did you work in this area lately?

@gerhardol did. I changed the handling of the Linux Tools dir (a.k.a. AppSettings.GitBinDir, which should be renamed.)

[gerhardol]

The problem that the ssh path is changed at upgrades is not new, it has occurred for me for at least five years. Problem is hard to pinpoint it seems.

There is something in the installer that occasionally changes the paths, before 3.5.2 reverting to PuTTY. Maybe flipping the setting? Will be "solved" in master when PuTTY binaries are dropped from GE and the stage is removed in the installer. Draft in #9386 (awaiting that WiX installer works with .NET5).
Before 3.5 the path to OpenSSH ssh.exe was always written to the registry and the environment variable GIT_SSH, now it is empty. If the setting matches the expected Git path, it is "cleaned", but if an incorrect setting has been introduced it cannot be fixed.

It may also not be possible to select the paths to 64bit executables, discussed in #9355. GE will not use the GIT_SSH path internally anyway, so that should be allowed. It is OK to change this manually though.

The search paths are preferring the x86 paths too, changed in #9386 too.

I do not want to change the installer in 3.5. The preferred path handling in #9386 and maybe possibility to select paths as mentioned in #9355 should maybe be applied.

--
Maybe GIT_SSH should not be overridden if already set (but this must be displayed in settings) and SSH settings removed from registry too.

[RussKie]

When we search for ssh, should we search under %PROGRAMFILES(x86)%, %PROGRAMFILES% and %GIT_SSH% (if it is set)?

[gerhardol]

If OpenSSH is used the path should be empty as the ash bundled with Git should be used.
This was incorrectly set some years ago.

If using plink or other, search should be done only in settings, no other adjustments.

[gerhardol]

To be clear: GE never uses ssh.exe, only passes on the configuration to Git.
If PuTTY is used, GE assists with starting PageAnt and such but not plink/ssh.exe.

[RussKie]

Do you think in this case we should show this screen whenever we open a new instance of the app, and get the user to fix it (or at least be aware of this)?

Despite the checked option below the dialog isn't shown...

[gerhardol]

An unknown ssh path is not a problem in itself, ge as a 32 bit app may not be able to check the path. Ge never accesses the path, just set the env var for Git.

[RussKie]

I'm just trying to think how we can alert a user to the issue

[gerhardol]

See also #9355
The filepicker and maybe other path checks need to allow 64 bit paths.
But this probably only applies to some %windir% paths, not an issue here.

Also #9386 is related, removing PuTTY and changes search paths to PuTTY binaries.
There is no explicit search for ssh.exe

--

Most users use the standard OpenSSH with Git which is handled as an empty path in GE settings.
This was populated as a full path in some GE versions though.

The check in Checklist will check the path if it exists or not which may be incorrect. The text in master is changed in this situation to state that the path is not found (as well as reporting Other rather than Unknown for other paths).
(The path check need to check 64 bit too.)

master will also try to 'migrate' paths that are explicitly set if they match the Git OpenSSH path.
(I added that migration, but have considered removing it and rely on user specific actions, it is just that settings point to "Other" rather than "OpenSSH". Maybe OK to have migration in CheckSettings.)

--

So a path check could be done at first startup after upgrade (already there?), to display this better.
The settings page is not shown if there are no errors or if GE believes it has autosolved the problem. There is no autosolver for SSH (you would get this for Git for instance).
I will open a PR for this.

But GE app does not manipulate the SSH path to cause these problems.
Likely, the installer is the core problem, but I do not see it.

Maybe some plugin is involved?

--

Related, not a problem here though.
Maybe GE should remove the SSH (and Git) path settings from the registry. The env var GIT_SSH should then be used to allow a global configuration for SSH (and as a hint for Git path?).
But I would like to make as few changes as possible here, it obviously is sensitive.