4 ms·

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 a

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.

Tomte 8y ago
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)
- windwake12 8y ago
  According to Google/SO curl can indeed be built/configured to use the Windows cert store, seems that would be a better fix?
  - moosingin3space 8y ago
    Another fix could be to use Hyper with tokio-tls. Under the hood, that package uses Windows schannel, macOS SecureTransport, and a dynamically-linked openssl on everything else.
    - littlestymaar 8y ago
      It already uses `reqwest`, which uses schannel. See https://news.ycombinator.com/item?id=19732721 https://news.ycombinator.com/item?id=19732721
- Arnavion 8y ago
  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/6389676b6bf21143e3c43a18482433ce8094381c 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`

Tomte 8y ago

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)

windwake12 8y ago
According to Google/SO curl can indeed be built/configured to use the Windows cert store, seems that would be a better fix?
- moosingin3space 8y ago
  Another fix could be to use Hyper with tokio-tls. Under the hood, that package uses Windows schannel, macOS SecureTransport, and a dynamically-linked openssl on everything else.
  - littlestymaar 8y ago
    It already uses `reqwest`, which uses schannel. See https://news.ycombinator.com/item?id=19732721 https://news.ycombinator.com/item?id=19732721
Arnavion 8y ago
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/6389676b6bf21143e3c43a18482433ce8094381c 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`