Installation instructions suggest piping into bash

[BodgeMaster]

curl -o- https://raw.githubusercontent.com/simplex-chat/simplex-chat/stable/install.sh | bash

Please don’t do this. Users should check what commands they are running if they get them from the internet to make sure what they are running isn’t malicious. This bypasses that and some users may actually just run it who would otherwise check what the installation script is doing.

An alternative would be providing a download link to the script directly and having this as a second option or providing individual installation commands if reasonable.

[epoberezkin]

I've heard this argument before, but I genuinely do not see any substantial difference in threat model between downloading a compiled binaries from the repo manually and doing the same via curl -> bash.

Can you please explain?

My thinking about possible decision process here on the users side is very simple here:

1. you trust our code and GitHub compilation process (it runs on Github btw, so any local malware we might have on own machines are irrelevant here) - in this case you can either download our binaries or use curl -> bash, it's just removes a few extra steps. And you can inspect the script in the repo before doing it.
2. you trust our code but do not trust GitHub compilation - in this case you would compile from source – I know many people who do it, and it's very simple too.
3. you don't trust our code - you won't use it at all.

So, what's the difference between direct binary downloads and curl -> bash?

[BodgeMaster]

The difference is that, in my opinion, just having a single command that downloads a script and pipes it into a shell encourages blindly following steps online by shaping people’s habits. Many will not abuse this but someone will.

[BodgeMaster]

Let me add to this, that I don’t advocate for removing it and never piping into a shell again. It would just be great if users thought to themselves "this is the lazy option for software that I trust", not "this is how to install software".

[epoberezkin]

I see... So we want to eradicate the practice... I agree that curl -> bash without trust to code authors is risky at best, but people do lots of risky things, like opening executables in email. No amount of warning to the users stopped it, until email clients and browsers implemented defences and warnings against that to stop users to think whether they understand what they are doing...

So the suggestions to not offering "curl -> bash" is equivalent to the old IT practitioners advice to avoid sending executables in emails as it forms bad habits... This advice never worked, people did it anyway, and the attackers were masking executables as pictures/pdfs. The key was always to verify the identity of the sender and whether you trust them, and even today some email clients don't make it easy...

Unlike email, GitHub has a relatively trustworthy identity system, so you know whose code you are executing most of the time.

Maybe the correct solution to curl -> bash is also on the client side - terminal apps warning users about what they do? Historically, terminal apps were considered a domain of IT professionals, but it definitely changed - lots of users use terminal, and lots of new software developers do not understand the terminal threat model...

What you are suggesting is to remove a convenience without any viable alternative, and I don't think it would have an effect of people not downloading bad scripts – some people would still do it...

[epoberezkin]

this is the lazy option for software that I trust

I love it... Maybe we should write exactly that:

lazy installation*: curl | bash

*never use curl | bash with software you don't trust.

[Krutonium]

A part of the threat model to consider with piping is that the script you see in your browser and the script that gets pulled by curl can be different - It's relatively simple for a webserver to detect the difference, based on something like the script pausing while somthing is executing. I doubt github does this, but it's a reason to avoid teaching users it's a good idea to begin with.

[BodgeMaster]

@epoberezkin Something like the disclaimer in your example above should be enough, in my opinion.

@Krutonium I didn’t even think about it that way but that seems like a significantly more dangerous scenario to me.

I guess the warning could be something like "Never use curl ... | bash commands with software and/or websites you don’t trust."

[epoberezkin]

It's relatively simple for a webserver to detect the difference, based on something like the script pausing while somthing is executing.

I do think the whole script would load first, bash interpreter most likely needs to parse the whole file before it can start executing (I might be wrong here:)... But what's possible to detect indeed is user agent - curl is different from your browser...

[mika-nl]

Maybe it is a idea that people must say y/n to the steps in the script ? So that people can read what steps the script make ?

[BodgeMaster]

@mika-nl That is generally a good idea though it still requires the user to trust the script.

[Krutonium]

It's relatively simple for a webserver to detect the difference, based on something like the script pausing while somthing is executing.

I do think the whole script would load first, bash interpreter most likely needs to parse the whole file before it can start executing (I might be wrong here:)... But what's possible to detect indeed is user agent - curl is different from your browser...

Nope, curl will only download it as fast as the output, and if the output is bash, stdin will block until the current command has finished executing, so a script with a 5 second pause is easy to detect as a direct curl to bash.