git 2.20.1.windows.1不支持http.sslverify = false [英] git 2.20.1.windows.1 does not honor http.sslverify=false
问题描述
在适用于Windows的git的最新更新(实际上，我进行了新安装)之后，我无法再通过https连接到特定的远程存储库.它位于内部服务器上，该服务器使用自签名证书，该证书也已经过期了一段时间(不要问).
After the latest update (in fact, I did a new install) of git for Windows I cannot connect to a specific remote repository any longer via https. It's on an in-house server which uses a self-signed certificate which has also been expired for a while (don't ask).
它曾经与Windows 2.16.x(iirc)一起使用git，并继续与cygwin和mysys2(分别报告版本2.17.0和2.20.1)中的并行安装一起工作.
It used to work with git for Windows 2.16.x (iirc) and continues to work with parallel installations in cygwin and mysys2 (which report version 2.17.0 and 2.20.1, respectively).
这是我尝试过的内容(并非同时使用):
Here is what I tried (not all at the same time):
-
我已经在
git config -l --show-origin报告的所有位置设置了配置选项http.sslverify=false，并验证了sslverify是否正确.尤其是在本地存储库的.git/config中，它应该覆盖任何默认或显式的系统或全局设置，因此它是false.
I have set the configuration option
http.sslverify=falsein all locations reported bygit config -l --show-originand verified that sslverify is nowhere true. In particular in the local repo's .git/config which should override any default or explicit system or global settings it is false.
我将http.sslbackend选项更改为sChannel，然后又返回到openssl；错误消息更改，表明该设置有效，但仍然是错误消息.那里有帖子表明无法完全阻止较新的sChannel机制检查证书，因此我想确保自己不会意外使用它. (显然，这是新安装中的默认机制.)
I changed the http.sslbackend option to sChannel and then back to openssl; the error message changes, indicating that the setting was effective, but it is still an error message. There are posts out there indicating that the newer sChannel mechanism cannot completely be prevented from checking certificates, so I wanted to make sure I'm not accidentally still using it. (It's the default mechanism in a new installation, apparently.)
我还下载了证书，并通过编辑~/.ssl/config指示openssl使用它；不幸的是，这只会导致git(或更确切地说，openssl)以证书过期为由拒绝证书.
I have also downloaded the certificate and directed openssl to use it by editing ~/.ssl/config; unfortunately this just leads git (or rather, openssl) to reject the certificate on the grounds that it is expired.
我将环境变量GIT_SSL_NO_VERIFY设置为"true"，它将覆盖所有配置设置.
I set the environment variable GIT_SSL_NO_VERIFY to "true" which should override all config settings.
我使用环境变量GIT_TRACE_CURL=path，GIT_TRACE和GIT_CURL_VERBOSE来获取调试输出，除了openssl尝试验证证书并失败的事实外，它没有任何令人惊讶的地方，这是正确的只要它尝试验证它.例如.跟踪文件将包含Info: SSL certificate problem: self signed certificate行，该行是完全正确的.
I used the environment variables GIT_TRACE_CURL=path, GIT_TRACE and GIT_CURL_VERBOSE to obtain debug output which didn't show anythng surprising beyond the fact that openssl tried to verify the certificate and failed, which is correct as long as it tries to verify it at all. E.g. the trace file would contain the line Info: SSL certificate problem: self signed certificate which is entireyl correct.
其他git(resp.openssl)安装似乎跳过了整个证书检查，尽管在这种情况下我们需要这样做.
The other git (resp. openssl) installations appear to skip the entire certificate check though which is what we need under the circumstances.
这是一个错误吗?有什么想法吗?
Is this a bug? Any ideas?
问题与https代理设置有关.在我的环境中，我位于HTTPS代理后面，但必须直接访问回购服务器.我为此设置了https_proxy和no_proxy变量.为了排除所有其他环境设置，我使用了具有两个不同设置的
env -i(启动没有设置环境变量的程序).请注意，我保留了最初具有git安装目录的原始路径.唯一的不同是，在失败的calll(首先出现)中，https_proxy设置为以"https://"开头的字符串(garbage部分的字面意思是明确的，它不是有效的主机):
The issue has to do with https proxy settings. In my environment I am behind a HTTPS proxy but the repo server must be accessed directly. I have https_proxy and no_proxy variables set for that. In order to exclude all other environment settings I used
env -i (which starts a program without eny environment variable set) with two different settings. Note that I kept my original path which has the git installation directories first. The only difference is that in the failing calll, which comes first, https_proxy is set to a string starting with "https://" (the garbage part is literal to make clear it's not a valid host):
ssl设置是
git config -l |grep -i ssl
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslbackend=openssl
env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="https://garbage" git fetch
16:41:53.953829 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin
16:41:53.955829 git.c:418 trace: built-in: git fetch
16:41:53.980831 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git]
16:41:54.001834 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
16:41:54.003834 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git]
16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git]
16:41:54.028836 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
* Couldn't find host [repo host FQDN] in the _netrc file; using defaults
* Trying [repo host IP address]...
* TCP_NODELAY set
* Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* SSL certificate problem: self signed certificate
* Closing connection 0
fatal: unable to access 'https://[FQDN/path-to-git]': SSL certificate problem: self signed certificate
env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="https://garbage" git fetch
16:41:53.953829 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin
16:41:53.955829 git.c:418 trace: built-in: git fetch
16:41:53.980831 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git]
16:41:54.001834 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
16:41:54.003834 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git]
16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git]
16:41:54.028836 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
* Couldn't find host [repo host FQDN] in the _netrc file; using defaults
* Trying [repo host IP address]...
* TCP_NODELAY set
* Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* SSL certificate problem: self signed certificate
* Closing connection 0
fatal: unable to access 'https://[FQDN/path-to-git]': SSL certificate problem: self signed certificate
如果https_proxy变量不是以https://开头，则该命令有效.直到CApath: none行为止，日志几乎完全相同，除了在curl确认no_proxy设置的那一行上.
The command works if the https_proxy variable does not start with https://. The logs are almost identical up to the line CApath: none, except that there is a line where curl acknowledges the no_proxy setting.
env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="" git fetch
17:04:56.884616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin
17:04:56.886616 git.c:418 trace: built-in: git fetch
17:04:56.911616 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git]
17:04:56.931616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
17:04:56.932616 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git]
17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git]
17:04:56.957616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
* Uses proxy env variable no_proxy == '[repo host FQDN]'
* Couldn't find host [repo host FQDN] in the _netrc file; using defaults
* Trying [repo host IP address]...
* TCP_NODELAY set
* Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[... certificate details incl. past expiration date; successful communication]
env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="" git fetch
17:04:56.884616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin
17:04:56.886616 git.c:418 trace: built-in: git fetch
17:04:56.911616 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git]
17:04:56.931616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
17:04:56.932616 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git]
17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git]
17:04:56.957616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core
* Uses proxy env variable no_proxy == '[repo host FQDN]'
* Couldn't find host [repo host FQDN] in the _netrc file; using defaults
* Trying [repo host IP address]...
* TCP_NODELAY set
* Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
[... certificate details incl. past expiration date; successful communication]
推荐答案
请先尝试并在CMD会话中访问您的存储库，在该会话中您设置了简化的路径，使用便携式 Git Windows (
Try first and access your repo in a CMD session where you set a simplified PATH, using a portable Git for Windows (PortableGit-2.20.1-64-bit.7z.exe), uncompressed in C:\Git:
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%
然后尝试在该会话中访问您的存储库.
由OP进行编辑，彼得:在整洁的环境下进行的测试有效.区别在于环境变量
https_proxy和HTTPS_PROXY都必须未设置两者. 1 即使服务器在no_proxy环境中列出，也是如此.变量，通常指示程序不要对变量值中列出的特定服务器使用代理.幸运的是，回购服务器位于本地网络中. 2
Then try to access your repo in that session.
Edit by the OP, Peter: The test with an uncluttered environment worked. The difference is with the environment variables
https_proxy and HTTPS_PROXY which both must be unset.1 This is true even though the server is listed in the no_proxy environment variable which normally instructs programs to not use a proxy for specific servers listed in the variable value. Luckily the repo server is in the local network.2
我不清楚git是否合适，cURL还是openssl是这里的罪魁祸首；我相信这些变量是由gitproperty和网络库评估的.
It's unclear to me whether git proper, cURL or openssl is the culprit here; the variables are, I believe, evaluated by git proper as well as the networking libraries.
1 我认为出于历史原因，该变量以大写和小写形式存在.
1I think it's for historical reasons that the variable exists in an upper-case and lower-case form.
2 据我所知，问题不在于代理服务器，因为已获得回购服务器证书并将其正确识别为自我认证.
2 As far as I can tell the issue is not with the proxy server because the repo server certificate is obtained and correctly recognized as self-certified.
这篇关于git 2.20.1.windows.1不支持http.sslverify = false的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
