Hacker News Reader

Comment by tomp | Hacker News Reader

> Installing software by piping from curl to bash is obviously a bad idea and a knowledgable user will most likely check the content first.

I’ve yet to hear a coherent explanation why this is any worse than installing software from the internet in general. It’s not like you check the source of all software you install.

View on HN

If maintainers of the distro review their accepted packages thoroughly, then apt install would be superior to curl | bash

But 9 out of 10 times I used apt install cargo, I've been bitten by dependency hell

Before SSL certs were as ubiquitous as they are now, we used to warn about the danger of curl to bash for unsecured URLs, as it's a vector for a DNS spoofing attack.

Now that nearly all URLs are HTTPS with valid certificates, the remaining risk seems to be that the host could be intentionally or unintentionally doing something destructive.

Sure it would be great to review the code of every install script before you run it, but as you allude to, it isn't practical.

Maybe something like ChatGPT could help us here?

Main reason I will download and examine instead of blindly run is that often the install script will fail to work as advertised or it will mess up my desired file system conventions. In both cases I'll need to check and perhaps modify the script so it must be bodily downloaded prior to executing. While looking for these problems I also check for obvious malicious instructions.

I guess it's a question of effort on the side of the person doing the trojan - if enough suckers just copy those snippets regularly you can be lazy and just do it like that, you don't need to go through the hassle of creating fake Ubuntu PPAs with trojans or distribute a big repo on GitHub and risk someone seeing the trojan part.

Source in this instance doesn't always mean source code but _the source were you're downloading it from_.

If canonical.com tells me to curl $url | sh, I'm fairly confident the script Im downloading is safe. as much as an .iso, .bin or .exe would be.

But I'd be a lot more hesitant doing the same from craigs-legit-swe-blog.com.

I think its more that the packages are vetted by your distro, but this script isn't, and you don't know what's in it.

Most software I install isn’t distro software, but Python binaries (python, mamba, numpy, pytorch) and packages via pip/mamba/conda.

let’s say some software has 100,000 users. the maintainer goes bad and wants to steal some users’ bank passwords to profit.

if they ship a keylogger to every user, the odds of being noticed before they’re able to cleanly get away are substantially lower than if they ship that to a subset of users. so they may prefer to scam only 100 users, chosen by delivering a malicious payload to only every 1000th curl/https request for the source code. even if one of those users notices, said user will have a tough time confirming and attributing it.

now try doing that with a modern package manager. you can’t, because the package manager ensures every user gets the same code. you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point.

it’s a safety in numbers game. i’m sure you play that game elsewhere in society. i won’t say it’s foolproof, but i’m not sure why it would seem incoherent to you when applied to the digital.

> you can still deliver different experiences at runtime — but you’re not likely to have the superuser privileges needed to run a leylogger or read ~/.ssh/id_rsa, etc, at that point.

Keyloggers are trivial to do in userspace Linux via LD_PRELOAD attacks[0], and typically your user account has permission to read ~/.ssh/id_rsa.

[0] https://github.com/Aishou/wayland-keylogger

Reply on news.ycombinator.com