Git: Installer does not detect PuTTY

[arthurward]

I noticed that the Git for Windows installer does not know to elevate privileges automatically (it fails with "Setup was unable to create the directory "C:Program FilesGittmp". Error 5: Access is denied."). This can be worked around by using "Run as administrator," but that creates another problem -- the installer does not find the PuTTY installation while running from the administrator account.

In my environment, I have a normal account and an administrator account without logon privileges. To install software, the installer either needs to know to elevate privileges before copying files (most MSIs seem to do this), or I can run the installer as the admin account. It appears that the Git installer looks for PuTTY's user configuration before deciding to ask about using Plink, which never succeeds in this environment, because the admin account is not used in day-to-day work and has no PuTTY configuration data. The obvious workaround is to run PuTTY as administrator once and create a dummy session for the Git installer to see.

[dscho]

This looks like the installer behaves exactly as designed. Already a long time ago we had several bug reports where PuTTY (read: PLink) would not work correctly, so we dropped official support for this. We kept the choice only for power users who I assumed would know what they are doing.

Now, we could put that choice back for everybody, not only for users who already have saved connections for use with plink.exe, but that would bring back all those problems, too, without anybody to fix them.

[Fleshgrinder]

What problems are you referring to? Maybe the guy who develops KiTTY would be willing to help in fixing his klink.exe?

[arthurward]

Are there directions for changing that setting post-install that I have overlooked?

I know that PuTTY not needing an installer, plus all the Plink variants out there, makes detecting it a pain. It seems like probing for PuTTY in the default installation location or for its uninstall entry would be a useful check. Even without the admin/non-admin problem I ran in to, if you're setting up a new development machine, there won't be any PuTTY sessions in the registry until you start doing work.

[Fleshgrinder]

Yes, create an environment variable that points to your plink.exe (or klink.exe in my case), e.g.:

GIT_SSH="C:\Program Files\PuTTY\plink.exe"

Connect once with PuTTY to e.g. GitHub and cache the public key. Afterwards you only need to start pageant, import your private key, and unlock it with your passphrase before you start working with git for Windows in the shell of your choosing.

Works like a charm on my side and I never had any issues with it. :blush:

[dscho]

What problems are you referring to?

I forgot the details. Best bet is to look through the history of msysgit's /share/WinGit/install.iss.

[dscho]

I am constantly amazed how users with real problems cannot be bothered to do anything about it. This is what I _wished_ somebody who has the problem (i.e. not me) would have done:

1. Clone https://github.com/msysgit/msysgit (from where the install.iss originates that we use in our installer)
2. inspect that /share/WinGit/install.iss file, as indicated.
3. Find that line 546 is responsible for the PuTTY page being hidden unless the installing account has saved PuTTY sessions.
4. Use git blame to find out which revision introduced that guard:

