this post was submitted on 19 Feb 2025
289 points (91.9% liked)

Mildly Infuriating

39429 readers
63 users here now

Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.

I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!

It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.


Rules:

1. Be Respectful


Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.

Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.

...


2. No Illegal Content


Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.

That means: -No promoting violence/threats against any individuals

-No CSA content or Revenge Porn

-No sharing private/personal information (Doxxing)

...


3. No Spam


Posting the same post, no matter the intent is against the rules.

-If you have posted content, please refrain from re-posting said content within this community.

-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.

-No posting Scams/Advertisements/Phishing Links/IP Grabbers

-No Bots, Bots will be banned from the community.

...


4. No Porn/ExplicitContent


-Do not post explicit content. Lemmy.World is not the instance for NSFW content.

-Do not post Gore or Shock Content.

...


5. No Enciting Harassment,Brigading, Doxxing or Witch Hunts


-Do not Brigade other Communities

-No calls to action against other communities/users within Lemmy or outside of Lemmy.

-No Witch Hunts against users/communities.

-No content that harasses members within or outside of the community.

...


6. NSFW should be behind NSFW tags.


-Content that is NSFW should be behind NSFW tags.

-Content that might be distressing should be kept behind NSFW tags.

...


7. Content should match the theme of this community.


-Content should be Mildly infuriating.

-The Community !actuallyinfuriating has been born so that's where you should post the big stuff.

...


8. Reposting of Reddit content is permitted, try to credit the OC.


-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.

...

...


Also check out:

Partnered Communities:

1.Lemmy Review

2.Lemmy Be Wholesome

3.Lemmy Shitpost

4.No Stupid Questions

5.You Should Know

6.Credible Defense


Reach out to LillianVS for inclusion on the sidebar.

All communities included on the sidebar are to be made in compliance with the instance rules.

founded 2 years ago
MODERATORS
 

Developers: I will never ever do that, no one should ever do that, and you should be ashamed for guiding people to. I get that you want to make things easy for end users, but at least exercise some bare minimum common sense.

The worst part is that bun is just a single binary, so the install script is bloody pointless.

Bonus mildly infuriating is the mere existence of the .sh TLD.

Edit b/c I'm not going to answer the same goddamned questions 100 times from people who blindly copy/paste the question from StackOverflow into their code/terminal:

