Not planned
Description
Setup
- Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.41.0.windows.1
cpu: x86_64
built from commit: ff94e79c4724635915dbb3d4ba38f6bb91528260
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.19044.2965]
- What options did you set as part of the installation? Or did you choose the
defaults?
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Probably none. Git was installed through Scoop
- Any other interesting things about your environment that might be related
to the issue you're seeing?
Behind enterprise proxy that intercepts HTTPS connections and self-signed certificates are used.
Details
- Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Powershell/Git Bash
- What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.
$env:GIT_CURL_VERBOSE=1
git clone https://github.com/[whatever-repository].git
- What did you expect to occur after running these commands?
Cloned repository on my disk
- What actually happened instead?
Cloning into 'repository-name'...
16:56:02.905057 http.c:842 == Info: Couldn't find host github.com in the (nil) file; using defaults
16:56:02.910502 http.c:842 == Info: Trying 192.168.229.22:8080...
16:56:02.922227 http.c:842 == Info: Connected to www-proxy.visana.ch (192.168.229.22) port 8080 (#0)
16:56:02.922227 http.c:842 == Info: CONNECT tunnel: HTTP/1.1 negotiated
16:56:02.922227 http.c:842 == Info: allocate connect buffer
16:56:02.922227 http.c:842 == Info: Establish HTTP proxy tunnel to github.com:443
16:56:02.922227 http.c:789 => Send header, 0000000121 bytes (0x00000079)
16:56:02.922227 http.c:801 => Send header: CONNECT github.com:443 HTTP/1.1
16:56:02.922227 http.c:801 => Send header: Host: github.com:443
16:56:02.922227 http.c:801 => Send header: User-Agent: git/2.41.0.windows.1
16:56:02.922227 http.c:801 => Send header: Proxy-Connection: Keep-Alive
16:56:02.922227 http.c:801 => Send header:
16:56:02.973986 http.c:789 <= Recv header, 0000000037 bytes (0x00000025)
16:56:02.973986 http.c:801 <= Recv header: HTTP/1.1 200 Connection established
16:56:02.973986 http.c:789 <= Recv header, 0000000002 bytes (0x00000002)
16:56:02.973986 http.c:801 <= Recv header:
16:56:02.973986 http.c:842 == Info: CONNECT phase completed
16:56:02.973986 http.c:842 == Info: CONNECT tunnel established, response 200
16:56:02.973986 http.c:842 == Info: schannel: disabled automatic use of client certificate
16:56:03.026716 http.c:842 == Info: schannel: added 134 certificate(s) from CA file 'C:\Users\UID20852\ca-trust\extracted\pem\tls-ca-bundle.pem'
16:56:03.037464 http.c:842 == Info: schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
16:56:03.038426 http.c:842 == Info: Closing connection 0
16:56:03.039405 http.c:842 == Info: schannel: shutting down SSL/TLS connection with github.com port 443
fatal: unable to access 'https://github.com/sburkard/cookie-factory.git/': schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
- If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
You can take any.
- Other infos
When I downgrade to Git 2.40.1.windows.1, everything works fine.
Activity
dscho commentedon Jun 15, 2023
Does it work when setting the config option
http.schannelCheckRevoke
tobest-effort
?sburkard commentedon Jun 16, 2023
No, unfortunately not. I tried
as well as
But the result was the same
sburkard commentedon Jun 16, 2023
Hey @dscho, your suggestion for this git option leaded me to the more relevant discussions for my case.
Git works again if I do
Has the latest Git version switched from
openssl
toschannel
? Are there any consequences when I continue to useopenssl
(like openssl is planned for deprecation as this is only a limited solution)?Thanks
dscho commentedon Jun 16, 2023
Indeed it has! I guess this release note entry did not talk about this explicitly, sorry...
Now, Secure Channel is the native Windows component to do TLS/SSL, so it is much preferred to using OpenSSL. For example, if you want to access hosts with self-signed SSL certificates, using OpenSSL you have to jump through hoops. With Secure Channel, because it is integrated well into the Windows ecosystem, you simply need to direct your web browser to that host, accept the certificate, and then
git clone
will implicitly trust that certificate, too.That is the reason why I would love to figure out what is going wrong here, so that you, too, can use Secure Channel.
I see that there is a CA file in effect. Is
http.sslCAInfo
configured on your system? I do recall that there have been problems in the past with Secure Channel and that setting, as that setting overrides the default Certificate Store for some reason.sburkard commentedon Jun 16, 2023
Great, thanks for your effort @dscho
Yes indeed, we build a custom PEM file that contains the public certificates of Git as well as our company self-signed certificates. This PEM is used as trust store for Git and other tools.
So I tried the following
Unfortunately I still get the same result.
dscho commentedon Jun 22, 2023
Hmm. So it seems that the proxy connection worked, but then the revocation check fails? Is there maybe a chance that you can try the same command but bypassing the proxy? (And yes, I am clutching at straws.)
sburkard commentedon Jun 30, 2023
Hi @dscho sorry for the delay, but I had to create a ticket to disable the SSL interception for my test URL
So, new test setting. Still with proxy but without SSL interception. And this is already quite different. The repository is successfully cloned, but the verbse output of curl contains a lot of
failed to decrypt data, need more data
messages (see below).No idea if this is normal or a problem indicator.
Settings
The result of the clone
Let me know if I should do some other tests in this setting or another test with proxy bypass. For the moment I stick with this setting because every change has to be done by ticket request.
Thanks
HaTiIn commentedon Jul 6, 2023
FYI: In our company, this change has caused CI pipelines using Gitlab Runner 16.1.0 to fail with the following error: "fatal: unable to access 'https://xxxx.git/': schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN."
The helper image used by Gitlab Runner 16.1.0 uses git version 2.41.0. Unfortunately, I don't know how to revert the default in the helper image. Therefore, we need to downgrade to version 16.0.2.
dscho commentedon Jul 7, 2023
@sburkard I guess this is a clear indication that the proxy's causing the problem. Now, my hunch is that libcurl might need some changes to allow for the
CURLSSLOPT_REVOKE_BEST_EFFORT
flag to be used for proxy connections, too.However, when I look at curl/curl@5450428 I do not see any red flags:
schannel_connect_step1()
seems to run in the exact same way for proxies as it does for the actual connection... Having said that, the current version of this function looks different, quite different.Oh, but I just saw this: the
CURSSLOPT_REVOKE_BEST_EFFORT
flag is mentioned also in theCURLOPT_PROXY_SSL_OPTIONS
manual page, but Git only sets theCURLOPT_SSL_OPTIONS
.@sburkard do you think you could test whether setting the proxy options helps? I.e.
install Git for Windows' SDK,
sdk cd git
,edit
http.c
, something like this:build Git via
make -j$(nproc)
test in-place via
./bin-wrappers/git -C <directory> <command>
?open a PR?
These are all prefixed with "Info:", therefore I assume that they are not even warnings, just informative messages indicating that data arrived in such small chunks that decryption had to wait until more data arrived.
http: set the proxy SSL options, if compiling with a new-enough libcurl
dscho commentedon Jul 7, 2023
FWIW I also opened a PR for that, you could therefore get going with a local test via these steps:
sburkard commentedon Jul 11, 2023
Hi @dscho
OK, I've built the Git binary locally, checked out your branch and gave it a try. Unfortunately still the same problem.
Official Git-Release + OpenSSL backend: works
Official Git-Release + schannel: NOT working
Local Git-Build from Branch + schannel: NOT working
I can now "switch" between interception and no-interception since my GitHub-Repo is no more intercepted and any public non-GitHub-Repo is intercepted.
Let me know if I can do other tests to find the problem.
Thanks
dscho commentedon Jul 12, 2023
Thank you for testing this.
I fear the next steps might be a bit more involved: The most promising direction would be to build libcurl and instrument it with debug print statements. My suggestion to get there:
This will build the current
mingw-w64-x86_64-curl
package, and most crucially, give you a worktree with the source code at/usr/src/MINGW-packages/mingw-w64-curl/src/curl-8.1.2
. If I were you, I would try to insertfprintf(stderr, "%s:%d: HERE!\n", __FILE__, __LINE__);
statements in the most interesting parts oflib/vtls/schannel*.c
(starting with the location where the error message is produced, and then adding more print statements as well as logging values of interest e.g. whether theBEST_EFFORT
flag was handed to the code as expected, and if not, where the ball was dropped), then build and "install" withmake -C /usr/src/MINGW-packages/mingw-w64-curl/src/build-MINGW64-shared && cp /usr/src/MINGW-packages/mingw-w64-curl/src/build-MINGW64-shared/lib/.libs/libcurl-4.dll /mingw64/bin/
.sburkard commentedon Jul 12, 2023
Hi @dscho
When I do
sdk build
I get SSL errors because of the selfsigned cert of our proxyCan I disable this check somehow?
16 remaining items