Proxy authentication mechanism support in cargo

[baburkin]

Problem statement

Currently cargo does not support updating crates index from GitHub behind some types of proxy, e.g. NTLM (which can often be the case for companies that don't allow direct access to GitHub due to corporate security policies).

For example, I am able to download the index manually, via curl, e.g.:

curl -vv --proxy-ntlm -U <user>:<password> --proxy <https://proxy:8080> https://github.com/rust-lang/crates.io-index

But cargo fails to apply the correct authentication mechanism when dealing with the proxy.

Proposed solution

Ideally, it would be nice to be able to to specify in ~/.cargo/config:

[http]
proxy = "host:port" # HTTP proxy to use for HTTP requests (defaults to none)
proxy-auth = "ntlm" # negotiate, basic, digest, etc... 
proxy-user = "username"
proxy-password = "password"
...          

And cargo should use that config for proxy authentication.

Notes There are few other proxy authentication (DIGEST, SPNEGO, etc.) methods that curl supports besides the NTLM, so eventually all of them might be supported by cargo.

This feature request was spawned off from Issue 6513

[alexcrichton]

Thanks for opening this up @baburkin If you're curious to work on this, that'd be awesome! It looks like the configuration would go roughly around here and the methods this'd use would be:

• Easy::proxy_auth
• Easy::proxy_username
• Easy::proxy_password

We'd probably want to make sure that the password could be loaded from ~/.cargo/credentials as well in case it's preferred to be stored there instead of in normal config files.

[baburkin]

Temporary workaround has been found and described here.

[olijaun]

Since there seems to be no movement here I just wanted to say that this is really a problem. I wanted to have a look at rust in order to see whether it would be interesting for our company and I lost a whole afternoon due to this. Will try the mentioned workaround now.

[your-diary]

Any updates? The workaround mentioned above didn't work.

[Eh2406]

git-fetch-with-cli = true is one work around. You may also be interested in https://github.com/rust-lang/cargo/issues/9069 witch removes the use of git from the index.

[your-diary]

@Eh2406 git is irrelevant in my case (as far as I think). I cannot access crates.io via cargo.

Here's the Cargo.toml:

[package]
name = "hello"
version = "0.1.0"
edition = "2021"

[dependencies]
thirtyfour_sync = "0.27.1"

and cargo check gives

warning: spurious network error (2 tries remaining): [56] Failure when receiving data from the peer (Received HTTP code 407 from proxy after CONNECT)
(snip (many duplicate lines here))
error: failed to download from `https://crates.io/api/v1/crates/async-trait/0.1.56/download`

Caused by:
  [56] Failures when receiving data from the peer (Received HTTP code 407 from proxy after CONNECT)

When I use curl,

$ curl https://crates.io/
curl: (56) Received HTTP code 407 from proxy after CONNECT

$ curl --proxy-ntlm --proxy-user <user>:<password> --proxy <IP> https://crates.io/
{"errors":[{"detail":"Not Found"}]} #error response from crates.io (i.e. request itself succeeded)

I can also access crates.io via browsers.

[brianblank]

I'm also getting a 407 code from cargo which is due to failed authentication with a corporate proxy server. The above code changes from babukin appear to add the necessary parameters to the configuration to allow us to specify the details necessary to get the proxy server to work correctly with cargo.

What is needed to move this fix forward?

[hhirtz]

Hey, I made a working cargo patch here: #11433 It'd be nice if others could test it out.

The idea is to have the proxy auth work automatically when it's possible, so just setting http_proxy/https_proxy should work. If not, you can set http.proxy-username and http.proxy-password in your config.

The main issue from what I can tell is that corporate (kerberos) proxies use "gss"/spnego authentication, which requires curl to be built with a 3rd-party library. However,

• curl-rust doesn't provide a way to vendor this dependency,
• official cargo builds seem to use the vendored curl flavor.

So either 1/ we need official cargo builds to link dynamically to libcurl and gss support depends on the user's libcurl, or 2/ figure out how to vendor libgss.

I'm more for option 2, so I opened an issue on curl-rust: https://github.com/alexcrichton/curl-rust/issues/481