Problem
curl error when using: curl https://sh.rustup.rs -sSf | sh -s -- -y
docker run -it centos:6 /bin/bash
[root@081cc8b7180c /]# curl
curl: try 'curl --help' or 'curl --manual' for more information
[root@081cc8b7180c /]# curl https://sh.rustup.rs -sSf | sh -s -- -y
info: downloading installer
curl: option --proto: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
rustup: command failed: downloader https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init /tmp/tmp.fBaoqs014w/rustup-init
Expected (this worked until 4 days ago):
curl https://sh.rustup.rs -sSf | sh -s -- -y
info: downloading installer
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2019-04-11, rust version 1.34.0 (91856ed52 2019-04-10)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: default toolchain set to 'stable'
stable installed - rustc 1.34.0 (91856ed52 2019-04-10)
Rust is installed now. Great!
To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH
environment variable. Next time you log in this will be done automatically.
To configure your current shell run source $HOME/.cargo/env
Steps
Possible Solution(s)
N/A
Notes
Output of rustup --version: N/A
Output of rustup show: N/A
This is a side-effect of our change to rustup-init.sh to force newer TLS versions always.
The --proto option is nine years old and was part of 7.21.0 released June 16th 2010.
I suggest that you come up with a way to update the version of curl available in your docker because to undo the change we made would be to weaken a commitment to stronger security around the installation of rustup.
If you really can't update curl, then perhaps we can come up with a way to force the use of wget on centos (assuming centos's wget supports --https-only and --secure-protocol=TLSv1_2)
Simpler solution is to download and run this file if you're on x86-64-linux machine:
https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init
Ok that is unfortunate. Does this mean CentOS 6 is not a supported target for rustup? At https://github.com/OISF/suricata we just made our Rust support mandatory and one of the reasons was that for CentOS 6 it could be installed (& then kept up to date) using very simple instructions.
No, Rustup should run well on CentOS 5+. The problem is in the rustup-init.sh script.
Can you point out which part in your project use rustup.rs so we can help?
I don't use it other than as part of my QA/CI infra, but we want to give users a simple instruction of how to upgrade our program from 4 (optional rust) to 5 (mandatory rust). Since quite a few of our users are still on CentOS 6, having a simple instruction like rustup normally provides would work best.
We could tell them to pull down the rustup-init for their arch manually (I confirmed it works), or have them install a more recent curl. But I was under the impression rustup was actually trying to solve these issues for us :)
We are trying to make it easy and safe to get Rust. In order to reduce the chance of TLS downgrade attacks, we introduced this flag to our use of curl (and similarly for wget) and we ensured our configuration of TLS inside rustup was similarly secured. I certainly don't want to make it impossible for your users, so we need to come up with a halfway house.
@lzutao suggested on our discord channel that we have some kind of flag to allow you to say to rustup-init.sh that you accept the risks of not requiring TLS 1.2. Would you prefer that to be a commandline argument, or an environment variable?
As a work-around, if you're able to install a curl proxy into the user's path, you could swallow the unrecognised arguments before passing it on to curl-proper.
I could see 2 paths (w/o reverting the new behaviour):
I'm wondering though, how much protection does this option really give? I mean it seems everything that is done is under the Rust projects control, so I guess I'm not really seeing the attack vector. But maybe I've missed an analysis on the issue somewhere.
I think that a check/downgrade-if-option-set is the only approach which is going to maintain the benefit while not causing users of older operating systems too much pain. Regarding the protections - downgrade attacks (which I'd tend to assume would be in the infra between the users's computer and rust-lang's servers) open the way to potentially introducing bad code into the compiler which is installed. Right now this is (to my mind) fairly unlikely, but it is a vector we'd prefer to protect ourselves against, no matter how unlikely we imagine it might be.
This is hitting us with our CI in https://github.com/pantsbuild/pants too, as we use Centos6 to build our native wheels for max compatibility.
I think that a check/downgrade-if-option-set is the only approach which is going to maintain the benefit while not causing users of older operating systems too much pain.
I think this is a good solution. Perhaps log a warning that you have to make this downgrade.
Thanks for your help here!
Looks like Rust in macOS 10.12 is broken with image xcode9.2 (on Travis). :sob:
But we have temporary workaround.
Is this travis-ci error related as well?
info: downloading installer
curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect
rustup: command failed: downloader https://static.rust-lang.org/rustup/dist/x86_64-apple-darwin/rustup-init /var/folders/bb/n7t3rs157850byt_jfdcq9k80000gn/T/tmp.yZX1SGRn/rustup-init
/Users/travis/.travis/functions: line 108: rustc: command not found
https://travis-ci.org/OISF/suricata/jobs/523642627
I believe its using xcode 8.3