-
Notifications
You must be signed in to change notification settings - Fork 886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curl: option --proto: is unknown on CentOS 6 #1794
Comments
This is a side-effect of our change to The 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 |
Simpler solution is to download and run this file if you're on x86-64-linux machine: |
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 |
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 |
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 this is a good solution. Perhaps log a warning that you have to make this downgrade. Thanks for your help here! |
…curl version (#7615) ### Problem Our CI is broken right now, failing to build `pants.pex` in our Linux shards running CentOS6, e.g. https://travis-ci.org/pantsbuild/pants/jobs/523606246. This appears to be an instance of an upstream rustup development, noted by @Eric-Arellano in rust-lang/rustup#1794 (comment). While there may be a solution which maintains the security that the rustup folks desire, this diff should work around the issue for now. ### Solution - Download the backup script as per rust-lang/rustup#1794 (comment) if the original request fails. ### Result CI should pass!
Looks like Rust in macOS 10.12 is broken with image xcode9.2 (on Travis). 😭 |
If we're using OS X less than 10.13 or any platform where curl or wget fail to advertise the required command line arguments then fall back to not passing the flags to force TLSv1.2 This should fix rust-lang#1794 Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Is this travis-ci error related as well?
https://travis-ci.org/OISF/suricata/jobs/523642627 I believe its using xcode 8.3 |
If we're using OS X less than 10.13 or any platform where curl or wget fail to advertise the required command line arguments then fall back to not passing the flags to force TLSv1.2 This should fix rust-lang#1794 Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
If we're using OS X less than 10.13 or any platform where curl or wget fail to advertise the required command line arguments then fall back to not passing the flags to force TLSv1.2 This should fix rust-lang#1794 Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Problem
curl error when using: curl https://sh.rustup.rs -sSf | sh -s -- -y
Expected (this worked until 4 days ago):
Steps
Possible Solution(s)
N/A
Notes
Output of
rustup --version
: N/AOutput of
rustup show
: N/AThe text was updated successfully, but these errors were encountered: