[ChuckNorris89]

>Yeah, let's teach users to paste sudo commands into the terminal. That's great.

This is also one of my fears with pushing non tech savvy people away from Apple/Windows and onto Linux without the Snap, Flathub, or other such curated stores that ship with the distro, without which they would need to touch the terminal and run commands found on the internet.

GNU/Geeks will keep shouting religiously how insecure Windows is because "grandma can download a dodgy .exe pretending to be a game and get viruses", but on Linux it's the same shit or worse, all you have to do is to convince a user new to Linux to paste and run a sudo command in the terminal as instructed by some scammy tutorial he found on Youtube when searching for "how to install Fortnite on Linux" and it's game over for him, since Youtube removed the downvote counter and the user had no idea he was running into a trap.

After all, for most Average Joes, copying some text feels far less dangerous than downloading and opening a strange file.

At least Windows Defender will most likely catch that malware you downloaded and warn you about it being harmful, but on Linux you have no such guardian nanny to save you. With sudo, it will do whatever self-destructive thing you tell it to do and not complain.

[marginalia_nu]

I've seen this extremely sketchy variant a few times

  curl -sfL www.marginalia.nu/install.sh | sudo sh -

Even without sudo, this is extremely sketchy.

[rosnd]

Is it meaningfully sketchier than downloading a .deb and calling dpkg -i on it?

Or cloning a git repo and building it?

[marginalia_nu]

The difference is that the stream coming out of curl and entering sh is ephemeral. With this device, there is no checksum or signature (as with apt). If you pipe curl into sh, you also leave no trail of what you've run. A malicious actor can also hinder analysis by serving different payloads per user-agent, per time of day, per subnet; or only serving the malicious payload intermittently.

With .deb-files you're expected to verify the checksum. Maybe you don't, and even if you don't, you can theoretically go back and verify after as part of a forensic process. This checksum is also typically distributed across different mirrors, making bait-and-switch attacks difficult. It means that if you're going to do a supply chain attack, you must do it in the open.

Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.

[rosnd]

>Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.

Is it really meaningfully easier to analyse? I get that it feels better, but I'd bet that the people saying this would fail to catch the backdoor every time.

[jdiff]

Yeah, it's possible for a web server to detect and change the returned data maliciously. Even with user agent and all other factors changed to match, it's possible to detect even the difference between being piped into another command vs being redirected to a file.

[rosnd]

It's also possible for a web server to selectively serve you a backdoored .deb or git repo

[electromech]

It helps that Signal uses an HTTPS apt repo and includes "signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg" in the apt list entry. If their download server were compromised, (and assuming the hacker didn't also get the private gpg key) the attacker would have to provide malicious archives selectively to avoid detection. Anyone who installed the old key (e.g., me) would notice the key validation errors.

[drran]

So what? I can inspect downloaded code and find the backdoor, or a trojan, or an error. I did it few times already in last 30 years. If you cannot do that doesn't mean that nobody can. But I cannot do that with `curl | bash`.

[rosnd]

If you can't save the output of curl into a file, you certainly aren't one of the few people capable of meaningfully inspecting anything you download.