git-for-windows/git

"credential-cache unavailable; no unix socket support"

hickford opened this issue · 12 comments

hickford commented

I tried to run git-credential-cache but got an error:

> git credential-cache
fatal: credential-cache unavailable; no unix socket support

Others have reported the same error https://stackoverflow.com/questions/67951554/error-fatal-credential-cache-unavailable-no-unix-socket-support

A workaround is to install and configure Git Credential Manager git-credential-manager-core --configure. The default credential store Windows Credential Manager works well.

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.36.1.windows.1
cpu: x86_64
built from commit: e2ff68a2d1426758c78d023f863bfa1e03cbc768
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.19043.1682]
dscho commented

fatal: credential-cache unavailable; no unix socket support

Well, it is true. Windows does not have Unix socket support in general. As per this comment:

echnically, since Git v2.34.0, git-credential-cache.exe can be built and run on Windows. Unix Sockets support has been introduce into Windows. The problem is that you need Windows 10 build 17061 or later, and Git for Windows still supports even Vista (although it has been announced that Git for Windows will drop supporting Vista really soon now).

Now, the question is: how much are you interested in getting Git for Windows to support credential-cache on Windows versions that support Unix sockets @hickford? Interested enough to work on a PullRequest? If so, I will be glad to assist, but I won't be able to justify the time to work on it myself.

hickford commented

How might that work? I don't have much C experience. Is it possible to change an optional compile-time dependency to a conditional runtime dependency? Or would Git for Windows have to compile credential-cache with and without sockets, and install the appropriate copy for the system?

rimrul commented

It is possible to query for unix socket support at runtime and we have ways to load CRT functions at runtime if available, so that approach is theoretically feasible.

hickford commented

ways to load CRT functions at runtime if available

@rimrul Do you have any examples to follow?

The good news is that credential-cache is confirmed to function on Windows if compiled (thanks @carenas).

rimrul commented

Yes, of course. Sorry for not providing you with more actionable info on this.

We have the macros DECLARE_PROC_ADDR() and INIT_PROC_ADDR() defined in compat/win32/lazyload.h.

You can see them in use in t/helper/test-drop-caches.c, compat/winansi.c, compat/win32/trace2_win32_process_info.c and two times in compat/mingw.c.

hickford commented

@rimrul interesting. This seems slightly different. If I understand correctly, the winsock2.h socket function in Ws2_32.dll is available on all versions of Windows. What's missing in older versions is header afunix.h with struct sockaddr_un.

What happens at runtime if you build with sockets on Windows 10 then try to run on Windows 7?

According to the docs above, the socket function should return error INVALID_SOCKET (specific error code WSAGetLastError). But will the application even start?

dscho commented

What happens at runtime if you build with sockets on Windows 10 then try to run on Windows 7?

@hickford It won't work. Likewise if you run on older Windows 10 that lack support for AF_UNIX. Something we need to test specifically, to ensure that the users will see a helpful error message (and not, say, a crash).

rimrul commented

What happens at runtime if you build with sockets on Windows 10 then try to run on Windows 7?

@hickford It won't work. Likewise if you run on older Windows 10 that lack support for AF_UNIX. Something we need to test specifically, to ensure that the users will see a helpful error message (and not, say, a crash).

I did some testing. Running Git for Windows 2.43.0 built without NO_UNIX_SOCKETS on Windows 8.1 we don't get a crash. Directly calling git credential-cache produces the usage message as it would on systems with unix sockets. Actually using the credential helper as a credential helper in git clone produces this not great error message:

fatal: unable to connect to cache daemon: Unknown error

I think we could improve that error message with a runtime check.

  • The simplest check would be to see if GetVersion() reports that we're on Windows 10 build 17063 or newer. That should work for most cases, but might not work in certain edge cases.
  • Microsoft recommends checking sc query afunix, but I'd rather not shell out to a new process if we don't have to. We could probably achieve the same result using OpenServiceA()/OpenServiceW() and QueryServicestatus()/QueryServiceStatusEx(),
  • We could also just try wether we can successfully create a unix socket at startup.
  • 👍1
hickford commented

@rimrul Exciting ideas!

Git for Windows 2.43.0 built without NO_UNIX_SOCKETS

Please could you share git-credential-cache.exe and git-credential-cache--daemon.exe here?

rimrul commented

Git for Windows 2.43.0 built without NO_UNIX_SOCKETS

Please could you share git-credential-cache.exe and git-credential-cache--daemon.exe here?

I could do that, but do you really want my locally built binaries that are just without NO_UNIX_SOCKETS? Wouldn't it make more sense to extract the binaries with the dynamic detection from the windows-artifacts CI build artifact at https://github.com/git-for-windows/git/actions/runs/7491375798?

hickford commented

@rimrul I can't find the credential-cache binaries in windows-artifacts.zip.

ogauge commented

some one stole all my files and just so happens it was done by google