Powershell installer: respect HTTPS_PROXY and ANY_PROXY env vars

[zsol]

This PR makes the Windows Powershell (.ps1) installer respect HTTPS_PROXY and ANY_PROXY as environment variables while fetching a binary.

Note

This doesn't support HTTP_PROXY, or NO_PROXY env vars, but it's better than nothing.

Manual Testing

Details

I've tested it with `cargo-dist` itself:

cargo build --release
.\target\release\dist init
.\target\release\dist build -a global -i powershell

And then, without proxy env vars:

❯ powershell -ExecutionPolicy ByPass .\target\distrib\dist-installer.ps1 -Verbose
Downloading dist 1.0.0-rc.1 (x86_64-pc-windows-msvc)
VERBOSE:   from https://github.com/axodotdev/cargo-dist/releases/download/v1.0.0-rc.1/dist-x86_64-pc-windows-msvc.zip
VERBOSE:   to C:\Users\zsolz\AppData\Local\Temp\632c46c5-f32d-422e-a010-695f66bcf768\dist.zip
VERBOSE: Unpacking to C:\Users\zsolz\AppData\Local\Temp\632c46c5-f32d-422e-a010-695f66bcf768
VERBOSE:   Unpacked dist.exe
Installing to C:\Users\zsolz\.cargo\bin
  dist.exe
everything's installed!
VERBOSE: Adding C:\Users\zsolz\.cargo\bin to your user-level PATH
VERBOSE: Install directory C:\Users\zsolz\.cargo\bin already on PATH, all done!

With proxy env vars:

❯ $env:HTTPS_PROXY = "http://proxyuser:proxypass@localhost:3128"
❯ powershell -ExecutionPolicy ByPass .\target\distrib\dist-installer.ps1 -Verbose
Downloading dist 1.0.0-rc.1 (x86_64-pc-windows-msvc)
VERBOSE:   from https://github.com/axodotdev/cargo-dist/releases/download/v1.0.0-rc.1/dist-x86_64-pc-windows-msvc.zip
VERBOSE:   to C:\Users\zsolz\AppData\Local\Temp\7ddaa0b9-de37-4206-879a-a7fbc59e4118\dist.zip
Exception calling "DownloadFile" with "2" argument(s): "Unable to connect to the remote server"

And then if I fire up a proxy server that requires auth, it works again.

See also

#2075 where most of the debugging happened

Closes astral-sh/uv#10709

[mistydemeo]

Looks like PSScriptAnalyzer has flagged a few things in CI; can you make the suggested changes?

[zsol]

Done! Hope I got the PSScriptAnalyzer lints, I didn't figure out how to run those locally :P

[mistydemeo]

PSScriptAnalyzer worked! Looks like one of the snapshots was missed though - the updated snapshot in the diff is for the wrong change.

[zsol]

Hmm I'm having trouble trying to run that particular test. Probably won't have time to figure out what's going on today

[zsol]

This is what the test outputs, in case you have any tips: https://gist.github.com/zsol/6e7764fa39178bc39a92f7ac3644ccae

[mistydemeo]

Aha, that requires the omnibor CLI tool to be installed. I can go ahead and update that test snapshot for you and push the change to this branch if you like.

[zsol]

Hmm but I thought I specifically installed it using cargo install --locked omnibor-cli. In any case, if you have time, I'd appreciate the help :)

[stoating]

This is a welcome update to the installer/self update script, but it currently only supports proxies which expect user/pass basic authentication. In other proxies, which are using Kerberos or NTLM, I suppose this method will not be adequate.

In such cases, the $proxy.Credentials may need to be grabbed using the following:
after:
$webProxy = New-Object System.Net.WebProxy($uri)
set the credentials to:
$webProxy .Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

You may find the type of credential by getting the current user and asking their authentication type (I'm not sure it is reliable or if there is a better way to attempt to find the right 'Credentials'. One could also just try all known methods one after the other until something works)

$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
Write-Host "Current Windows User: $($currentUser.Name)"
Write-Host "Authentication Type: $($currentUser.AuthenticationType)" -> generally returns 'Kerberos', 'NTLM', or 'Negotiate'.

If 'Kerberos' or 'NTLM' then try:
$webProxy .Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

Instead of parsing out the user/pass from HTTP_PROXY.

If this is a change you would be open to, I'll check if in the coming days I can find the time to create an Issue/PR.

[zsol]

AFAIU if you don't set the env variables, the script will fall back to the default system-wide proxy (if that's set). I would assume that proxies that require complex authentication would usually be configured properly on the system anyway.

Is that not the case for you, @stoating ?

[stoating]

AFAIU if you don't set the env variables, the script will fall back to the default system-wide proxy (if that's set). I would assume that proxies that require complex authentication would usually be configured properly on the system anyway.

Is that not the case for you, @stoating ?

@zsol, after taking your change and being able to test it thoroughly in the necessary environment, it looks like you are correct 👍. Your merged change appears to address the issues we were having with the standalone install as well.