Should cargo use git proxies for other http requests?

[calidion]

Problem

when a global git https/http proxy config is set.

cargo install will fail with the following errors:

    Updating crates.io index
warning: spurious network error (3 tries remaining): [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to index.crates.io:443 )
warning: spurious network error (2 tries remaining): [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to index.crates.io:443 )
warning: spurious network error (1 tries remaining): [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to index.crates.io:443 )
error: download of config.json failed

Caused by:
  failed to download from `https://index.crates.io/config.json`

Caused by:
  [35] SSL connect error (OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to index.crates.io:443 )

after removing git config, cargo install will be normal again.

Steps

1. create a git config file in ~/.gitconfig
2. add the following config

[https]
	proxy = socks5://127.0.0.1:1080
[http]
	proxy = socks5://127.0.0.1:1080

3. execute cargo install

Possible Solution(s)

remove git proxy config for http/https.

Notes

No response

Version

cargo 1.85.0-nightly (769f622e1 2024-12-14)

[weihanglo]

Thank you for the issue report.

The config doc of http.proxy doesn't mention it respects git proxy settings. As far as I can tell, this is an undocumented behavior, which was implemented in 618137b in #541, way earlier than Rust 1.0 release.

I am not seeing any reason of this design in #541. Maybe it was because crates.io registry index was mainly downloaded via Git from rust-lang/crates.io-index, or it was just a handy default to help people use Git dependencies out-of-the-box.

Cargo has sparse registry support since 1.68. If people are not using any git dependencies, it is surprising that git proxy settings affect HTTP requests for normal cargo operations.

Having some possible approaches here:

• Completely remove the support of respecting HTTP proxy settings from git config. While this is an undocumented behavior, it might break someone's existing settings.
• Only respect git config if an http handle is going to talk to git (like git dependencies or crates.io-index from git repo).
• Keep the behavior as is and document it. It might still cause confusion like Should cargo config get print warning if proxy config found in git/libcurl ? #12572.

[weihanglo]

To me, since we want to rely less on a specific external, I am a bit inclined to remove the support, though the middle ground solution is not bad at all, and is consistent when net.git-fetch-with-cli enabled.

[calidion]

should keep it only for git, not for crates.io.

[calidion]

it seems not all cargo install will cause this problem.

[weihanglo]

See also #8327.

[ehuss]

As far as I can tell, this is an undocumented behavior

I believe this is documented in http.proxy

This behavior was added in 1.51 via #8986. It was intended to work that way from the early days via #725, but it was broken at the time. The current behavior was also requested in #8327.

The cargo team discussed this, and I wanted to summarize some different ideas.

Background: Cargo currently chooses the proxy for both git and HTTP network traffic in priority order:

• Cargo's http.proxy config setting (or CARGO_HTTP_PROXY).
• The git global, XDG and system configuration files http.proxy setting.
• Libcurl's environment variables "http_proxy", "HTTP_PROXY", "https_proxy", "HTTPS_PROXY"

To some degree, this is done as a convenience so that you can have a single place to configure a proxy. However, as evidence from this issue it does seem like some proxies configured for git will be configured to only access certain sites, and may not be appropriate for all http traffic.

Since we can't really change this in a backwards compatible way, we felt like the best approach would be to have some kind of config setting to be able to disable things in some way. This would likely be a change to the http.proxy cargo config setting, though I'm not sure exactly the shape. I'll describe some options http.proxy could be set to (skipping exact syntax):

• explicitly use today's default behavior (git proxy if set, else libcurl's env var)
  • Probably not a strong use-case for this option. I only list it in case we decide to have a warning, but the user wants to silence the warning and continue using git.
• use git configuration only for git traffic, use a different proxy for other traffic
  • The use case here is if you need different proxies for different kinds of traffic.
• use git configuration only for git traffic, use libcurl env var's for other traffic if set (otherwise no proxy).
  • The use case here is if you need different proxies for different kinds of traffic.
• don't use git configuration, only use env vars if set
  • The use case here is where the git proxy is only configured for certain things, but you have git dependencies to other sites that the git proxy doesn't have access to.
• don't use a proxy for anything, even if set in gitconfig or env vars
  • Probably not a strong use-case for this option if there is a way to disable the git config.

We also discussed the possibility of showing a warning if cargo implicitly falls back to the git config, and tell the user to switch cargo's http.proxy to something more explicit. Another thought was to only show that warning if there is a network error.

I don't know what, if any of those options we should add. There's also some consideration about how difficult the implementation would be, since the proxy choice is done at a very low-level and may be difficult to switch based on usage.