Supports HTTPS proxy authorization

[earthengine]

Are there a way to support HTTPS proxy authorization? Idealy it should be

export $proxy-authorization="Basic YWxhZGRpbjpvcGVuc2VzYW1l"

Otherwise, for organizations that require proxy authorization, we could not connect.

I also quickly looked at the code under src/download/lib.rs, couldn't find "authorization" or "authentication" so I assume this function is not currently existing.

[whizsid]

I will work on this issue.

[kinnison]

Support for this would belong in the libraries we use for fetching. So the curl and reqwest libraries. We use env_proxy for reqwest, but curl finds its own proxy information from the environment itself.

I would suggest @whizsid begin by looking at those libraries to see if they support this kind of authentication approach.

[whizsid]

@kinnison I investigated it and there are no option to set custom proxies. Only method is to resolve this issue is implement our own proxy env resolver and construct the reqwest and curl clients with these proxy settings.

[kinnison]

My preference, as stated on the PR, is to try and resolve this in the upstream crates, since otherwise we're carrying complexity we shouldn't really own.

[amejia1]

Like what earthengine posted years back, it would be great to use a rustup proxy using basic username/password credentials. Could there be a RUSTUP_AUTH_HEADER or similarly named environment variable that can be used to set a default Authorization header for curl and/or reqwest from rustup? If such support existed, a script that could be used to use these kind of proxies can look like the following.

#!/bin/sh
export RUSTUP_DIST_SERVER="https://rustup-dist-proxy"
export RUSTUP_UPDATE_ROOT="${RUSTUP_DIST_SERVER}/rustup"
export RUSTUP_AUTH_HEADER="Basic $(echo 'username:password' | base64)"
exec rustup "$@"

There's a similar tool that supports this kind of usage of proxies, the nvm tool which manages nodejs installs. Their support for proxies that require authentication involves running scripts or similar programs such as the following.

#!/bin/sh
export NVM_NODEJS_ORG_MIRROR="https://nodejs-org-proxy"
export NVM_AUTH_HEADER="Basic $(echo 'username:password' | base64)"
exec nvm "$@"

[djc]

