Any time you install a package (an RPM, deb, .exe, etc.), including from something like yum or apt-get, you are trusting somebody with root access to your system, including the ability to run arbitrary shell commands.

This is something to take seriously; but not something to dismiss as entirely unacceptable. It is generally a manageable, and somewhat quantifiable, risk. This is no different than if the Rust developers provided an RPM or deb package for you to install; the same privileges are being granted to them. Though it is the same thing, it doesn't seem to generate the same concern as the "pipe this file into a shell" method of installation. In fact, one of the folks who responded to you explained that this problem will be gone once rust is packaged for distribution...but that merely means the commands are different, not that rust developers aren't being granted root access to your system.

It is possibly even more suspect, in the case of binary packages, since in the case of the shell script, you could download it, look at it, and then run it. A binary package might have modifications that aren't included in the source distribution, and it would be difficult for a non-expert to spot those differences (and an expert would need to go looking for them, and might miss them).

This is why signed packages are a big deal in the free OS world. At least you know who signed off on your package.

In short, you're right: It's kind of crazy that people grant root access to arbitrary people every time they install software. But, it's the way things are done, for now, so we deal with it and only install stuff from people we perceive to be trustworthy. (i.e. be careful what apt and yum repositories you enable on your systems, and what scripts you pipe into a sudo shell.)

All of that is true. But when I pull a package on Ubuntu or Fedora, it's checked against a key that came with the the system at install time as part of the whole package authentication infrastructure. The root of trust is rather stronger than running the output of some random unencrypted HTTP URL. And the distros recognize that and publish hash values for their install media in lots of obvious places.

This is just a bad habit from the OS X world that needs to die. Really there should be some part of the step that allows a typical user to at least try to manually authenticate the root of trust, via a published hash on a bootstrap package maybe (that's what third party RPM/deb archives do, for example).

it is a https url, the same you use to move funds in your bank... If they provided a rpm/deb package it either would not be signed or you would have to download the public key and the package over https.

In the end is the same level of security, this one at least you can first download the script, read it and then pipe it to bash much more easily than a rpm/deb.

TLS encrypts the transfer. It... sort of authenticates the site (modulo multiple holes that exist in that scheme).

But that just pushes the problem on the user: now the user needs to know affirmatively that "rust-lang.org" is the correct source. And they need to know the same thing about every piece of software they install using this insanity.

That's a rather different situation than simply trusting the install-time keys shipped on your system, which you can authenticate manually (via a public key check against a well-published, historically attestable key) with comparative simplicity.

"the install-time keys shipped on your system" -- given Rust's rapid pace of development, I highly doubt that default packages that are provided e.g., by Debian would be relevant.

To get a reasonably fresh version, you would need to use something like Ubuntu's ppa where you need to trust the ppa's author and TLS, to get you signed packages and the corresponding keys.

"keys + signed package" via TLS from a known (via google) site is more secure than "human readable sh script" via TLS but it is not by leaps and bounds.

Oy vey! No! It's not! HTTPS as commonly implemented is well known to be much more compromisable than the approach of using an actual signed system. In particular, the CA system is.... not good (lots of discussion about this exists).

Having the Debian approach is far better here!

I don't see how comparing an install script you get from somebody with a hash you get from that same somebody gains you an appreciable amount of security. If their server is compromised, you can't trust the hash either. Basically, what you need is a source of trust external to the transaction. If that isn't available and you aren't going to manually review everything, I don't see how this is meaningfully different.

It doesn't give you "perfect" authentication (because nothing does, that's the why the whole root of trust issue is so difficult), but to argue that it isn't appreciably different than literally running the output of curl is just silly.

If I don't trust the hash value I got from the Fedora web site I can ask Google. I can check it vs. the mirrors. I can ask my friend who installed it already to see if it matches her file. I can check the signature on the hash to make sure it matches the key I have stored from my existing install (or the one before that, etc...). That's not perfect but at least it's something.

Yes, but I'm talking about the case where you do trust the hash value just like people who use this method trust rust-lang.org. If you don't trust this software, you could download it and get a hash from somebody you trust as well — in neither case are you forced to do it the easier and less secure way. Obviously a quick install process where you trust the source will be less secure than a laborious process where you carefully inspect the code or obtain and verify multiple hashes via sneakernet. But I'm not convinced that the "secure" easy path where you get a file from somebody and a hash/key from the same source, see that the two match and then run the file is actually more secure in any meaningful way than piping curl into sh. The difference seems to be more in the user's level of caution — this method just lays what you're doing bare rather than burying it under layers of indirection.

But... you can't get a hash from somebody you trust with this scheme. The script downloads and runs and throws itself away with no attempt made to authenticate anything (well, I guess there's the TLS cert as it's a https url -- that's something at least).

Or if it's there somewhere I don't see it. Where it it?

The point is that if you're paranoid, you won't pipe curl into sh just like you won't blindly trust an unauthenticated hash. There is nothing stopping you from putting more effort into installing this software just like there's nothing stopping you from putting more effort into installing an apt package of questionable provenance.

you can also read the bash script before running it... and it is infinitely more secure than just trusting a hash as your friend and the mirrors can be compromised without you being able to notice (and it has happen before).

Er, huh? You're mixing two arguments here. You're talking about the difficulty of authenticating the root of trust (very hard) and trying to use it to address the issue of installing authenticated software (a long-solved problem).

I'm aware of no situations where linux distro mirrors have been compromised with code that will install on live systems. Again, the key is set up on the clients at install time, you can't drop compromised software on them via package install without stealing the signing keys.

The whole point here is that the "run the shell script off hte web" skips the whole root-of-trust issue, and suffers for it. It must stop, guys.

