Git: curl sspi ntlm

Created on 2 Dec 2015  路  5Comments  路  Source: git-for-windows/git

There are two curl binaries in git-for-windows located into:

usr/bin/curl.exe
nimgw64/bin/curl.exe

But compiled with different features. The one in usr/bin misses the SSPI feature, which means that can not use proxy NTLM auth using the windows login credentials.

Details:

usr/bin/curl.exe -V
curl 7.45.0 (x86_64-pc-msys) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 libidn/1.32
libssh2/1.6.0
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp s
ftp smb smbs smtp smtps telnet tftp
Features: Debug IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets Met
alink

nimgw64/bin/curl.exe -V
curl 7.45.0 (x86_64-w64-mingw32) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 libidn/1.32
libssh2/1.6.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s
rtmp rtsp scp sftp smtp smtps telnet tftp
Features: IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP

Git works OK with NTLM+SSPI auth. But Git Bash puts first in the path the usr/bin version,

pending-answer unclear

Most helpful comment

Just out of curiosity, what is the reason of shipping two binaries? Is it an error or is needed for something?

(For background regarding MSys2 vs MinGW, the short version is that for some functionality, we rely on the POSIX emulation layer provided by MSys2, a slimmed down Cygwin. Whenever we can get away without using POSIX functionality, we try to rely on _MinGW_ instead, which targets the Win32 API directly.)

The curl package (which is the MSys2 package) is required by Perl. Perl needs MSys2 because it requires the fork() call. And we need Perl because git-svn is implemented as a Perl script that relies on Subversion bindings (and Subversion bindings is another thing that is really hard to do without POSIX functionality).

The mingw-w64-curl package (which is the MinGW package) is required by the HTTP(S) support of git.exe itself.

These packages _both_ include also the executables curl.exe you found. Therefore, it is actually _more_ work to ship with only one curl.exe because we have to _filter out_ one of them.

Feel free to patch our exclusion filter, make sure to test that your patch works by making and running an installer and then open a Pull Request.

If I did not have a couple of _really_ pressing other things to do, I would make that change myself, but as it is, I have to rely on your participation.

All 5 comments

Git Bash puts first in the path the usr/bin version,

This is not correct; Starting _Git Bash_ from the Start Menu results in this PATH:

me@work MINGW64 ~
$ echo $PATH
/c/Users/me/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:[...]

As you can clearly see, /mingw64/bin is in the PATH _before_ /usr/bin.

But maybe you started Git Bash differently and wanted to describe what you tried, precisely?

PATH problem aside it doesn't make sense to ship two curl binaries.

@ismail patches welcome.

You are rigth. Starting with git-bash.exe puts /migw64 first.

My fault. I was starting this using cmder which packages git-for-windows inside, and puts /usr/bin path first. My fault.

Just out of curiosity, what is the reason of shipping two binaries? Is it an error or is needed for something?

Just out of curiosity, what is the reason of shipping two binaries? Is it an error or is needed for something?

(For background regarding MSys2 vs MinGW, the short version is that for some functionality, we rely on the POSIX emulation layer provided by MSys2, a slimmed down Cygwin. Whenever we can get away without using POSIX functionality, we try to rely on _MinGW_ instead, which targets the Win32 API directly.)

The curl package (which is the MSys2 package) is required by Perl. Perl needs MSys2 because it requires the fork() call. And we need Perl because git-svn is implemented as a Perl script that relies on Subversion bindings (and Subversion bindings is another thing that is really hard to do without POSIX functionality).

The mingw-w64-curl package (which is the MinGW package) is required by the HTTP(S) support of git.exe itself.

These packages _both_ include also the executables curl.exe you found. Therefore, it is actually _more_ work to ship with only one curl.exe because we have to _filter out_ one of them.

Feel free to patch our exclusion filter, make sure to test that your patch works by making and running an installer and then open a Pull Request.

If I did not have a couple of _really_ pressing other things to do, I would make that change myself, but as it is, I have to rely on your participation.

Was this page helpful?
0 / 5 - 0 ratings