git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.37k stars 2.54k forks source link

http.schannel.checkRevoke option is not recognized #1531

Closed yopito closed 6 years ago

yopito commented 6 years ago

Setup

$ git --version --build-options
git version 2.16.2.windows.1
cpu: x86_64
built from commit: e1848984d1004040ec5199e749b5f282ddf4bb09
sizeof-long: 4
$ cmd.exe /c ver

Microsoft Windows [version 6.1.7601]

$ echo $PROCESSOR_ARCHITECTURE
AMD64

Mostly defaults:

$ git config --system -l
http.sslbackend=schannel
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager

insert your response here

Details

git-BASH only

$ tail -n ~/.gitconfig
<snip>
    35  [http]
    36          schannel.checkRevoke = false

$ git config  -l
fatal: bad config line 36 in file C:/Users/pbourgin/.gitconfig

No error and this new option usable

can't set this option

insert URL here

yopito commented 6 years ago

other hints:

$ cat -n ~/.gitconfig 35 36 [http "schannel"] 37 checkRevoke = false

But It does not help:

$ git pull vpc fatal: unable to access 'https://pbourgin@mycorp.com/toto.git/': \ schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) \

ping @shiftkey about this

dscho commented 6 years ago

Maybe try with GIT_TRACE_CURL=1?

yopito commented 6 years ago

Sorry for late reply. Using GIT_TRACE_CURL=1 does not help for this problem I think.
anyway here the traces:

