Hacker News Reader

Comment by falsemyrmidon | Hacker News Reader

Piping curl to sh is pretty much always a bad practice.

Have there been any notable incidents where mistrusting a curl | sh was the cause? I hear people say not to do it way more than I hear people talking about actual incidents it's caused.

I mean you really don't wanna run this one

    echo -e "HTTP/1.1 200 OK\r\nContent-Length: 4\r\n\r\nrm /" | nc -l 8080 & curl localhost:8080 | sh

edit: seriously, don't run this, not even if you're curious

it'll just print an error message because / is a directory. There's also a good chance curl starts first and fails to connect to the server that's not running yet.

None. It was always a kind of snobbery against packages too small to be in package managers.

There are reasons curl|sh is a bad way to install things but security isn't one. It's difficult to uninstall, for instance.

One coverage tracker used something like this for recommended CI setup, script was hijacked, users were advised to rotate all credentials available in CI.

I've had a few. Not as security attacks.

More just very badly made install scripts, which (in good faith) destroy some part of my operating system.

Messing up repositories added to package manager, creating dependency conflicts, overwriting config files I used. Even removing full folders - "because it's MINE" syndrome. --dry-run modes that are destructive. A lot of install scripts treat my computer as disposable machine meant for their app only.

Not as bad as giving it your root password which it asks on step 3. Not via sudo or run0, it asks you a password which it saves so it can then use sudo or run0. Uuuh no.

It’s not a good look, but: if you’re installing this, you already trust it with your password, since its UI is the lock screen and the login screen, etc. where you enter your password.

Yeah but I think there's a line between trusting a local app and trusting a remote install script

Reply on news.ycombinator.com