Skip to content

Instantly share code, notes, and snippets.

@btm btm/gist:6700524
Last active Jul 21, 2019

Embed
What would you like to do?
Why curl | sudo bash is good: it is simple single line, and uses the same channel that downloading a repository signing key would.

Easy one line Chef installation for all platforms (except windows)

curl https://www.opscode.com/chef/install.sh | sudo bash

That's it. This can be put in any instructions, such as a README or someone's blog, since the logic is in the shell script. Provided you download the script using https, the file has standard levels of authentication and encryption protecting it from manipulation.

This is obviously a shell script, if you're really concerned about the argument that it may contain nefarious activities within, you can easily review it before you run it.

wget https://www.opscode.com/chef/install.sh 
less install.sh
sudo bash install.sh

More complex alternatives

Without a shell script, you must have a website that selects the correct installation procedure based on platform, platform version, and architecture, because you cannot provide a single binary package that is correct for all of them. Source installs require extensive configuration of a development environment and multiple dependencies.

See the old Chef 10 installation directions for specific examples of the complexity of supporting multiple platforms and versions this way.

Source install:

# multiple steps to install development dependencies, which all vary by platform
sudo apt-get install build-essential ruby ruby-dev rake 
# download the source
wget https://www.somewhere.com/chef/source.tgz
tar -xvzf source.tgz
cd source
rake gem
sudo gem install pkg/chef-*.gem

Binary install for a single platform:

wget https://www.somewhere.com/chef/install-ubuntu-12.04-x86.deb -O /tmp/install.deb
sudo dpkg -i /tmp/install.deb
# or
sudo yum install wget
wget https://www.somewhere.com/chef/install-centos-6-x86.rpm -O /tmp/install.rpm
sudo rpm -Uvh /tmp/install.rpm

But does being in a regular package make you trust it more than a shell script? Most distribution packages contain shell scripts that are run on installation, and they're harder to review than a simple shell script. The required commands differ depending on platform. For example:

dpkg -e /tmp/install.deb /tmp/install.conffiles
less /tmp/install.conffiles/postinst

What about dependencies? Does your platform have all the required dependencies? Are they new enough (no, unless you're on the most recent version). So now you also need to add a repository for all of these platforms to get updated dependencies. All of these are going to need to be backported and maintained for multiple versions by someone.

@jlk

This comment has been minimized.

Copy link

commented May 16, 2016

A distribution package is a versioned item that allows reproducible installs. I would never run a curl-bash pipe on a production system. It depends on your website being up, network connectivity being intact, and most importantly, expects that a shell script somewhere on the Internet hasn't been modified to do something other than originally planned (whether that's install a different version, or something more malicious).

"Source installs require extensive configuration of a development environment and multiple dependencies" is an interesting statement: You'd rather each user go to the trouble of figuring out how to unroll your install script, instead of doing it right yourself in the first place. This is what burns me the most.

@andrewpollock

This comment has been minimized.

Copy link

commented Jun 8, 2016

curl | bash is indefensible. Just because the transport is over HTTPS doesn't guarantee the content hasn't been maliciously modified on the server. It also doesn't guarantee that you won't receive a partial download that happens to stop at some inopportune time and delete your entire filesystem. Just say no.

@ageorgop

This comment has been minimized.

Copy link

commented Oct 7, 2016

This is horrible, apt/yum repositories are at least gpg signed. Spend a few minutes and set up your own apt/yum repo and sign it yourself. It's so easy with tools like aptly. Piping arbitrary shells scripts from the web into a shell with sudo rights is a freaking disease.

@joachimmetz

This comment has been minimized.

@lukehinds

This comment has been minimized.

Copy link

commented Jun 29, 2017

"uses the same channel that downloading a repository signing key would. "

This is so wrong. GPG will raise if anything is wrong with a key based on high strength encryption and alert the user. Just piping a script through bash, coupled with sudo, is giving someone complete control of your machine with no checks in place to know that the infrastructure has not been hacked and the contents of the script replaced. Its irresponsible to even compare the two as the same thing

@monsieurp

This comment has been minimized.

Copy link

commented Jul 18, 2017

I'm afraid I won't use Chef in the foreseeable future.

@jdimpson

This comment has been minimized.

Copy link

commented Feb 1, 2018

curl|bash is bad as much because it encourages new users to develop bad habits than because it is a horrible security risk.

@miglen

This comment has been minimized.

Copy link

commented Jul 29, 2018

A great example why curl | bash is a really bad idea: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/

@AlexSkrypnyk

This comment has been minimized.

Copy link

commented Dec 18, 2018

Good discussion why it makes no difference https://news.ycombinator.com/item?id=12766049

@flying-sheep

This comment has been minimized.

Copy link

commented Jan 22, 2019

If you don’t trust the domain owners to not pwn your shit, don’t download and execute their stuff.

If you do, curl|bash is completely fine. sandstorm explains it well.

if you really just want to download and vet a 100 line (non-installer) script from a shady source, sure, do so. but don’t lie to yourself that you’d vet any real piece of software on your PC.

@stevegt

This comment has been minimized.

Copy link

commented Mar 1, 2019

I have to agree with @jdsimpson: Aside from the other concerns raised here, 'curl | bash' is horrible from a security training standpoint, because it teaches both users and developers some very bad, very lazy habits. I ran across this thread just now in the course of teaching a young person exactly why the 'curl | sudo bash' that they ran yesterday was a bad idea, why they should never give unsigned, untrusted code root access to their machine, and why the bash script in question broke their laptop's network manager when it replaced zlib with a version that was incompatible with other packages provided in the Ubuntu repositories.

Of course, it wasn't obvious at the time what broke the laptop. Discovering and undoing the damage was a stressful waste of my time and hers, other than the teachable moment it provided.

The question to ask yourself is, if the developer didn't have the time, resources, or interest to create a package, sign it, and test it for compatibility with at least the stock set of packages for your distro, then why in the world would you give them root access to your machine?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.