rust-lang
CfT: Test out Rustup's `reqwest` backend with `rustls`
[!NOTE] rustup v1.28.0 beta is now available for early adopters! See this discussion thread for more info :)
In #3790, we have started an initiative to make reqwest/rustls Rustup's future download/TLS backend combination.
While a maximally-Rust stack might sound exciting, we want to get it tested beforehand to minimize the possibility for you to experience hiccups in production.
If you're using rustup v1.28+, this should be available for you by default [^3] ~~; for rustup v1.27 and earlier, chances are you can opt in right now by setting the environment variable RUSTUP_USE_RUSTLS=1 [^1]~~ .
Please feel free to share your experiences below, and many thanks in advance 🙇♀️
Note
You can report in this issue the changes that switching to rustls has made to your workflow, so I assume most of them are breakages: what worked before but now doesn’t work with rustls.
Of course, it could also be the opposite, i.e. what didn't work but now works.
If you can’t feel any difference, that’s actually a good news for us! Just reacting with 😄[^2] to this message would be perfect in this case :)
Tasks
- [x] https://github.com/rust-lang/rustup/pull/3979
[^1]: Please make sure that RUSTUP_USE_CURL is NOT set, otherwise the curl download backend will be selected; to opt out, just set RUSTUP_USE_RUSTLS=0.
[^2]: ~~GitHub has recently replaced the emoji with 😂, I have no idea why this is the case 🤷♀~~ No, they have changed it back, never mind :)
[^3]: At the time of writing, the only exceptions are powerpc64*, loongarch*, *openbsd* and *illumos*.
An interesting observation by @llde indicates that this change might be a move in the right direction!
RUSTUP_USE_RUSTLS=1 seems to be another workaround with last rustup version.
https://github.com/rust-lang/rustup/issues/3689#issuecomment-2094159776
This CfT has been added to TWiR Issue 546.
You may now remove the call-for-testing label. Please feel free to re-add the label if you wish this CfT to appear again in a future issue.
Rustls is completely unusable with the WARP Gateway (a corporate VPN) due to lack of support for p521 signatures.
RUSTUP_USE_RUSTLS=1 rustup update
info: syncing channel updates for 'stable-aarch64-apple-darwin'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256' to '~/.rustup/tmp/pnvxaiia4u2hcr_n_file'
info: syncing channel updates for 'nightly-aarch64-apple-darwin'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-nightly.toml.sha256' to '~/.rustup/tmp/ay1l00g5xg91pnuc_file'
info: syncing channel updates for '1.63-aarch64-apple-darwin'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-1.63.toml.sha256' to '~/.rustup/tmp/0oaqi61f4mgwqa4n_file'
info: syncing channel updates for '1.64-aarch64-apple-darwin'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-1.64.toml.sha256' to '~/.rustup/tmp/9rhc8csclaotwleh_file'
info: syncing channel updates for '1.65-aarch64-apple-darwin'
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-1.65.toml.sha256' to '~/.rustup/tmp/26d6fm0my9i9sgvg_file'
info: checking for self-update
error: could not download file from 'https://static.rust-lang.org/rustup/release-stable.toml' to '/var/folders/lq/fqqfw_z50v96h8tlkj56c8wc0000gn/T/rustup-update5PMZuE/release-stable.toml'
Caused by:
0: failed to make network request
1: error sending request for url (https://static.rust-lang.org/rustup/release-stable.toml): error trying to connect: invalid peer certificate: BadSignature
2: error trying to connect: invalid peer certificate: BadSignature
3: invalid peer certificate: BadSignature
The curl backend has no problems with it.
@kornelski interesting... So WARP MITMs all connections, and only supports P521 for this? That seems pretty restrictive and a little surprising. Or is this configurable for WARP and does your WARP org require the stronger curve?
https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/user-side-certificates/custom-certificate/ suggests that RSA is supported for custom roots so it doesn't look like P521 is a requirement for the product itself?
Now that we have released v1.28.0 beta (https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-v1-28-0), it'd be nice to give the CfT tag another try :)
Hi, @rami3l,
This CfT has been added to TWiR Issue 579.
You may now remove the call-for-testing label. Please feel free to re-add the label if you wish this CfT to appear again in a future issue (or leave the label on if you don't see much response over the holidays).
Happy holidays!
I think 1.28 needs a small change like extending the timeout period https://github.com/rust-lang/rustup/issues/4213
Hello,
I've started running into an issue with rustup 1.28.0 since switching to the rustls backend. Apologies for not noticing the CfT for testing sooner - I would have tried these changes in our environment sooner.
For some context, I'm running rustup inside of a rather restrictive corporate environment and we have a mirror of Rust crates and toolchains (mirror created with Panamax) and we configure RUSTUP_DIST_SERVER and RUSTUP_UPDATE_ROOT to point to this mirror. Our crate/toolchain mirror is secured with a certificate issued from our own internal CA. When attempting to use rustup 1.28 with this mirror, I now see the error:
error sending request for url (https://rustmirror.ourcompany.com/dist/channel-rust-1.85.0.toml.sha256): client error (Connect): invalid peer certificate: Other(OtherError(NameConstraintViolation))
This CA hasn't caused any problems with rustup in the past and switching back an alternative backend (either by setting RUSTUP_USE_RUSTLS=0 or RUSTUP_USE_CURL=1 works perfectly fine. OpenSSL appears to verify the certificate used by the server correctly, and it seems to work fine with other TLS implementations as well (e.g. a dummy Golang or Java client that just tries to make an https connection works fine).
Our CA structure is something like this:
Root CA -> Issuing CA -> Server Cert (e.g. rustmirror.ourcompany.com)
The only name constraint that I can see is that our Root CA has a name constraint for C=CA so that all certs below the Root CA should have this constraint and I have verified that C=CA is part of the other certs in the chain. I will mention that I've now noticed that the leaf certificate has C=ca whereas the other certs in the chain are C=CA (note the case difference) - my understanding is that this shouldn't be problematic but I mention it for the sake of completeness.
If there's any other debugging steps that can be done on my side to provide more information I'm happy to try to do my best to help, but for now I'll be sticking with the Curl backend and would humbly request that it not be removed any time soon. 😅
Can you file a separate issue? Might be interesting to see if you can isolate this in a test binary directly using rustls-platform-verifier.