在 Windows 上代理后面的货物 ssl 下载错误

Del*_*ore 5 ssl rust rust-cargo

我无法让货物在经过身份验证的代理后面的 Windows 下开始任何下载。

这是我的代理设置:-

C:\Users\ukb99427\Downloads
? set | grep http
https_proxy=http://user:pass@corporate.proxy:8080
http_proxy=http://user:pass@corporate.proxy:8080
Run Code Online (Sandbox Code Playgroud)

注意 http s _proxy 有一个http地址。这允许像 git 这样的东西,顺便说一下 rustup-init 和 rustup 可以正常工作。这些输出是

? rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2017-11-10, rust version 1.23.0-nightly (d6b06c63a 2017-11-09)
info: downloading component 'rustc'
 33.4 MiB /  33.4 MiB (100 %)   2.7 MiB/s ETA:   0 s
Run Code Online (Sandbox Code Playgroud)

但是当运行等效cargo install命令时,我得到以下信息

? cargo install libc
    Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): [12/-2] [56] Failure when receiving data from the peer
warning: spurious network error (1 tries remaining): [12/-2] [56] Failure when receiving data from the peer
Run Code Online (Sandbox Code Playgroud)

作为测试,我可以运行curl

? curl --insecure https://github.com/rust-lang/crates.io-index -o registry.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  785k    0  785k    0     0   389k      0 --:--:--  0:00:02 --:--:--  393k
Run Code Online (Sandbox Code Playgroud)

或者,我尝试将 https_proxy 设置为https ://user:pass@corporate.proxy:8080

并得到以下

? cargo install libc
    Updating registry `https://github.com/rust-lang/crates.io-index`
warning: spurious network error (2 tries remaining): [12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass@corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
warning: spurious network error (1 tries remaining): [12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass@corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  [12/-2] [4] A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. (Unsupported proxy 'https://user:pass@corporate.proxy:8080', libcurl is built without the HTTPS-proxy support.)
Run Code Online (Sandbox Code Playgroud)

供参考 curl --version 输出

? curl --version
curl 7.53.0 (x86_64-w64-mingw32) libcurl/7.53.0 OpenSSL/1.0.2k zlib/1.2.11 libssh2/1.8.0 nghttp2/1.19.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: IPv6 Largefile SSPI Kerberos SPNEGO NTLM **SSL** libz TLS-SRP HTTP2 HTTPS-proxy Metalink
Run Code Online (Sandbox Code Playgroud)

货版

? cargo version
cargo 0.24.0-nightly (b83550edc 2017-11-04)
Run Code Online (Sandbox Code Playgroud)

有没有办法让货物使用与 rustup、git 或 curl 相同的设置?其他应用程序可以正常工作,使用 sslverify=false(例如 git),这充其量是一种解决方法,但会让我在某个地方而不是无处可去。

这一切都在 Windows10 上,在经过身份验证的代理之后。如果没有给出用户/通行证,它(和任何应用程序)会以 http 错误 407 退出,这是有道理的。对于 Windows 应用程序,它们使用运行良好的 IE 设置(对于 Visual Studio Code 或类似应用程序)

我能想到的唯一替代方法是强制所有内容仅使用 http,但我不知道有任何设置可以使货物发生这种情况。

关于我还能尝试什么的任何想法?

Del*_*ore 6

I struggled with this a while but finally figured out a work around. I post this here as a possible solution for those behind corporate firewalls. It does, sadly, reduce adoption of rust if people can't install it easily at work.

Download the crates-io from github

git clone --bare https://github.com/rust-lang/crates.io-index.git
Run Code Online (Sandbox Code Playgroud)

In $HOME/.cargo/config file set the registry like

[registry]
index = "file:///C:/Users/someuser/crates.io-index.git"
Run Code Online (Sandbox Code Playgroud)

This stops the registry download via libgit-curl which apparently doesn't support https_proxy.

A longer term solution I think (but I've not tested this yet), is to rebuild cargo with libgit-curl supporting https.