I think this should work if you just use `HTTPS_PROXY=http://username:password@my.proxy.net/"?

[amejia1]

That is sort of the workaround I am using now, except I set that kind of URL in the RUSTUP_DIST_SERVER environment variable directly. So I use something like this.

#!/bin/sh
export RUSTUP_DIST_SERVER="https://username:password@rustup-dist-proxy"
export RUSTUP_UPDATE_ROOT="${RUSTUP_DIST_SERVER}/rustup"
exec rustup "$@"

Maybe this is fine for those that only need to support Basic auth to authenticate against a proxy. I was expecting to see support similar to how it's done in nvm where you give it the value of an 'Authorization' HTTP header you want to send. I think cargo also supports setting the value of an 'Authorization' HTTP header through the credential provider. The cargo documentation here has this statement.

The token will be sent to the registry as the value of the Authorization HTTP header.

[djc]

I'm still unclear on what it is that you need from rustup and why you're not getting it.

[amejia1]

What I am requesting is a way to have rustup set the value of an Authorization HTTP header to a specific value I specify whenever it makes any web request. I am requesting this so I can use a private rustup distribution server that requires authentication.

I tried using the HTTPS_PROXY environment variable but it doesn't work for me. See this for example.

~
❯ $env:HTTPS_PROXY = "http://username:password@127.0.0.1:8080"

~
❯ rustup update
2026-01-04T21:18:47.178015Z DEBUG rustup::cli::common: read metadata version: '12'
2026-01-04T21:18:47.224824Z DEBUG rustup::cli::common: updating existing install for 'stable-x86_64-pc-windows-gnu'
2026-01-04T21:18:47.224939Z DEBUG rustup::cli::common: toolchain directory: 'C:\Users\andre\.rustup\toolchains\stable-x86_64-pc-windows-gnu'
2026-01-04T21:18:47.251169Z  INFO rustup::cli::common: syncing channel updates for 'stable-x86_64-pc-windows-gnu'
2026-01-04T21:18:47.251738Z DEBUG rustup::cli::common: creating temp file: C:\Users\andre\.rustup\tmp\cm4x1rk9ddeo7rri_file
2026-01-04T21:18:47.252543Z DEBUG rustup::cli::common: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256'
2026-01-04T21:18:47.252662Z DEBUG rustup::cli::common: downloading with reqwest
2026-01-04T21:18:47.252982Z DEBUG reqwest::connect: starting new connection: https://static.rust-lang.org/
2026-01-04T21:18:47.253252Z DEBUG reqwest::connect: proxy(http://127.0.0.1:8080) intercepts 'https://static.rust-lang.org/'
2026-01-04T21:18:47.253397Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:18:47.254601Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080
2026-01-04T21:18:47.254756Z DEBUG reqwest::connect: tunnel to static.rust-lang.org:443 using basic auth
2026-01-04T21:18:47.255103Z ERROR rustup::download::reqwest_be: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256", source: hyper_util::client::legacy::Error(Connect, "unsuccessful tunnel") })
2026-01-04T21:18:47.256219Z ERROR rustup::cli::common: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to 'C:\Users\andre\.rustup\tmp\cm4x1rk9ddeo7rri_file'
2026-01-04T21:18:47.298825Z DEBUG rustup::cli::common: updating existing install for 'stable-x86_64-pc-windows-msvc'
2026-01-04T21:18:47.298984Z DEBUG rustup::cli::common: toolchain directory: 'C:\Users\andre\.rustup\toolchains\stable-x86_64-pc-windows-msvc'
2026-01-04T21:18:47.325667Z  INFO rustup::cli::common: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
2026-01-04T21:18:47.326127Z DEBUG rustup::cli::common: creating temp file: C:\Users\andre\.rustup\tmp\pkyox0faaitzm32z_file
2026-01-04T21:18:47.326707Z DEBUG rustup::cli::common: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256'
2026-01-04T21:18:47.326886Z DEBUG rustup::cli::common: downloading with reqwest
2026-01-04T21:18:47.327401Z DEBUG reqwest::connect: starting new connection: https://static.rust-lang.org/
2026-01-04T21:18:47.327526Z DEBUG reqwest::connect: proxy(http://127.0.0.1:8080) intercepts 'https://static.rust-lang.org/'
2026-01-04T21:18:47.327584Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:18:47.328191Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080
2026-01-04T21:18:47.328368Z DEBUG reqwest::connect: tunnel to static.rust-lang.org:443 using basic auth
2026-01-04T21:18:47.328786Z ERROR rustup::download::reqwest_be: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256", source: hyper_util::client::legacy::Error(Connect, "unsuccessful tunnel") })
2026-01-04T21:18:47.329886Z ERROR rustup::cli::common: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to 'C:\Users\andre\.rustup\tmp\pkyox0faaitzm32z_file'
2026-01-04T21:18:47.330103Z  INFO rustup::cli::self_update: checking for self-update
2026-01-04T21:18:47.330506Z DEBUG reqwest::connect: starting new connection: https://static.rust-lang.org/
2026-01-04T21:18:47.330596Z DEBUG reqwest::connect: proxy(http://127.0.0.1:8080) intercepts 'https://static.rust-lang.org/'
2026-01-04T21:18:47.330649Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:18:47.330989Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080
2026-01-04T21:18:47.331093Z DEBUG reqwest::connect: tunnel to static.rust-lang.org:443 using basic auth
2026-01-04T21:18:47.331348Z ERROR rustup::download::reqwest_be: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: "https://static.rust-lang.org/rustup/release-stable.toml", source: hyper_util::client::legacy::Error(Connect, "unsuccessful tunnel") })
2026-01-04T21:18:47.332448Z ERROR rustup::cli::common: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to 'C:\Users\andre\AppData\Local\Temp\rustup-updateZcA3OZ\release-stable.toml': error downloading file: error sending request for url (https://static.rust-lang.org/rustup/release-stable.toml): client error (Connect): unsuccessful tunnel

If I use the RUSTUP_DIST_SERVER environment variable instead, it works.

~
❯ $env:RUSTUP_DIST_SERVER = "http://username:password@127.0.0.1:8080"

~
❯ $env:RUSTUP_UPDATE_ROOT = "${env:RUSTUP_DIST_SERVER}/rustup"

~
❯ rustup update
2026-01-04T21:22:58.636806Z DEBUG rustup::cli::common: read metadata version: '12'
2026-01-04T21:22:58.684544Z DEBUG rustup::cli::common: updating existing install for 'stable-x86_64-pc-windows-gnu'
2026-01-04T21:22:58.684709Z DEBUG rustup::cli::common: toolchain directory: 'C:\Users\andre\.rustup\toolchains\stable-x86_64-pc-windows-gnu'
2026-01-04T21:22:58.711329Z  INFO rustup::cli::common: syncing channel updates for 'stable-x86_64-pc-windows-gnu'
2026-01-04T21:22:58.711902Z DEBUG rustup::cli::common: creating temp file: C:\Users\andre\.rustup\tmp\so2ujkdd_103ueug_file
2026-01-04T21:22:58.712507Z DEBUG rustup::cli::common: downloading file from: 'http://username:password@127.0.0.1:8080/dist/channel-rust-stable.toml.sha256'
2026-01-04T21:22:58.712641Z DEBUG rustup::cli::common: downloading with reqwest
2026-01-04T21:22:58.712978Z DEBUG reqwest::connect: starting new connection: http://127.0.0.1:8080/
2026-01-04T21:22:58.713121Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:22:58.714506Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080
2026-01-04T21:22:58.782574Z DEBUG rustup::cli::common: deleted temp file: C:\Users\andre\.rustup\tmp\so2ujkdd_103ueug_file
2026-01-04T21:22:58.784864Z DEBUG rustup::cli::common: toolchain is already up to date
2026-01-04T21:22:58.827014Z DEBUG rustup::cli::common: updating existing install for 'stable-x86_64-pc-windows-msvc'
2026-01-04T21:22:58.827167Z DEBUG rustup::cli::common: toolchain directory: 'C:\Users\andre\.rustup\toolchains\stable-x86_64-pc-windows-msvc'
2026-01-04T21:22:58.852836Z  INFO rustup::cli::common: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
2026-01-04T21:22:58.853392Z DEBUG rustup::cli::common: creating temp file: C:\Users\andre\.rustup\tmp\46ujwsrvhs1p3rvw_file
2026-01-04T21:22:58.854084Z DEBUG rustup::cli::common: downloading file from: 'http://username:password@127.0.0.1:8080/dist/channel-rust-stable.toml.sha256'
2026-01-04T21:22:58.854223Z DEBUG rustup::cli::common: downloading with reqwest
2026-01-04T21:22:58.854593Z DEBUG reqwest::connect: starting new connection: http://127.0.0.1:8080/
2026-01-04T21:22:58.854693Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:22:58.855533Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080
2026-01-04T21:22:58.884552Z DEBUG rustup::cli::common: deleted temp file: C:\Users\andre\.rustup\tmp\46ujwsrvhs1p3rvw_file
2026-01-04T21:22:58.886253Z DEBUG rustup::cli::common: toolchain is already up to date
2026-01-04T21:22:58.886671Z  INFO rustup::cli::self_update: checking for self-update
2026-01-04T21:22:58.887551Z DEBUG reqwest::connect: starting new connection: http://127.0.0.1:8080/
2026-01-04T21:22:58.887648Z DEBUG hyper_util::client::legacy::connect::http: connecting to 127.0.0.1:8080
2026-01-04T21:22:58.888134Z DEBUG hyper_util::client::legacy::connect::http: connected to 127.0.0.1:8080

   stable-x86_64-pc-windows-gnu unchanged - rustc 1.92.0 (ded5c06cf 2025-12-08)
  stable-x86_64-pc-windows-msvc unchanged - rustc 1.92.0 (ded5c06cf 2025-12-08)

2026-01-04T21:22:58.948282Z  INFO rustup::cli::rustup_mode: cleaning up downloads & tmp directories

However, I consider this a workaround due to the potential of having user creds end up in log files as you can see in my logs above. I think having rustup support setting an Authorization HTTP header would be a better way to make use of proxies for rustup.

[djc]

Seems like we should try to fix it so that the HTTPS_PROXY approach works, rather than adding yet another mechanism.

Given that I don't have a good test environment for this, I'm unlikely to work on this, but happy to give guidance/review a PR.

[amejia1]

I can give it a try in my free time. My test proxy is a ferron web server with the below config and notes.

// This is for starting a simple proxy that requires basic auth. The only valid credentials will be 'test:123?45>6'. The
// docker command to run is the following (assuming the current working directory is the directory with this .kdl file.)
//
// $ docker run --detach --name ferron-rustup-dist-server 8080:8080 --volume "$(pwd):/mnt/cwd" ferronserver/ferron:2 ferron --config /mnt/cwd/ferron-rustup-dist-server.kdl
//
// For powershell users, the equivalent command is the following.
//
// > docker run --detach --name ferron-rustup-dist-server --publish 8080:8080 --volume "$(Get-Location):/mnt/cwd" ferronserver/ferron:2 ferron --config /mnt/cwd/ferron-rustup-dist-server.kdl
//
// Once the server is started, have rustup use it by setting the necessary environment variables.
//
// $ export RUSTUP_DIST_SERVER="http://localhost:8080"
// $ export RUSTUP_UPDATE_ROOT="${RUSTUP_DIST_SERVER}/rustup"
//
// In powershell, the equivalent commmands are the following.
//
// > $env:RUSTUP_DIST_SERVER = "http://localhost:8080"
// > $env:RUSTUP_UPDATE_ROOT = "${env:RUSTUP_DIST_SERVER}/rustup"
//
// Use of this proxy would work with this Authorization header (derived from the test creds 'test:123?45>6').
//
// Authorization: Basic dGVzdDoxMjM/NDU+Ng==
//
// The 'RUSTUP_LOG' environment variable should also be set so you can see what server is being used for web requests. Once
// testing is done, the server can be stopped using the following command.
//
// $ docker stop ferron-rustup-dist-server && docker rm ferron-rustup-dist-server

:8080 {
  status 401 regex=".*" users="test"
  user "test" "$argon2id$v=19$m=19456,t=2,p=1$emTillHaS3OqFuvITdXxzg$G00heP8QSXk5H/ruTiLt302Xk3uETfU5QO8hBIwUq08"
  proxy "https://static.rust-lang.org/"
}

In this test case, basic auth is required but support for other authentication schemes (bearer, digest, etc.) should be implemented as well.

[amejia1]

Today I learned the difference between a forward proxy and a reverse proxy. To clarify, my issue is with supporting reverse proxies that require authentication and then forward traffic to the main rustup dist server. Still, I think an implementation that supports adding an 'Authorization' HTTP header can work the same as one that supports adding a 'Proxy-Authorization' HTTP header. I will focus on supporting the 'Authorization' header first.