Rustup: Rustup 1.17 ignores http_proxy environment vars

[jsgf]

Problem


rustup 1.16 and before would accept proxy configuration via the http_proxy (and https_proxy environment variables). rustup 1.17 ignores this environment variable and always tries to connect directly.

Steps

With 1.16:

$ http_proxy=127.0.0.1:1123  https_proxy=127.0.0.1:1123 rustup self update
info: checking for self-updates
error: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to '/var/folders/05/jjgr0x5n2k7_h_g42xq2d5pr0p65z0/T/rustup-update.Ed9KcNtYvsVw/release-stable.toml'

ie failure shows it tried to use my bogus proxy

but with 1.17:

$ http_proxy=127.0.0.1:1123  https_proxy=127.0.0.1:1123 rustup self update
info: checking for self-updates

It should not have worked

Possible Solution(s)

Notes

Output of rustup --version:rustup 1.17.0 (069c88ed6 2019-03-05)
Output of rustup show:

Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
nightly-2018-12-06-x86_64-apple-darwin
nightly-2018-12-06-x86_64-unknown-linux-gnu
nightly-2018-12-31-x86_64-apple-darwin
nightly-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.33.0 (2aa4c46cf 2019-02-28)

Also happens in Linux.

[kinnison]

Thank you for this report.

I will look into why env_proxy isn't doing what we hoped, but in the meantime you can continue to use 1.17.0 if you add RUSTUP_USE_CURL=1 to your environment too.

I am sorry for causing you this inconvenience.

[dwijnand]

Discussed on Discord: https://discordapp.com/channels/442252698964721669/459149107387170817/553011624517304322

This seems to be related to the switch from the curl crate to reqwest/hyper.

The workaround is to use the curl crate: RUSTUP_USE_CURL=1.

[kinnison]

I have spent some time investigating and it seems that env_logger is perhaps a smidge more strict than cURL's interpretation of the environment variables. If you set http_proxy=http://127.0.0.1:1123 then you'll get the behaviour of reqwest using the false-proxy and failing. I think we possibly need to get some useful statement on what is valid in the proxy envvars and then if env_proxy is being overly strict, get it made slightly less so.

[kinnison]

Further investigation suggests that env_logger is using url to parse the content of the environment variable directly.

[jsgf]

OK, I can change the variables to include http[s]://.

There seems to be another difference in behaviour - curl will use http_proxy for http:// urls, and https_proxy for https:// urls, whereas the reqwest path will use either http_proxy or https_proxy. (I think?)

[kinnison]

Yes, env_proxy uses https_proxy.or(http_proxy).or(all_proxy) for HTTPS as it were.

[kinnison]

env_proxy 0.3.0 is less strict and we've merged a PR for that. I consider this closed for now.

[jsgf]

Do you plan to roll out a new release soon?

[kinnison]

There is no plan specifically to do so, but if we gather enough changes to warrant it, then yes we will. I have a number of small changes I'd like to see completed before we do though, so not for a month maybe.

[dzhang-b]

Same problem still exists in 1.21.

[0] # rustup
rustup 1.21.1 (7832b2ebe 2019-12-20)
The Rust toolchain installer

USAGE:
    rustup [FLAGS] [+toolchain] <SUBCOMMAND>

root@host:~/rust-example  0s
[0] # RUSTUP_USE_CURL=1 rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to '/root/.rustup/tmp/9gcjpzacfzkokuo8_file
info: checking for self-updates
error: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to '/tmp/rustup-updateNSw3Px/release-stable.toml'
error: caused by: error during download
error: caused by: [35] SSL connect error

[kinnison]

@dzhang-b I'm afraid that the report that you've made is not the same as the original poster's issue -- namely they had issues without CURL whereas you're reporting an issue with CURL. If you're having this kind of problem then it'd be useful if you could open a fresh issue and include as much data as you can, such as whether your system supports IPv6 and an strace of the attempt to update using CURL.