Why curl | sudo bash is good: it is simple single line, and uses the same channel that downloading a repository signing key would.

gistfile1.md

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.

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

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

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.

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?

then why in the world would you give them root access to your machine

Because that developer wrote some good software that I want to use?

It is completely understandable if a single developer in a small project doesn't want to create and maintain packages for deb, rpm, and dozen other package managers various linux systems use. Do you seriously expect everyone to build packages for your MacOS or Arch?

Curl+bash are there in every system. Easy to support, easy to run. If it doesn't work, revert to the last backup (btrfs snapshot and the like) that you should've made beforehand (teachable moment about the value of full-system backups right here).

And if you have any security concerns whatsoever, don't give root access. No matter what it is, dpkg or bash script. Don't run it as system root, run it in a container instead (lxc, docker). Bonus point: if it breaks something, you just lose a container with nothing else in it.

curl | bash should be treated as a warning that a project is very small and doesn't have enough community support (since noone else created 3rd party package yet). Nothing more, nothing less.

curl pipe bash is cool, but there a drawback - I cannot reload PATH and user has to type exec $SHELL by himself.

curl pipe bash is cool, but there a drawback - I cannot reload PATH and user has to type exec $SHELL by himself.

@yaitskov
you could try

curl https://raw.githubusercontent.com/xxx/bin/master/useradd.sh | sudo --preserve-env=SSH_AUTH_SOCK env PATH=$PATH bash -s -- [arg1] [arg2]

How do you uninstall the software after it's shit all over your computer? If you want to reformat every year like some windows pleb sure go ahead use curl | bash, It's not hard to setup a github worker to build various distro packages or ship something on flatpak that actually runs on every OS, instead of just crashing because it can't find the right libraries or a previous install wasn't cleaned up correctly, or it was complied against the wrong glib verison, or worse does rm -rf $HOME because the dev doesn't have nearly the expertise of a fortune 500 company that did the same thing.

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

They make a point of mentioning HSTS in an article about curl, ignoring that curl's default behaviour does not respect HSTS.

If you don't start the URL with https://, and you don't have a mitigation in your ~/.curlrc, then you're still open to MITM attacks.

Why the drive-by? Well I ended up on this page after stumbling into a web page containing bash <(curl -L example.com) and digging into that. They include the -L to respect the redirect that would take the user from the cleartext site over to the TLS site. But by then it's too late. If you're subject to MITM then the attacker won't perform that redirect.

It boggles the mind.

Wow, Sandstorm took the time to write a lovely post trying to defend the indefensible, rather than do something better. I stand by my remarks from 2016.

If you don't start the URL with https://

I haven‘t seen any curl|bash lines that don’t start the URL with https:// so that if condition evaluates to false.

Wow, Sandstorm took the time to write a lovely post trying to defend the indefensible, rather than do something better. I stand by my remarks from 2016.

I fully agree that there are better options, but that doesn’t make your arguments make sense:

1. Just because the transport is over HTTPS doesn't guarantee the content hasn't been maliciously modified on the server.

   Downloading stuff in any way from a server means you trust the server owners. So unless you criticize the praxis of downloading things from various sources instead of a central package repo, this argument doesn’t apply more or less to curl|bash than “download and execute a installer”

2. 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.

   Can you point to one that doesn’t first define a function that does everything and on the last line execute it? Because all of them do.

Don’t get me wrong: I hate how error prone POSIXy shells are, and do think that central package repos are better than “go to https://vendor.org and download their installer”. I’m just saying that curl|bash is in praxis exactly as safe or unsafe as the latter.

I haven‘t seen any curl|bash lines that don’t start the URL with https:// so that if condition evaluates to false.

This one doesn't ¹:
https://zellij.dev/

Can you point to one that doesn’t first define a function that does everything and on the last line execute it? Because all of them do.

This one doesn't:
https://zellij.dev/launch

Not a true Scotsman?

Footnotes

1. The .dev TLD is supposed to be HTTPS-only. Curl doesn't respect that, though. If it did, then there'd be no sense in using the -L command line argument to follow the redirect from the HTTP site. ↩

Well, file a bug report then if it bothers you!

It looks like somebody already tried. Twice.

OK, fine...
zellij-org/zellij-org.github.io#227

But it's your job to rewrite the shell script to wrap everything in a function.

I got curious.

Here's a very rough search query to find vulnerable command lines in GitHub. I included -L in the curl command line switch because I still got heaps of results but less noise. I think -L is so common because it deals with what would normally be a TLS site responding with a redirect -- presumably where people feel the safest doing dumb stuff.

They're not safe, though. Not safe at all.

/\bcurl -[^ ]*L[^:${%]*\|[ a-z]*sh\b/

11k results is more bugs than I'm ever going to file, let alone creating pull requests for the authors to also ignore.

And that's just on GitHub. And I know there are many more than that because I lost quite a few results (including sudo results) trying to reduce the results to be less noisy.

I'm reminded of the Google Hacking Database, which is a collection of search terms where the results reveal sites with specific vulnerabilities. So if you have the tools to apply a particular exploit then you can use Google to tell you all the sites you can attack with it.

And there's nothing to be done about it. Almost everybody in the chain of places where it might be mitigated regards it as somebody else's problem.

It's certainly a remarkable time in which were live right now.

Thanks for doing some current analysis to help make this a data-driven discussion 👍

And there's nothing to be done about it. Almost everybody in the chain of places where it might be mitigated regards it as somebody else's problem.

It's certainly a remarkable time in which were live right now.

Yep, this is exactly why open source software supply chain security is a Hard Problem^tm 😿