$ GIT_TRACE_CURL=1 git push -u vpc --all 12:59:35.328594 http.c:656 == Info: STATE: INIT => CONNECT handle 0x891680; line 1392 (connection #-5000) 12:59:35.328594 http.c:656 == Info: Couldn't find host mycorp.com in the _netrc file; using defaults 12:59:35.328594 http.c:656 == Info: Added connection 0. The cache now contains 1 members 12:59:35.329594 http.c:656 == Info: STATE: CONNECT => WAITRESOLVE handle 0x891680; line 1428 (connection #0) 12:59:35.338594 http.c:656 == Info: Trying 10.24.7.135... 12:59:35.338594 http.c:656 == Info: TCP_NODELAY set 12:59:35.338594 http.c:656 == Info: STATE: WAITRESOLVE => WAITCONNECT handle 0x891680; line 1509 (connection #0) 12:59:35.346594 http.c:656 == Info: Connected to mycorp.com (10.24.7.135) port 443 (#0) 12:59:35.346594 http.c:656 == Info: STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x891680; line 1561 (connection #0) 12:59:35.346594 http.c:656 == Info: Marked for [keep alive]: HTTP default 12:59:35.346594 http.c:656 == Info: schannel: SSL/TLS connection with mycorp.com port 443 (step 1/3) 12:59:35.346594 http.c:656 == Info: schannel: checking server certificate revocation 12:59:35.350594 http.c:656 == Info: schannel: sending initial handshake data: sending 203 bytes... 12:59:35.350594 http.c:656 == Info: schannel: sent initial handshake data: sent 203 bytes 12:59:35.350594 http.c:656 == Info: schannel: SSL/TLS connection with mycorp.com port 443 (step 2/3) 12:59:35.350594 http.c:656 == Info: schannel: failed to receive handshake, need more data 12:59:35.350594 http.c:656 == Info: STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x891680; line 1575 (connection #0) 12:59:35.360594 http.c:656 == Info: schannel: SSL/TLS connection with mycorp.com port 443 (step 2/3) 12:59:35.360594 http.c:656 == Info: schannel: encrypted data got 1380 12:59:35.360594 http.c:656 == Info: schannel: encrypted data buffer: offset 1380 length 4096 12:59:35.360594 http.c:656 == Info: schannel: encrypted data length: 1286 12:59:35.360594 http.c:656 == Info: schannel: encrypted data buffer: offset 1286 length 4096 12:59:35.360594 http.c:656 == Info: schannel: received incomplete message, need more data 12:59:35.360594 http.c:656 == Info: schannel: SSL/TLS connection with mycorp.com port 443 (step 2/3) 12:59:35.360594 http.c:656 == Info: schannel: encrypted data got 2059 12:59:35.360594 http.c:656 == Info: schannel: encrypted data buffer: offset 3345 length 4096 12:59:35.436594 http.c:656 == Info: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de r¦vocation n¦a pas pu v¦rifier la r¦vocation du certificat. 12:59:35.436594 http.c:656 == Info: Marked for [closure]: Failed HTTPS connection 12:59:35.436594 http.c:656 == Info: multi_done 12:59:35.436594 http.c:656 == Info: stopped the pause stream! 12:59:35.436594 http.c:656 == Info: Closing connection 0 12:59:35.436594 http.c:656 == Info: The cache now contains 0 members 12:59:35.436594 http.c:656 == Info: schannel: shutting down SSL/TLS connection with mycorp.com port 443 12:59:35.437594 http.c:656 == Info: schannel: clear security context handle 12:59:35.437594 http.c:656 == Info: Expire cleared fatal: unable to access 'https://pbourgin@mycorp.com/SquashTM-mig/toto.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de r¦vocation n¦a pas pu v¦rifier la r¦vocation du certificat.

shiftkey commented 6 years ago

This is on my radar, just haven't had a chance to dig into it.

@yopito thanks for the GIT_TRACE_CURL=1 logs. These should help.

zspitz commented 6 years ago

@shiftkey Any news on this? I think I am seeing the same issue -- http.schannel.checkRevoke=true seems to be ignored.

PS C:\> cmd.exe /c ver

Microsoft Windows [Version 10.0.16299.371]
PS C:\> Get-ChildItem Env:PROCESSOR_ARCHITECTURE

Name                           Value
----                           -----
PROCESSOR_ARCHITECTURE         AMD64

I can't recall offhand, but here is the full configuration from outside a specific Git-tracked folder:

PS C:\> git config --list --show-origin
file:"C:\\ProgramData/Git/config"       core.symlinks=false
file:"C:\\ProgramData/Git/config"       core.autocrlf=true
file:"C:\\ProgramData/Git/config"       core.fscache=true
file:"C:\\ProgramData/Git/config"       color.diff=auto
file:"C:\\ProgramData/Git/config"       color.status=auto
file:"C:\\ProgramData/Git/config"       color.branch=auto
file:"C:\\ProgramData/Git/config"       color.interactive=true
file:"C:\\ProgramData/Git/config"       help.format=html
file:"C:\\ProgramData/Git/config"       sendemail.smtpserver=/bin/msmtp.exe
file:"C:\\ProgramData/Git/config"       diff.astextplain.textconv=astextplain
file:"C:\\ProgramData/Git/config"       rebase.autosquash=true
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    http.sslbackend=openssl
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    diff.astextplain.textconv=astextplain
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    filter.lfs.clean=git-lfs clean -- %f
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    filter.lfs.smudge=git-lfs smudge -- %f
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    filter.lfs.process=git-lfs filter-process
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    filter.lfs.required=true
file:"C:\\Program Files\\Git\\mingw64/etc/gitconfig"    credential.helper=manager
file:C:/Users/win8/.gitconfig   user.name=Zev Spitz
file:C:/Users/win8/.gitconfig   user.email=__________@__________
file:C:/Users/win8/.gitconfig   filter.lfs.required=true
file:C:/Users/win8/.gitconfig   filter.lfs.clean=git-lfs clean -- %f
file:C:/Users/win8/.gitconfig   filter.lfs.smudge=git-lfs smudge -- %f
file:C:/Users/win8/.gitconfig   http.sslbackend=schannel
file:C:/Users/win8/.gitconfig   http.schannel.checkrevoke=false

My ISP provides a content filter which works even over SSL. I've installed the ISP-provided security certificate to Windows, but not to Git (e.g. via http.sslCAInfo or http.sslCAPath). My understanding is that as I've set http.sslBackend to schannel, Git for Windows will make use of said certificate; is this correct?

CMD; Powershell from the VS Code integrated terminal


I have the following trace, after $env:GIT_CURL_VERBOSE=1:

PS D:\Zev\Projects\_typescript\DefinitelyTyped> git pull upstream master
* STATE: INIT => CONNECT handle 0x5709840; line 1392 (connection #-5000)
* Couldn't find host github.com in the _netrc file; using defaults
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x5709840; line 1428 (connection #0)
*   Trying 192.30.253.113...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x5709840; line 1509 (connection #0)
* Connected to github.com (192.30.253.113) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x5709840; line 1561 (connection #0)
* Marked for [keep alive]: HTTP default
* schannel: SSL/TLS connection with github.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 175 bytes...
* schannel: sent initial handshake data: sent 175 bytes
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x5709840; line 1575 (connection #0)
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: encrypted data got 1360
* schannel: encrypted data buffer: offset 1360 length 4096
* schannel: encrypted data length: 1290
* schannel: encrypted data buffer: offset 1290 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: encrypted data got 1360
* schannel: encrypted data buffer: offset 2650 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: encrypted data got 1376
* schannel: encrypted data buffer: offset 4026 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: encrypted data got 1024
* schannel: encrypted data buffer: offset 5050 length 5050
* schannel: encrypted data length: 495
* schannel: encrypted data buffer: offset 495 length 5050
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with github.com port 443 (step 2/3)
* schannel: encrypted data got 75
* schannel: encrypted data buffer: offset 570 length 5050
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Marked for [closure]: Failed HTTPS connection
* multi_done
* stopped the pause stream!
* Closing connection 0
* The cache now contains 0 members
* schannel: shutting down SSL/TLS connection with github.com port 443
* schannel: clear security context handle
* Expire cleared
fatal: unable to access 'https://github.com/DefinitelyTyped/DefinitelyTyped.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
riezebosch commented 6 years ago

See my comment: https://github.com/git-for-windows/git/commit/55c268f393281e9a6f6df9f8080d08a72e3b9213#r28965974

(credits to a colleague)

agusmba commented 6 years ago

Thank you all for tackling this issue, it's not easy to work with git and https in a windows box.

I updated to the latest git version (2.17.1.windows.2) but I'm still seeing this problem:

$ git config --list --show-origin | grep http
file:C:/Program Files/Git/mingw64/etc/gitconfig http.sslbackend=schannel
file:d:/home/user/.gitconfig        http.emptyauth=true
file:d:/home/user/.gitconfig        http.sslbackend=schannel
file:d:/home/user/.gitconfig        credential.my.server.com.usehttppath=true
file:d:/home/user/.gitconfig        http.schannel.checkrevoke=false
file:.git/config        remote.origin.url=https://user@my.server.com/bitbucket/scm/~user/repository.git
$ GIT_CURL_VERBOSE=1 GIT_TRACE_CURL=1 git fetch -vvv
11:32:11.906524 http.c:709              == Info: Couldn't find host my.server.com in the _netrc file; using defaults
11:32:11.922125 http.c:709              == Info:   Trying 10.xxx.xxx.x...
11:32:11.922125 http.c:709              == Info: TCP_NODELAY set
11:32:11.922125 http.c:709              == Info: Connected to my.server.com (10.xxx.xxx.x) port 443 (#0)
11:32:11.922125 http.c:709              == Info: schannel: SSL/TLS connection with gestioncodigo.sco.ree.es port 443 (step 1/3)
11:32:11.922125 http.c:709              == Info: schannel: checking server certificate revocation
11:32:11.937725 http.c:709              == Info: schannel: sending initial handshake data: sending 197 bytes...
11:32:11.937725 http.c:709              == Info: schannel: sent initial handshake data: sent 197 bytes
11:32:11.937725 http.c:709              == Info: schannel: SSL/TLS connection with my.server.com port 443 (step 2/3)
11:32:11.937725 http.c:709              == Info: schannel: failed to receive handshake, need more data
11:32:11.937725 http.c:709              == Info: schannel: SSL/TLS connection with my.server.com port 443 (step 2/3)
11:32:11.937725 http.c:709              == Info: schannel: encrypted data got 2008
11:32:11.937725 http.c:709              == Info: schannel: encrypted data buffer: offset 2008 length 4096
11:32:11.937725 http.c:709              == Info: schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - La función de revocación no puede comprobar la revocación debido a que el servidor de revocación está sin conexión.
11:32:11.937725 http.c:709              == Info: stopped the pause stream!
11:32:11.937725 http.c:709              == Info: Closing connection 0
11:32:11.937725 http.c:709              == Info: schannel: shutting down SSL/TLS connection with my.server.com port 443
11:32:11.937725 http.c:709              == Info: schannel: clear security context handle
fatal: unable to access 'https://user@my.server.com/bitbucket/scm/~user/repository.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - La función de revocación no puede comprobar la revocación debido a que el servidor de revocación está sin conexión.

Curl version should be ok:

$ curl --version
curl 7.60.0 (x86_64-w64-mingw32) libcurl/7.60.0 OpenSSL/1.0.2o (WinSSL) zlib/1.2.11 libidn2/2.0.5 nghttp2/1.31.1
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL Metalink

@zspitz is it working for you?

Thanks!

dscho commented 6 years ago

@agusmba it should be fixed in the 2.18.0-rc2 prerelease. v2.18.0 was supposed to come out last night, but slipped, it will probably be there soon.

agusmba commented 6 years ago

Hi @dscho, thanks for the answer!

Today I updated to 2.18.0 via git update-... but I still got the same error as before. Is there any way I could help by getting more detailed logs somehow?

Just in case I also uninstalled git completely and reinstalled it with the newest installer (2.18.0) to no avail.

melscoop commented 6 years ago

👋 Hi all

I've ran across this same issue and I'd like to know if there is any output or other details we can provide to help here?

Here is the current config: Git for Windows 2.18.0 GitHub Desktop to 1.2.6

dscho commented 6 years ago

Since I cannot rely on immediate testing of what I put out, I would need a quick reproducer on my side, i.e. a short list of instructions to reproduce the issue designed not to take too much time to set up.

agusmba commented 6 years ago

Ok, so I got to reproduce it on my machine, using openssl and docker. I'm assuming you have a windows box with docker-toolbox, and git-for-windows installed (this last one is to have openssl available)

  1. Generate some certificates as shown in the accepted answer here, note that the script will fail on git-bash unless you use double slash // instead of single one in all the -subj attributes.

  2. Run an apache server with docker:

    docker run -dit --name my-apache-app -p 8080:80 -p 8443:443 -v /"$PWD"/htdocs://usr/local/apache2/htdocs -v apache-conf://usr/local/apache2/conf httpd:2.4

  3. Stop the server

    docker stop my-apache-app

  4. Edit the configuration files in the apache-conf volume (see SSL section):

    • Edit /usr/local/apache2/conf/httpd.conf, remove the comment from the line with #Include conf/extra/httpd-ssl.conf ; uncomment also a couple of LoadModules
    • copy the contents of out/1.crt and out/1.key generated in step 1 into the server.crt and server.key located in /usr/local/apache2/conf/ in the docker volume
  5. Install the root ca and intermediate certificates generated in 1 into your windows trust store.

  6. start the apache again (as in step 2)

  7. add your docker-machine ip to your windows etc/hosts so that it points to 1.example.com (the certificate you generated in 1)

  8. navigate to https://1.example.com:8443/ this should give you an empty directory list

  9. test git clone from command line:

git clone https://1.example.com:8443/test-clone
Cloning into 'test-clone'...
fatal: unable to access 'https://1.example.com:8443/test-clone/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La función de revocación no puede comprobar la revocación para el certificado.

These are a bit quick and dirty steps I hacked in an hour, so they are not very elegant. The certificates do not have the alt name so using chrome to browse the server will complain about it. IE doesn't complain. I do not even need a git server since the error is at the ssl connection level.

Hope this helps.

I know it's a bit of a hassle to set this up, but once you have it, you can test it with docker start my-apache-app , git clone https://1.example.com:8443/test-clone, and docker stop my-apache-app when done.

If you get a 404 it should indicate that the ssl part is working for git.

agusmba commented 6 years ago

I tested the previous setup with openssl backend (instead of schannel) and after adding the ca.crt and intermediate.crt to my git CAbundle, I got the expected 404:

$ git clone https://1.example.com:8443/test-clone
Cloning into 'test-clone'...
fatal: repository 'https://1.example.com:8443/test-clone/' not found
dscho commented 6 years ago

I don't have all of those prerequisites installed (docker-toolbox, a container with Apache), so the thing that helps me most is that you have a working setup to reproduce the issue.

So here goes the next step to investigate: verify that the code path is actually hit. You could verify this e.g. by recompiling Git (you will need the SDK for that) with this patch applied:

diff --git a/http.c b/http.c
index 57a889a13cd..6a1faf2d7b9 100644
--- a/http.c
+++ b/http.c
@@ -832,6 +832,7 @@ static CURL *get_curl_handle(void)
    if (http_ssl_backend && !strcmp("schannel", http_ssl_backend) &&
        !http_schannel_check_revoke) {
 #if LIBCURL_VERSION_NUM >= 0x074400
+       fprintf(stderr, "NO REVOKE!\n");
        curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
 #else
        warning("CURLSSLOPT_NO_REVOKE not applied to curl SSL options because\n"
agusmba commented 6 years ago

I'll give it a try. I downloaded the SDK, but on the first make install (after sdk init) I get:

compat/mingw.c: In function 'mingw_startup':
compat/mingw.c:3463:24: error: passing argument 1 of 'SetConsoleCtrlHandler' from incompatible pointer type [-Werror=incompatible-pointer-types]
  SetConsoleCtrlHandler(handle_ctrl_c, TRUE);
                        ^~~~~~~~~~~~~
In file included from C:/git-sdk-32/mingw32/i686-w64-mingw32/include/windows.h:74:0,
                 from C:/git-sdk-32/mingw32/i686-w64-mingw32/include/winsock2.h:23,
                 from compat/../git-compat-util.h:162,
                 from compat/mingw.c:1:
C:/git-sdk-32/mingw32/i686-w64-mingw32/include/wincon.h:245:29: note: expected 'PHANDLER_ROUTINE' but argument is of type 'BOOL (*)(DWORD) {aka int (*)(long unsigned int)}'
   WINBASEAPI WINBOOL WINAPI SetConsoleCtrlHandler(PHANDLER_ROUTINE HandlerRoutine,WINBOOL Add);
                             ^~~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
make: *** [Makefile:2262: compat/mingw.o] Error 1

should I ignore these warnings?

if so, after I compile git, should I build the installer in order to properly test it?

dscho commented 6 years ago

Hmm.

$ make -j15 DEVELOPER=1 compat/mingw.o
GIT_VERSION = 2.17.0.windows.1.3188.g39e86d28d6
    * new build flags
    CC compat/mingw.o

No errors. My git rev-parse HEAD says 39e86d28d69e836a417e120c838c5b03fab272e0. (I did call sdk cd git instead of sdk init, though.)

Oh, I see that you use the 32-bit SDK. Let me try again (I did this in my 64-bit SDK, the vast majority of Git for Windows installations seems to be 64-bit, and this issue was reported for a 64-bit build, too).

Yes, on 32-bit I can reproduce the compiler warning (turned error via DEVELOPER=1). This diff seems to fix it:

diff --git a/compat/mingw.c b/compat/mingw.c
index d278904f63..102e94acbb 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -3344,7 +3344,7 @@ static void adjust_symlink_flags(void)

 }

-static BOOL handle_ctrl_c(DWORD ctrl_type)
+static WINAPI WINBOOL handle_ctrl_c(DWORD ctrl_type)
 {
    if (ctrl_type != CTRL_C_EVENT)
        return FALSE; /* we did not handle this */
dscho commented 6 years ago

after I compile git, should I build the installer in order to properly test it?

Sorry, forgot to answer this question. It would be ideal if you could do that (via sdk build git-and-installer). But it will affect your setup if you install that, of course.

agusmba commented 6 years ago

Ok, thanks for the quick fix! Yes, I was using the 32 bits because I'm playing with the git sdk in a virtualbox VM, and the windows 7 images only come in 32bit flavor. This way I can minimize the chances of affecting my regular setup.

I had to change the code in remote-curl.c in order to avoid another warning, and finally got it compiling.

The problem seems to be that http_schannel_check_revoke does not reflect the contents of http.schannel.checkrevoke configuration:

$ git config --list | grep http
http.sslcainfo=/ssl/certs/ca-bundle.crt
http.sslbackend=schannel
http.schannel.checkrevoke=false

$ git clone https://user@server/bitbucket/scm/project/repo.git
Cloning into 'repo'...
1531-LOG: http_ssl_backend: schannel
1531-LOG: http_schannel_check_revoke: 1
fatal: unable to access 'https://user@server/bitbucket/scm/project/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

Changing the revoke configuration to true yields the same result:

$ git config --list | grep http
http.sslcainfo=/ssl/certs/ca-bundle.crt
http.sslbackend=schannel
http.schannel.checkrevoke=true

$ git clone https://user@server/bitbucket/scm/project/repo.git
Cloning into 'repo'...
http_ssl_backend: schannel
http_schannel_check_revoke: 1
fatal: unable to access 'https://user@server/bitbucket/scm/project/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

Printing out the calls to http_options(...) it seems it is never called with the check revoke option:

$ git config --list | grep http
http.sslcainfo=/ssl/certs/ca-bundle.crt
http.sslbackend=schannel
http.schannel.checkrevoke=true

$ git clone https://user@server/bitbucket/scm/project/repo.git
Cloning into 'repo'...
1531-LOG: http_options var: http.sslcainfo ; value: /ssl/certs/ca-bundle.crt
1531-LOG: http_options var: http.sslbackend ; value: schannel
1531-LOG: get_curl_handle http_ssl_backend: schannel
1531-LOG: get_curl_handle http_schannel_check_revoke: 1
fatal: unable to access 'https://user@server/bitbucket/scm/project/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

It looks like the http.schannel.checkrevoke configuration entry is not being recognized as such

dscho commented 6 years ago

I had to change the code in remote-curl.c in order to avoid another warning, and finally got it compiling.

Yes, I saw that, too, some sort of "this comparison is always false" when comparing an int to the maximal value of curl_off_t. I was not able to find a work-around quickly, and I have to attend to more important things (Git for Windows' 32-bit git.exe is built without DEVELOPER=1 and in a 64-bit SDK by "cross-compiling"), so I dropped the ball there.

The problem seems to be that http_schannel_check_revoke does not reflect the contents of http.schannel.checkrevoke configuration

Hmm. Okay.

At least we're getting to the root of the problem now, which is great! Thank you for doing all this, it is very helpful.

Does your call hit the code path at https://github.com/git-for-windows/git/blob/34573d29cddc47a2e55fe5948fe397190c6adede/http.c#L321-L324?

And does it hit this? https://github.com/git-for-windows/git/blob/34573d29cddc47a2e55fe5948fe397190c6adede/http.c#L832-L840

agusmba commented 6 years ago

Thanks for your help @dscho ! Glad I could also help!

The first code path is never reached. At the beginning of the http_options(...) function I put the trace

fprintf(stderr, "1531-LOG: http_options var: %s ; value: %s\n", var, value); // AMB

As you can see in the execution log in the previous response, the checkrevoke option is never passed to that method.

The second code path is reached (I have log traces right before), but only the first if. Since http_schannel_check_revoke is never set to 0, the condition will always be false.

Edit (added): What is curious is that git config does find that configuration option, but other git operations don't. Edit 2: Nevermind, git config will find any bogus option you write in the correct format.

dscho commented 6 years ago

Printing out the calls to http_options(...) it seems it is never called with the check revoke option

Oh my. We really did not think this option through, did we? There is this obscure feature where you can limit any http.* option to certain remotes by setting http.<url>.*. And guess how the schannel in http.schannel.checkRevoke looks to Git? Exactly. Like a URL.

Let me mull about this.

dscho commented 6 years ago

Okay, I mulled about this, and there are a couple of dirty tricks we could use to make http.schannel.checkRevoke work. But they are all ugly, and given that this feature never worked as advertised, we should fix it properly.

So here is my proposal: rename the config setting to http.schannelCheckRevoke.

This has the further advantage of also working with that http.<url>.* trick: if you need to disable this for just one URL, you now can. The diff looks like this:

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f8565941b0..e08e1b8695 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2124,12 +2124,12 @@ http.sslBackend::
    This option is ignored if cURL lacks support for choosing the SSL
    backend at runtime.

-http.schannel.checkRevoke::
+http.schannelCheckRevoke::
    Used to enforce or disable certificate revocation checks in cURL
    when http.sslBackend is set to "schannel". Defaults to `true` if
    unset. Only necessary to disable this if Git consistently errors
    and the message is about checking the revocation status of a
-   certificate. This option is ignored if cURL lacks support for 
+   certificate. This option is ignored if cURL lacks support for
    setting the relevant SSL option at runtime.

 http.schannel.useSSLCAInfo::
diff --git a/http.c b/http.c
index 57a889a13c..93c65ae5d8 100644
--- a/http.c
+++ b/http.c
@@ -318,7 +318,7 @@ static int http_options(const char *var, const char *value, void *cb)
        return 0;
    }

-   if (!strcmp("http.schannel.checkrevoke", var)) {
+   if (!strcmp("http.schannelcheckrevoke", var)) {
        http_schannel_check_revoke = git_config_bool(var, value);
        return 0;
    }

@agusmba could I bother you to test this?

@shiftkey this will most likely require changes in GitHub Desktop, but as that feature is unlikely to ever have worked... 😄

agusmba commented 6 years ago

I think that's the right call. I'll check it and report back

dscho commented 6 years ago

I'll check it and report back

Thank you so much! Please note that I opened a PullRequest to address this: #1747

agusmba commented 6 years ago

Ok, now we're getting somewhere.

The option is being recognized, however I seem to have a problem with the CURL version:

1531-LOG: http_options var: http.schannelcheckrevoke ; value: false
1531-LOG: get_curl_handle http_ssl_backend: schannel
1531-LOG: get_curl_handle http_schannel_check_revoke: 0  <---- GOOD!
warning: CURLSSLOPT_NO_REVOKE not applied to curl SSL options because
 your curl version is too old (>= 7.44.0) <----- ????

However:

$ curl -V
curl 7.60.0 (i686-w64-mingw32) libcurl/7.60.0 OpenSSL/1.0.2o (WinSSL) zlib/1.2.11 libidn2/2.0.5 nghttp2/1.32.0
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL Metalink

Do I need to manually configure anything to convince the compiler about having a newer curl version?

(Should I move this discussion to the PR you prepared?)

agusmba commented 6 years ago

Where is LIBCURL_VERSION_NUM set?

shiftkey commented 6 years ago

@dscho nice work on identifying that http.[url].* interferes with this!

this will most likely require changes in GitHub Desktop, but as that feature is unlikely to ever have worked... 😄

I've had plans to help users set this config value when they encounter the error, but I haven't baked this in yet so a change of the config value name is fine.

agusmba commented 6 years ago

Sorry for the curl misdirection, actually the SDK istalls an old version:

$ curl-config --vernum
073c00

Which is lower than 0x074400

Any tips on how to upgrade my SDK's curl? (sorry I'm a complete pacman newbie)

NEVERMIND (see below)

agusmba commented 6 years ago

https://github.com/git-for-windows/git/blob/34573d29cddc47a2e55fe5948fe397190c6adede/http.c#L834-L834

This looks a bit fishy @dscho

The latest curl version 7.60.0 in hex is 073c00, so assuming that the check wanted to compare with version 7.44.00, shouldn't we use hex 072c00? unless 074400 is an intended future version...

Edited to fix hex typo :-(

agusmba commented 6 years ago

Just in case I changed that check to

-#if LIBCURL_VERSION_NUM >= 0x074400
+#if LIBCURL_VERSION_NUM >= 0x072c00

and I finally I got git to ignore the crl check!!!

shiftkey commented 6 years ago

The latest curl version 7.60.0 in hex is 073c00, so assuming that the check wanted to compare with version 7.44.00, shouldn't we use hex 072c00? unless 074400 is an intended future version...

Looks like that one is on me - I think I glossed over that we didn't port 44 to hex in the original #1450. Nice find!

agusmba commented 6 years ago

Thanks! I thought I was going crazy for a minute, not understanding why it wasn't working

dscho commented 6 years ago

Thanks, both!

kanine9 commented 6 years ago

Excellent job TEAM!!!