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 中，它应该覆盖任何默认或显式系统或全局设置，它是假的.

• I have set the configuration option http.sslverify=false in all locations reported by git config -l --show-origin and 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 代理，但必须直接访问 repo 服务器.我为此设置了 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 获取16:41:53.953829 exec-cmd.c:236 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/bin16:41:53.955829 git.c:418 跟踪:内置:git fetch16: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 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/libexec/git-core16:41:54.003834 git.c:675 trace: exec: git-remote-https origin https://[FQDN/git 路径]16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/git 路径]16:41:54.028836 exec-cmd.c:236 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/libexec/git-core* 在 _netrc 文件中找不到主机 [repo host FQDN]；使用默认值* 正在尝试 [repo 主机 IP 地址]...* TCP_NODELAY 设置* 连接到[repo host FQDN] ([repo host IP address]) 端口443 (#0)* ALPN，提供 h2* ALPN，提供http/1.1* 成功设置证书验证位置:* CA文件:D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crtCApath:无* SSL证书问题:自签名证书* 关闭连接 0致命:无法访问 'https://[FQDN/path-to-git]':SSL证书问题:自签名证书

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 fetch17:04:56.884616 exec-cmd.c:236 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/bin17:04:56.886616 git.c:418 跟踪:内置:git fetch17: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 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/libexec/git-core17:04:56.932616 git.c:675 trace: exec: git-remote-https origin https://[FQDN/git 路径]17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/git 路径]17:04:56.957616 exec-cmd.c:236 跟踪:解析的可执行目录:D:/Programs/Git/mingw64/libexec/git-core* 使用代理环境变量 no_proxy == '[repo host FQDN]'* 在 _netrc 文件中找不到主机 [repo host FQDN]；使用默认值* 正在尝试 [repo 主机 IP 地址]...* TCP_NODELAY 设置* 连接到[repo host FQDN] ([repo host IP address]) 端口443 (#0)* ALPN，提供 h2* ALPN，提供http/1.1* 成功设置证书验证位置:* CA文件:D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crtCApath:无* 使用 TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 的 SSL 连接* ALPN，服务器接受使用 http/1.1* 服务器证书:[...证书详细信息包括.过期日期；成功沟通]

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]

推荐答案

首先尝试并在设置 简化路径，使用便携式 Git forWindows (PortableGit-2.20.1-64-bit.7z.exe)，在 C:Git 中未压缩:

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:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;C:WINDOWSSystem32WindowsPowerShellv1.0
set GH=C:path	ogit
set PATH=%GH%in;%GH%usrin;%GH%mingw64in;%PATH%

然后尝试在该会话中访问您的存储库.<小时>由 OP 编辑​​，Peter: 在整洁的环境中进行的测试有效.不同之处在于环境变量 https_proxy 和 HTTPS_PROXY 必须取消设置两者.¹ 即使服务器列在 no_proxy 环境变量中，该变量通常指示程序不要为变量值中列出的特定服务器使用代理.幸运的是，repo 服务器在本地网络中.²

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.¹ 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.²

我不清楚是 git 正确、cURL 还是 openssl 是这里的罪魁祸首；我相信这些变量是由 git 和网络库评估的.

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.

---

¹我认为变量以大写和小写形式存在是历史原因.

---

¹I think it's for historical reasons that the variable exists in an upper-case and lower-case form.

² 据我所知，问题不在于代理服务器，因为已获得回购服务器证书并正确识别为自我认证.

² 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屋！