Cargo behind a proxy

[JP-Ellis]

I am using trying to use Cargo from behind a proxy, and it is unable to fetch external repositories despite having all the appropriate environment variables and configurations.

More specifically, I have the following environment variables set:

export HTTP_PROXY=proxy.example.com:8000
export HTTPS_PROXY=proxy.example.com:8000
export FTP_PROXY=proxy.example.com:8000

along with their lowercase counterparts. Git and Cargo both have in their configuration:

[http]
proxy = proxy.example.com:8000

[https]
proxy = proxy.example.com:8000

and git from the command line works fine; however, when Cargo attempts to fetch a repository, I encounter

$ cargo build
    Updating git repository `https://github.com/pistondevelopers/piston`
Unable to update https://github.com/pistondevelopers/piston

Caused by:
  failed to fetch into /home/user/.cargo/git/db/piston-10111ca7958cf505

Caused by:
  [2] Failed to connect to github.com: No route to host

yet if I run git on its own, it works fine:

$ git clone https://github.com/pistondevelopers/piston
Cloning into 'piston'...
remote: Counting objects: 1959, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 1959 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1959/1959), 2.19 MiB | 575 KiB/s, done.
Resolving deltas: 100% (1252/1252), done.

[tomjakubowski]

Typically these proxy variables are given in the form of URLs (e.g. http://proxy.example.com:8000 or https://proxy.example.com:8443). It's possible that libgit2 is more strict about this than git or curl is.

[JP-Ellis]

I had actually thought of that, and I did try this with all the relevant proxy variables set with the full URLs. I.e., ~/.gitconfig and ~/.cargo/config containing:

[http]
proxy = "http://proxy.example.com:8000/"

[https]
proxy = "https://proxy.example.com:8000/"

and the environment variables being

export HTTP_PROXY=http://proxy.example.com:8000/
export HTTPS_PROXY=https://proxy.example.com:8000/
export FTP_PROXY=ftp://proxy.example.com:8000/

but the result remains the same.

[tomjakubowski]

Taking a quick look through libgit2's source, it looks like they handle reading HTTP proxy settings in a private-looking function, but only ever call this function from the winhttp transport.

And in fact, @alexcrichton has opened an issue for that here: libgit2/libgit2#2555

[alexcrichton]

Aha yes indeed! I would very much like cargo to support proxies. I believe that all of our own personal HTTP requests are routed through proxies when necessary (mostly when dealing with the registry), but as @tomjakubowski found out this has yet to move over to libgit2 on unix.

My plan at this point is to make a git2-curl package (or something like that) which provides an HTTP transport powered through curl-rust. That way we can do maximum configuration with curl-rust to support things like HTTP/SOCKS proxies, etc.

Thanks for opening this! It's good to have a tracker.

[bartavelle]

Is there a way to manually do the cloning ? I am new to rust, so I don't know where cargo is supposed to store the dependent repos ...

[bartavelle]

Ok I just cloned it and used a file:/// type url ..

[hamstergene]

Until this issue is fixed, you can use alias cargo='http_proxy= https_proxy= proxychains4 cargo' to workaround the problem, it works well for me. On OS X, proxychains can be installed via brew install proxychains-ng and configured by editing /usr/local/etc/proxychains.conf.

[aldanor]

Same story here -- behind a corporate proxy with SSL certificate injection (and both HTTP_PROXY/HTTPS_PROXY set to the same address):

$ cargo build --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
Unable to update registry https://github.com/rust-lang/crates.io-index

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  SSL error: error:140E0114:SSL routines:SSL_shutdown:uninitialized

E.g., I normally get git and wget working by settings http.sslverify=false and --no-check-certificate as defaults, but with cargo there doesn't seem a way around this.

Is this also caused by libgit2? If not and if it's caused by ssl verification, it'd be nice to have an option to ignore it (same as in `git).

[alexcrichton]

@aldanor yes that's coming from libgit2, but I don't think that it's coming from http.sslverify as I believe that libgit2 just doesn't handle connecting to HTTP proxies.

They did have support for http.sslverify awhile back, but it looks like they semi-recently removed it. We could always add support for it in Cargo as well though!

Are you sure that the only error there is http.sslverify, and not the fact that cargo isn't connecting to a proxy though?

[aldanor]

@alexcrichton Nope, not sure it's exactly the same problem (other than the OP's error was "no route to host" and not SSL-related), wonder how to confirm it? It's just I've faced this same problem with most tools and package managers (git, npm, wget, pip to name a few) and in each case it was solved by disabling ssl verification, hence the assumption it was also the problem here.

If I enable http.sslverify on git, it yields:

$ git config --global http.sslverify true
$ git clone https://github.com/rust-lang/cargo.git
Cloning into 'cargo'...
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/rust-lang/cargo.git/info/refs
fatal: HTTP request failed

which is a different SSL routine and a different error code, hm...

So maybe libgit2 fails at connecting to proxy in the first place, like you said.