refactor(download): remove curl backend

[rami3l]

Part of #3790.

Revives #2034, superseding #1657.

(Thanks @lnicola!)

Concerns

Switching to the curl backend via RUSTUP_USE_CURL will no longer be a workaround

• rustup-init hangs in armv7 docker container running on an arm64 Linux with reqwest backend #3122 (incomplete)
• reqwest http handler causes silent failure on AAarch64 Windows #3334
• Rustup cannot download hash file for toolchains channel information under Wine #3689 (works with reqwest/rustls)
• Can't install, fails with: "internal error inside Hyper and/or its dependencies, please report" #3391 (incomplete, upstream)
• Unable to download files, certificate verify failed #1856 (certificate)

[djc]

Have you taken stock of open issues referencing being solved by reverting to the curl backend?

Have you considered the alternative of using curl with the rustls TLS backend?

(Note: I am very much in favor of ditch curl and OpenSSL in favor of maximally-Rust solutions, but want to make sure we minimize the risk of getting users stuck.)

[rami3l]

Have you taken stock of open issues referencing being solved by reverting to the curl backend?

@djc I've added a new section to track this.

Have you considered the alternative of using curl with the rustls TLS backend?

Hmmm, with this option we are basically introducing curl/rustls to replace curl/openssl, and eliminating the notion of TLS backend (so no more reqwest/openssl) in our repo, right?

First, I'm not sure if this would cause more problems or not, since we're introducing something new. In other words, can these existing issues be worked around with curl/rustls?
Also, I'm not quite familiar with the building process, will we be shipping rustls twice with curl/rustls + reqwest/rustls with this approach? Looks like we won't.

But indeed, this would allow the removal of openssl to happen sooner. I guess I can try both...

PS: The 1.28.0 milestone is indicative, it only means I think this should be considered in this release cycle.

[djc]

So as I understand it:

• The default currently is to use reqwest with native-tls (OpenSSL on Linux, native stacks on macOS and Windows)
• If RUSTUP_USE_CURL is set, we use the curl backend, which defaults to openssl
• If RUSTUP_USE_RUSTLS is set, we use reqwest with rustls

There is no way of knowing whether the curl + rustls option would solve some of the issues that people have seen with using reqwest.

Perhaps we should compile or release builds with tracing support built in so that people can give us more detailed logging without compiling their own rustup.

At least for some of the issues, there's the suggestion that native-tls might actually be at fault, such that reqwest + rustls might actually do better than the default reqwest + native-tls option.

I would advocate making the reqwest + rustls option the default first and shipping that -- I have high trust in the rustls maintainers (there are two full-time maintainers and myself) so I think any rustls issuers could be resolved pretty quickly. The one thing I would like is to ship support for rustls-platform-verifier in reqwest.

[rami3l]

Perhaps we should compile or release builds with tracing support built in so that people can give us more detailed logging without compiling their own rustup.

@djc I guess that's a plus, yeah.

At least for some of the issues, there's the suggestion that native-tls might actually be at fault, such that reqwest + rustls might actually do better than the default reqwest + native-tls option.

I would advocate making the reqwest + rustls option the default first and shipping that -- I have high trust in the rustls maintainers (there are two full-time maintainers and myself) so I think any rustls issuers could be resolved pretty quickly. The one thing I would like is to ship support for rustls-platform-verifier in reqwest.

Do you think now is the right time to try out rustls even without rustls-platform-verifier?

[djc]

At least for some of the issues, there's the suggestion that native-tls might actually be at fault, such that reqwest + rustls might actually do better than the default reqwest + native-tls option.
I would advocate making the reqwest + rustls option the default first and shipping that -- I have high trust in the rustls maintainers (there are two full-time maintainers and myself) so I think any rustls issuers could be resolved pretty quickly. The one thing I would like is to ship support for rustls-platform-verifier in reqwest.

Do you think now is the right time to try out rustls even without rustls-platform-verifier?

Yes, I think it would make sense to flip the default for the reqwest backend to rustls, but in that case I feel like we should keep the curl backend around for now as a backup option. And should definitely include a good tracing setup so that we can ask folks for more detailed information if issues occur.

[rami3l]

Yes, I think it would make sense to flip the default for the reqwest backend to rustls, but in that case I feel like we should keep the curl backend around for now as a backup option. And should definitely include a good tracing setup so that we can ask folks for more detailed information if issues occur.

@djc In that case I guess we can still keep this PR as a potential second step. Just to be sure, should I remove reqwest/openssl as well while changing curl/openssl to curl/rustls in that first step?

[djc]

Yes, I think it would make sense to flip the default for the reqwest backend to rustls, but in that case I feel like we should keep the curl backend around for now as a backup option. And should definitely include a good tracing setup so that we can ask folks for more detailed information if issues occur.

@djc In that case I guess we can still keep this PR as a potential second step. Just to be sure, should I remove reqwest/openssl as well while changing curl/openssl to curl/rustls in that first step?

Yes, I think this could be a good second step. To be clear, I don't think we should make the curl + openssl -> curl + rustls change at the same time as promoting the reqwest + rustls backend to be the primary, since curl + openssl is currently a reliable fallback for scenarios where the default doesn't work, so I think we should keep it for a while longer. So I think the steps are:

1. Include tracing support with tracing-subscriber (I don't think we need opentelemetry stuff?) by default, make sure we don't constrain the trace!() level statically (using tracing Cargo features)
2. Switch the default from reqwest + native-tls to reqwest + rustls, keeping the curl + openssl fallback for now
   .. put out a release and wait a few months for feedback
3. Try again if we can ditch curl + openssl (and reqwest + native-tls)

[djc]

So does this mean we're branching off 1.30? Or do we think we can do this even in 1.29.1?

[djc]

(I forget, do we have a warning now when curl is enabled via an environment variable?)

[ChrisDenton]

I definitely think this should constitute a big change. People had been using it as a fallback if they were having issues. Hopefully that's not a problem any longer but still.

[ChrisDenton]

@rami3l you may need to remove bcrypt from here if it's no longer used:

rustup/build.rs

Line 69 in bd69b96

let delay_load_dlls = ["bcrypt", "api-ms-win-core-synch-l1-2-0"];

[rami3l]

So does this mean we're branching off 1.30? Or do we think we can do this even in 1.29.1?

@djc As I said I will pursue #4738 so this will be in v1.30, and I think the best way to land the workflow change is to actually make a breaking change :) I don't like repairing a vessel on the sea but I guess we have to do exactly that sooner or later regarding this...

That said I think it's a good idea to first make the backport branch, then bump the version, and finally merge this PR. This is also why I'm keeping it as a draft for now.

do we have a warning now when curl is enabled via an environment variable?

It's been enabled since a long time ago. 3cd156c was merged and shipped in May 2025 via v1.28.2. v1.30 will happen in 2027 if we go on like that XD

[rustbot]

☔ The latest upstream changes (possibly #4764) made this pull request unmergeable. Please resolve the merge conflicts.