The MITM proxy issue makes Rust a non-starter in many corporate environments.

Unfortunately, when someone tried to make a first step, he was treated very poorly and his work was sabotaged.

I don't have much hope that it will be addressed again soon: https://github.com/rust-lang/rustup.rs/pull/1624#pullrequest...

It's really sad, because Rust started with the same good idea as Golang: treat Windows users as first-class citizens.

That is a very uncharitable way to frame the linked discussion. Expressing concern about ignoring TLS certificates is not "sabotage".

Also, this doesn't have anything to do with Windows support that I can see.

Maybe "sabotage" was a bit strong, but the work seems to have been killed. Or is there some publically viewable discussion anymore?

It went from "rebase and I'll merge" to not a single word anymore about how it might be merged.

The Windows support thing is this: rustup/curl doesn't use Windows' own certificate store. Where employers put the TLS certificate for their intercepting proxies.

curl itself has the -k option, so the user can override the check (much, much easier than preparing a certificate bundle for curl – and since the employer intercepts and decrypts the traffic anyway, there is no security issue).

rustup calls curl without that flag. The pull request was to teach rustup to call curl with -k.

(I know that it doesn't solve the whole problem, because cargo itself needs to support it, as well)

The reqwest backend (which uses native-tls and thus schannel and thus the Windows cert store) is the default on Windows, so it shouldn't be using curl. https://github.com/rust-lang/rustup.rs/commit/6389676b6bf211...

If you must use an older rustup, set `$env:RUSTUP_USE_REQWEST` (or `$env:RUSTUP_USE_HYPER` for an even older rustup) to `1`