It's completely wrong to equate the security of installing software via curl+pipe to installing signed packages. There are certainly security holes in first-party signed package installation but they pale in comparison the attack surface of curl+pipe.

Systems need to be made more secure and curl+pipe is a step in the wrong direction. It's kind of shocking that attacks are becoming more sophisticated and prevalent but security is becoming more complacent.

> only install stuff from people we perceive to be trustworthy.

Except you can't authenticate the script with curl+pipe, so if someone compromised the server or the communication link it's game over.

I don't believe it is "completely wrong", and I discussed the reason you should prefer signed packages from your OS vendor, though that wasn't my focus.

If you install packages from a third party, and if they are signed, you are generally getting the signing key from the same location. i.e. when the rust developers build packages (as has been suggested will be the solution to this problem), you'll also need to install their signing key. Presumably from the same webserver that is serving you the script that is being judged insecure in this thread.

"Except you can't authenticate the script with curl+pipe, so if someone compromised the server or the communication link it's game over."

s/package and signing key/script with curl+pipe/

The two are not dramatically different if an attacker has taken over the website in question, or if the build/distribution infrastructure has otherwise been compromised, and that was my point.

You could do an sha checksum of the script, and you could obtain the package signing key by meeting up with the developer in person and checking their ID, and you could download the sources, check them thoroughly, and build your own packages, etc., etc. Very few people do that.

There are levels of risk at every stage. It is a difficult problem to distribute software in a safe fashion.

All of that said: I install everything from a package. If it is not from the OS standard repository, I download the source package and build it myself (sometimes checking the source tarball for anomalies and checking the patches to be sure nothing is obviously amiss). I do not enable third party repositories unless I trust them a lot. If no package is available, I make one, and sign it with my own key. If I can't make one, I don't use the software in a deployment (the cost of maintaining a piece of software built from source is way too high).

I was not suggesting the curl+pipe is a good practice. Merely that we live in a world full of compromises. And, insuring you are getting what you think you're getting, and that the person who packaged it had no malicious intent, is a lot harder than merely installing from a package (particularly a package from a source that doesn't have stringent identity requirements...Debian and Fedora packages have a pretty clear ownership trail...most third party packages do not).

Signing keys can easily be distributed out of channel and also verified through a chain of trust. Even if you got a forged key you could, at minimum, detect post-facto that the key was fake.

Moreover, there are things you can build on top of signed packages (distributed consensus of signatures and keys) that can't be built on top of curl+pipe.

curl+pipe is mental.

You're right, and I agree with you. Packages that are signed by a trusted party are a reasonable choice; anything less is not reasonable.

But, lots of people add third party software repositories without out-of-channel confirmation of signing keys, and without any awareness of the risks involved in that. I see it more than most (I support server-side software products with a million or so installations), and I'm amazed at how often third party repos are enabled on people's systems, seemingly without any reason other than "more software is better". They often don't even know why/when they enabled those other repos or who operates them.

That's no different than this curl+pipe scenario.

Yeah third party repos are pretty unreasonable. The problem is that software development now moves pretty fast and package maintainers can't or don't want to keep up. That, coupled with the fact that building packages is far too difficult for most distros incentivizes people to take risks that they shouldn't be taking.

Systems need to be safe by default and they should largely service the needs of users. Distros are no longer doing that.

>They often don't even know why/when they enabled those other repos or who operates them.

Most likely because they either blindly followed instructions from a website or blindly ran an install script from a website, giving it root access. In which case it is basically equivalent to curl + pipe.

This is purely because Rust and Cargo both are not yet stable, and so packaging them for distributions is inappropriate. Once there's a stable release, we will be telling people to use their packaging system and/or official installers rather than the script.

There are various issues filed in the repository if you want to track when this changes.

It's bad, but no different than installing a package supplied by a third party, or using a third-party installer, in terms of what authority you're granting, both of which are fairly commonplace. Obviously the eventual goal is to get something vetted and blessed into a package management system, but that's probably not a reasonable expectation for a brand new project.

Do you really think that's a trend because I've been seeing people complain about it on Hacker News for 3 or 4 years now.

Maybe so, but I've only just started seeing it within the last few weeks. I've been on HN for less than a year so maybe thats why.

Does curl return a partial output if a connection dies?

What if it dies and the last thing it got was "rm - fr /" but not the rest after the / ?

Most shell scripts used like this are implemented by defining a function, then calling it - so if it fails downloading, all that happens is a syntax error as the code never actually gets run.

That's a good point. I filed https://github.com/rust-lang/rust/issues/19168 to get it fixed.

Never thought about this, interesting question.

You can try this equivalent, killing the server when it tells you to - https://gist.github.com/aidanhs/e40417381e9aecb87b35. It prints '/', i.e. would remove your root directory if it was an `rm` command.

Won't be doing that again then.

Remember that these days, with GNU rm, you have to pass in `--no-preserve-root` to actually `rm -rf /`. Attempting to remove something in the home directory and getting a `rm -rf /home/username/` would still be pretty bad.

The chance that the connection dies at exactly this moment is negligible compared to the chance that your hard drive dies. Worry about that.

I used to be an http link some time ago...

What alternative do you propose? You can check the script whether it does something malicious, but then it downloads and installs some binaries.

Some good points from Nate Lawson: https://news.ycombinator.com/item?id=2427492

related discussion: https://news.ycombinator.com/item?id=8553625

Not only that, but the script is useless.

All it does is bullshit of 100 lines or so, but the main part of what it does is

download a tarball, make some temporary directory, and run install.sh

How difficult would those instructions be? Here take a tarball, and you know, unpack it and run install.sh

I guess, too difficult for the audience that Rust developers are targeting with this curl this | sudo bash bullshit.

I don't disagree that that seems simple enough a process to follow, but bear in mind this command is supposed to be run daily. Convenience is definitely a boon.