WhY iS ThaT woRSe thAn jUst DoWnlOADing a BinAary???

  1. Downloading the compiled binary from the release page (if you don't want to build yourself) has been a way to acquire software since shortly after the dawn of time. You already know what you're getting yourself into
  2. There are SHA256 checksums of each binary file available in each release on Github. You can confirm the binary was not tampered with by comparing a locally computed checksum to the value in the release's checksums file.
  3. Binaries can also be signed (not that signing keys have never leaked, but it's still one step in the chain of trust)
  4. The install script they're telling you to pipe is not hosted on Github. A misconfigured / compromised server can allow a bad actor to tamper with the install script that gets piped directly into your shell. The domain could also lapse and be re-registered by a bad actor to point to a malicious script. Really, there's lots of things that can go wrong with that.

The point is that it is bad practice to just pipe a script to be directly executed in your shell. Developers should not normalize that bad practice.

(page 2) 33 comments
sorted by: hot top controversial new old
[–] [email protected] 15 points 2 months ago* (last edited 2 months ago)

You really should use some sort of package manager that has resistance against supply chain attacks. (Think Linux distros)

You probably aren't going to get yourself in trouble by downloading some binary from Github but keep in mind Github has been used for Malware in the past.

[–] [email protected] 1 points 2 months ago (3 children)

I'm curious, op, do you think it's bad to install tools this way in an automated fashion, such as when developing a composed docker image?

[–] [email protected] 4 points 2 months ago* (last edited 2 months ago) (3 children)

Very much yes

You want to make your Dockerfile be as reproducible as possible. I would pull a specific commit from git and build from source. You can chain together containers in a single Dockerfile so that one container builds the software and the other deploys it.

load more comments (3 replies)
load more comments (2 replies)
[–] [email protected] 0 points 2 months ago (2 children)

I'll die on the hill that curl | bash is fine if you're installing software that self updates - very common for package managers like other comments already illustrated.

If you don't trust the authors, don't install it (duh).

[–] [email protected] 3 points 2 months ago* (last edited 2 months ago)

There was a malicious website on Google pretending to be the brew package manager. It didn't leave any trace but when you ran the command it ran a info stealer and then installed brew.

If this was rare I could understand but it is fairly common.

load more comments (1 replies)
[–] [email protected] 6 points 2 months ago* (last edited 2 months ago)

You are being irrational about this.

You're absolutely correct that it is bad practice, however, 98% of people already follow bad practice out of convenience. All the points you mentioned against "DoWnlOADing a BinAary" are true, but it's simply what people do and already don't care about.

You can offer only your way of installing and people will complain about the inconvenience of it. Especially if there's another similar project that does offer the more convenient way.

The only thing you can rationally recommend is to not make the install script the "recommended" way, and recommend they download the binaries from the source code page and verify checksums. But most people won't care and use the install script anyway.

If the install script were "bloody pointless", it would not exist. Most people don't know their architecture, the script selects it for them. Most people don't know what "adding to path" means, this script does it for them. Most people don't know how to install shell completions, this script does it for them.

You massively overestimate the average competence of software developers and how much they care. Now, a project can try to educate them and lose potential users, or a project can follow user behavior. It's not entirely wrong to follow user behavior and offer the better alternatives to competent people, which this project does. It explains that it's possible and how to download the release from the Github page.

[–] [email protected] 25 points 2 months ago

I've seen a lot of projects doing this lately. Just run this script, I made it so easy!

Please, devs, stop this. There are defined ways to distribute your apps. If it's local provide a binary, or a flatpak or exe. For docker, provide a docker image with well documented environments, ports, and volumes. I do not want arbitrary scripts that set all this up for me, I want the defined ways to do this.

[–] [email protected] 14 points 2 months ago

I'm with you, OP. I'll never blindly do that.

Also, to add to the reasons that's bad:

  • you can put restrictions on a single executable. setuid, SELinux, apparmor, etc.
  • a simple compromise of a Web app altering a hosted text file can fuck you
  • it sets the tone for users making them think executing arbitrary shell commands is safe

I recoil every time I see this. Most of the time I'll inspect the shell script but often if they're doing this, the scripts are convoluted as fuck to support a ton of different *nix systems. So it ends up burning a ton of time when I could've just downloaded and verified the executable and have been done with it already.

[–] [email protected] 6 points 2 months ago (2 children)

I assume your concern is with security, so then whats the difference between running the install script from the internet and downloading a binary from the internet and running it?

[–] [email protected] 8 points 2 months ago (1 children)

To add to OP's concerns, the server can detect if you run curl <URL> | sh rather than just downloading the file, and deliver a malicious payload only in the piped to sh case where no one is viewing it

https://github.com/Stijn-K/curlbash_detect

[–] [email protected] 7 points 2 months ago (1 children)

You're already installing a binary from them, the trust on both the authors and the delivery method is already there.

If you don't trust, then don't install their binaries.

[–] [email protected] 4 points 2 months ago

You aren't just trusting the authors though. You're trusting that no other step in the chain has been tampered with or compromised somehow.

[–] [email protected] 4 points 2 months ago

See post edit. I've already answered that twice.

[–] [email protected] 3 points 2 months ago (1 children)

Can you actually explain what concerns you have, that wouldnt be any more of a concern if you downloaded and installed a binary directly?

At least a shell script you can read in plaintext, a binary can just do who the fuck knows what.

[–] [email protected] 8 points 2 months ago (2 children)

If they expected you to read the install script, they'd tell you to download and run it. It's presented here for lazy people in a "trust me, bro, nothing could ever go wrong" form.

  • There are SHA256 checksums of each binary file available in each release on Github. You can confirm the binary was not tampered with by comparing a locally computed checksum to the value in the release's checksums file.

  • Binaries can also be signed (not that signing keys have never leaked, but it's still one step in the chain of trust)

  • The install script is not hosted on Github. A misconfigured / compromised server can allow a bad actor to tamper with the install script that gets piped directly into your shell. The domain could also lapse and be re-registered by a bad actor to point to a malicious script. Really, there's lots of things that can go wrong with that.

[–] [email protected] 2 points 2 months ago (1 children)

On Github you can look at the CLI to see if the build process looks reasonable.

I would still get packages from a distro though

load more comments (1 replies)
[–] [email protected] 5 points 2 months ago

I've gone through and responded to the other top level comments as well, but another massive issue you could add to your edit is that servers can detect curl <URL> | sh rather than just curl <URL> and deliver a malicious payload only if it's being piped directly to a shell.

There's a proof-of-concept attack showing its efficacy here: https://github.com/Stijn-K/curlbash_detect

[–] [email protected] 27 points 2 months ago* (last edited 2 months ago) (2 children)

Would you prefere

$ curl xyz
$ chmod +x xyz
$ ./xyz

?

[–] [email protected] 37 points 2 months ago (1 children)

You can detect server-side whether curl is piping the script to Bash and running it vs just downloading it, and inject malicious code only in the case no one is viewing it

https://github.com/Stijn-K/curlbash_detect

So that would at least be a minor improvement

[–] [email protected] 9 points 2 months ago* (last edited 2 months ago)

In most cases the script already installs a pre-compiled binary that can be anything, they wouldn't need to make the script itself malicious if they were bad actors.

[–] [email protected] 6 points 2 months ago (1 children)

I mean, how about:

  1. Download the release for your arch from the releases page.
  2. Extract to ~/.local/bin
  3. Run
[–] [email protected] 19 points 2 months ago (1 children)

I think you missed the point.

Why is that safer/better? That binary can do anything a shell script can, and it’s a lot harder to inspect.

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago) (1 children)
  1. That's been the way to acquire software since shortly after the dawn of time. You already know what you're getting yourself into.
  2. There are SHA256 checksums of each binary file available in each release on Github. You can confirm the binary was not tampered with by comparing a locally computed checksum to the value in the release's checksums file.
  3. Binaries can also be signed (not that signing keys have never leaked, but it's still one step in the chain of trust)
  4. The install script is not hosted on Github. A misconfigured / compromised server can allow a bad actor to tamper with the install script that gets piped directly into your shell. The domain could also lapse and be re-registered by a bad actor to point to a malicious script. Really, there's lots of things that can go wrong with that.

The point is that it is bad practice to just pipe a script to be directly executed in your shell. Developers should not normalize that bad practice

[–] [email protected] 10 points 2 months ago (2 children)

If you trust them enough to use their binary, why don't you trust them enough to run their install scripts as well?

[–] [email protected] 5 points 2 months ago (4 children)

How do you know the script hasnt been compromised? Is every user competent enough to evaluate it to ensure its safe to run?

Using package managers to handle this provides a couple things: First: most package manager have builtin mechanisms to ensure the binary is unmodified Second: they provide a third party validating them.

load more comments (4 replies)
load more comments (1 replies)
[–] [email protected] 24 points 2 months ago

I agree but hey at least you can inspect the script before running it, in contrast to every binary installer you're called to download.

[–] [email protected] 106 points 2 months ago (4 children)

It's bad practice to do it, but it makes it especially easy for end users who already trust both the source and the script.

On the flip side, you can also just download the script from the site without piping it directly to bash if you want to review what it's going to do before you run it.

[–] [email protected] 27 points 2 months ago

It's bad practice to do it, but it makes it especially easy for end users who already trust both the source and the script.

You're not wrong but this is what lead to the xz "hack" not to long ago. When it comes to data, trust is a fickle mistress.

load more comments (3 replies)
[–] [email protected] 56 points 2 months ago (13 children)

Installing Rust: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs/ | sh (source)
Installing Homebrew: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" (source)

I understand that you find it infuriating, but it's not something completely uncommon, even in high end projects :/

[–] [email protected] 3 points 2 months ago

Don't forget everyone's favorite massgravel script

[–] [email protected] 13 points 2 months ago (2 children)

Don't forget Pi-hole! It's been the default install method since basically the beginning.

[–] [email protected] 4 points 2 months ago

Yah, when I read this, I was like, pretty sure pi-hole started this as a popular option. I dig it though, so I guess OP and I are not on the same page. (I do usually look over the bash scripts before running them piped to bash, though.

load more comments (1 replies)
[–] [email protected] 28 points 2 months ago

Common or not, it's still fucking awful and the people who promote this nonsense should be ashamed of themselves.

load more comments (10 replies)
load more comments
view more: ‹ prev next ›