sh $ git blame -L 546,546 install.iss` f11be46b (Sebastian Schuberth 2009-08-31 23:58:48 +0200 546) [...]

1. Inspect that revision
2. Since we did not include useful links in our commit messages back then, go by the date (August 31st, 2009) and search in the msysGit mailing list for the keyword putty around that time.
3. End up with the responsible thread.

After re-reading that entire thread, I do agree that it was a good idea to disable PuTTY support unless users had already saved PuTTY sessions.

So here we are, I am set back by half an hour in which I could not take care of more critical bugs, so I expect those who desire PuTTY support to put in _at least_ the same amount of time to _do_ something about it (chatting amiably does not really count).

I will accept any solution as long as it is

1. elegant and
2. does not leave _me_ with tons of user requests to deal with.

[Fleshgrinder]

Although I do not feel addressed by your comment, simply because I do not have a problem, I still feel the need to reply. Offering support for a product always involves answering dumb questions, but what it involves even more is to understand that other people do not know the history of a project or its inner workings; especially if it is very old. They do not know where to search, or maybe even how. What costs you half an hour might cost another person several days, in which that person could also do more important stuff (hopefully).

How to solve this? That is a question many people thought about since the dawn of mankind. Companies usually hire people to take care of such requests and questions, of course, you do not have that luxury since you develop an open source project. However, documenting things with e.g. a CHANGELOG or with other means can help. (Meaningful commit messages help.) Nonetheless, I do not think that there is a silver bullet.

I once read a very interesting blog post by a German author of an open source project who collected statistics of his support efforts over many years. Sadly I cannot find it … but the moral of the story was, that he spent more time supporting people than actually developing.

That said, do not start like Linus Torvalds and shit on people just because they think that you are producing an awesome thing and they do not understand it thoroughly; especially if you do not know those people. Otherwise you will end up bothering yourself and hurt the feelings of others (which is also not nice). :blush:

[dscho]

@Fleshgrinder and now maybe you can start helping me? :wink:

[Fleshgrinder]

Just read the thread you linked. I see two real problems:

1. Detecting if PuTTY (or any derivative) is actually installed.
2. When a server presents a previously unknown key everything hangs because PuTTY wants to ask the user for confirmation of trust but does not indicate that to the calling program.

I do not have the time to start developing because I need to create some other stuff, however, I can offer my ideas:

1. If the user selects the PuTTY option (that is simply always offered as an alternative) in the installer and the plink.exe cannot be found in the standard installation directory (which should be %ProgramFiles(x86)%\PuTTY or %ProgramFiles%\PuTTY if a x64 build is ever released) display a window where the user has to browse to the file manually. No need to check for existing sessions.
2. The only way would be to either ask the PuTTY developers to implement it or to port it from TortoisePlink to PuTTY and submit a patch. However, that would in turn require version checks. Opening a PuTTY terminal for the initial connect could also solve it, because PuTTY should present the window to the user in that case. How one could determine if a connection attempt is initial or not would be the problem here. I would display a warning message if PuTTY is used to connect to a host and offer a configuration option with which one is able to disable the warning. Additionally I would kill the connection attempt if it hangs for too long (e.g. 60 seconds) and display a detailed message that explains the user that an initial connection attempt has to be made via PuTTY itself because it is an awkward software that does not allow any interaction.

I really hope that my ideas are at least a bit helpful and not a waste of anyone's and especially your time. I would love to help with this stuff but I am part of too many projects already. :yum:

[dscho]

@Fleshgrinder I think that your contribution (while it is not code) is a valuable one: it summarizes the situation.

Funnily enough, even without showing the respective setting by default, just today a ticket came in to demonstrate the sorts of users' problems with PuTTY: https://github.com/git-for-windows/git/issues/482

[Fleshgrinder]

I am very glad that I could be of help. Ha ha ha, I can understand your frustration with the situation very well. I think it is a typical Windows situation with PuTTY, all these programs are optimized only for GUI usage.

[dscho]

I made up my mind about this ticket and close it now because I cannot fix anything here. It is easy enough to reopen it if anybody with the time and the expertise to actually do something about this issue.

[fourpastmidnight]

@dscho: I'm going to tackle this along with #682; I found the issue with why this isn't detected in the current Git for Windows installer.

If you use the PuTTY InnoSetup installer (which isn't recommended), the registry keys that the Git for Windows installer uses for determining if PuTTY sessions exist aren't created by that installer after a fresh install. Once a user creates session, then those registry keys exist. (I assume). I was able to confirm that once a session is created, these keys are created---as you would think would be the case. (17 Apr 2016)

Using the MSI PuTTY installer, however, those registry keys are created. But again, for a fresh install of PuTTY, there are no entries underneath the Sessions registry key--so even using the MSI installer, there's no guarantee that the Git for Windows installer will offer the choice to use PuTTY even if we know it exists on the system.

Yes, they have two installers, one is InnoSetup, the other MSI. They want people to use the MSI (but it's horribly broken, I must say), but they still offer the use of the InnoSetup installer. I'm already working on logic in #682 to properly detect the installation of PuTTY, no matter the installer technology used. Although, if the MSI installer is used, we won't know the location of PLink.exe (due to their very broken MSI). For the new MSI installer for Git for Windows, we can perform a file search for plink.exe in the default installation location of %ProgramFiles(x86)%\PuTTY. If we find it, great! If not, we'll need to ask the user for the location. This is what the current Git for Windows installer does (but only if the installer finds registry entries for PuTTY sessions).

The only question I have regarding giving the user choice to use PuTTY is: why do we care if any PuTTY sessions exist? Isn't it enough that PuTTY is installed to let the user choose to use PuTTY over OpenSSH? Granted, until a session exists, PuTTY will be useless--but then, they should know that if they're using PuTTY. And if not, there's plenty of info online to point someone in the right direction.

[dscho]

why do we care if any PuTTY sessions exist?

Because PuTTY does not really integrate well with Git for Windows. If you connect to a previously unknown host, PuTTY will ask you to acknowledge the fingerprint. Due to technical issues that nobody ever tried to resolve, the user input is not accepted, though. Therefore, we decided to discourage users from choosing the PuTTY option, unless they know what they are doing. Having saved connections is the tell-tale we settled on to determine whether the user knows what she is doing.

[fourpastmidnight]

@dscho I see. Just two more questions: Do I understand, then, that this issue you mention lies with PuTTY? And have newer versions of PuTTY been tried?

I used PuTTY back when I was first learning git with Atlassian's GUI (which, as far as GUIs go, is half decent) and had a great experience with it; but as you said, I already had a session setup.

I wonder, too, if we detect PuTTY and the user selects it, but there are no sessions, could we walk the user through setting one up at install time? (Though, I do question the value of this--the bundled OpenSSH client works OK and gets the job done.)

[dscho]

this issue you mention lies with PuTTY?

Yes, at least partially.

have newer versions of PuTTY been tried?

Not that I know of.

I wonder, too, if we detect PuTTY and the user selects it, but there are no sessions, could we walk the user through setting one up at install time?

I'd rather not. This is really PuTTY's duty, not Git for Windows. We also do not show users how to set up their OpenSSH configuration, they have to figure that out by themselves.

[landstander668]

For what it's worth, I'm currently in the process of integrating ssh-pageant into Git for Windows... expect to have the pull requests cleaned up (based upon dscho's feedback) tonight. This should make it easier to use OpenSSH instead of PuTTY, by allowing it to perform key-based authentication against Pageant.

I've been using it without issue for a couple of weeks now. It should work with Git Bash, Git CMD, and also when invoking Git directly from the Windows command prompt.

[fourpastmidnight]

@dscho: Thanks for the explanations. I do have one lingering concern, though. Please read this all the way through before responding--as my goals are truly aligned with yours, even though we may not _currently_ see eye-to-eye on this specific issue, but I'm still listening and I'm just playing the devil's advocate to ensure that we are serving our customers' best interests.

We also do not show users how to set up their OpenSSH configuration, they have to figure that out by themselves.

So, despite the fact that if someone who has installed PuTTY and (maybe) wants to use this as their SSH client, but has not configured any sessions, we're not going to offer them the opportunity to set PuTTY as their default SSH client when installing Git for Windows _even though_ when Git for Windows installs OpenSSH, it also is not configured?

If I'm understanding your explanations above correctly, from your POV, you want to provide the best, most positive user experience for Git for Windows users (and I wholeheartedly agree with that POV in general), and that the past user experience with an unconfigured PuTTY installation was not great--OK, apparently it sucked. But in this case, I just feel like I should point out the resulting irony when it comes to the choice of SSH client offered during installation and the outcome: In both cases, the user is left with an unconfigured (i.e. not ready to use) SSH client.

@landstander668: Please educate me, as I honestly don't know or understand: What is the benefit of your solution over just setting up PuTTY natively to work with Git via the GIT_SSH environment variable (e.g. see this StackOverflow question and answer and this linked-to guide)?

[landstander668]

@fourpastmidnight The advantage of ssh-pageant, which will largely be a matter of opinion, is simply that it makes it easier for all of the "heavy lifting" to be performed by OpenSSH... which tends to be more reliable and better tested than PuTTY, in the specific context of Git for Windows. Basically it's a drop-in replacement for ssh-agent, which ties key-based authentication requests into Pageant (so there's no need for multiple keystores, which don't work together).

Don't get me wrong... I have great of respect for the PuTTY project, and use it constantly in my day-to-day work. But for this project, OpenSSH works much better (in my experience).

As usual, your mileage may vary. (-;

[fourpastmidnight]

@landstander668: OK, fair enough. Thanks for the explanation.

[dscho]

I just feel like I should point out the resulting irony when it comes to the choice of SSH client offered during installation and the outcome: In both cases, the user is left with an unconfigured (i.e. not ready to use) SSH client.

The difference, of course, is that calling

git clone [email protected]:my-repository.git

would _still_ succeed with OpenSSH, after successfully asking the user to confirm the host fingerprint.

If you try the same trick with PuTTY, it _does_ ask the user to confirm the host fingerprint, but the answer is not accepted.

[fourpastmidnight]

@dscho: OK--so even though OpenSSH is not configured by Git for Windows during the installation, when "push comes to shove", in the end, OpenSSH just works and does what the user expects--PuTTY does not. That's too bad.

Thanks for your patience. :)

[dscho]

@fourpastmidnight it _is_ too bad. And no worries, explaining things like this is part of my job (even if I am sometimes scrambling for time to do it).

[fourpastmidnight]

After some discussion with @dscho and with what it would take to support this behavior in the MSI (which doesn't fit in well with the development workflow of the Git for Windows SDK), as well as the outstanding work @landstander668 provided with ssh-pageant which is now included with Git for Windows, this really doesn't make sense anymore.

From what I understand about ssh-pageant from the discussions above and over on #682, Git for Windows now comes with the ability to inter-operate with both your OpenSSH and PuTTY key-stores without as much fuss as it used to be.

Thanks @dscho and @landstander668 for your comments and help.