this post was submitted on 19 Feb 2025

286 points (92.1% liked)

Mildly Infuriating

36841 readers

1334 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/Explicit

Content

-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

LillianVS@lemmy.world

STRIKINGdebate2@lemmy.world

Tenthrow@lemmy.world

286

When software devs expect you to pipe a script straight from the internet into Bash... (dubvee.org)

submitted 3 days ago* (last edited 3 days ago) by ptz@dubvee.org to c/mildlyinfuriating@lemmy.world

83 comments fedilink hide all child comments

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???

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
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 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

[–] rustymitt@lemmy.world 6 points 3 days ago (4 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?

[–] ptz@dubvee.org 4 points 3 days ago

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

load more comments (3 replies)

[–] pixxelkick@lemmy.world 3 points 3 days ago (4 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.

load more comments (4 replies)

[–] lastweakness@lemmy.world 2 points 3 days ago (6 children)

What's a good package manager right now for stuff like this if i don't want to use the distro package manager though? I want up to date versions of these tools, ideally shipped by the devs themselves, with easy removal and updates. Is there any right now? I think Homebrew is like that? But I wish it didn't need creating an entire new user and worked on a user account basis.

In an ideal world, i would want to use these tools in such a way that I can uninstall them, including any tool data (cache, config, etc), and update them in a reliable manner. Most of these tools are also hellbent on creating a new "." folder or file in the home folder ignoring the XDG spec.

[–] fraksken@infosec.pub 3 points 3 days ago (1 children)

It says in the comment of the script:

npm install

[–] lastweakness@lemmy.world 3 points 3 days ago

npm is JS-specific

[–] corsicanguppy@lemmy.ca -4 points 3 days ago (1 children)

if i don't want to use the distro package manager

I'm stunned you don't understand why this is a problem.

This was absolutely trivial stuff before the great Y2K layoffs, so if you can't figure it out, ask someone who was releasing software professionally back then.

And please, if you learn something from this, try to help others.

[–] lastweakness@lemmy.world 2 points 3 days ago

I don't want to use a distro package manager for certain software because nearly every distro except Arch requires adding third party repositories which can stop getting updates at any second.

Don't worry, I understand the intricacies of these problems a lot more deeply than you probably realise. As a developer, it can suck when your "hotfix" cools down by the time a distro gets around to packaging it. And as a packager, you're human in the end. As a user though, you just want stuff to work.

As a longtime Linux user, this isn't really a problem for me, none of this is. But what about a new user? We need to address these issues at some point if we want Linux to be truly user-friendly.

load more comments (4 replies)

[–] IceFoxX@lemm.ee 1 points 3 days ago

4.Since MS bought github, github is no longer trustworthy. Databreaches etc have increased since MS owns github. Distribution of malware via github as well. What is the 4 point supposed to say?

[–] TrickDacy@lemmy.world 1 points 3 days ago (2 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?

[–] possiblylinux127@lemmy.zip 4 points 3 days ago* (last edited 3 days ago) (1 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.

[–] TrickDacy@lemmy.world 1 points 3 days ago (2 children)

I mean, you're not op. But your method requires all updates to be manual, while some of us especially want updates to be as automated as possible.

[–] moonpiedumplings@programming.dev 1 points 3 days ago

You can use things like dependabot or renovate to update versions in a controlled manner, rather than automatically using the latest of everything.

On the other side, when it comes to docker containers, you can use github actions or some other CI/CD system to automate the container build.

[–] possiblylinux127@lemmy.zip 2 points 3 days ago

I don't think it is that hard to automate a container build. Ideally you should be using the official OCI image or some sort of package repo that was been properly secured.

[–] Moonrise2473@feddit.it 2 points 3 days ago (1 children)

Protect from accidental data damage: for example the dev might have accidentally pushed an untested change where there's a space in the path

rm -rf / ~/.thatappconfig/locatedinhome/nothin.config

a single typo that will wipe the whole drive instead of just the app config (yes, it happened, I remember clearly more a decade ago there was a commit on GitHub with lots of snarky comments on a script with such a typo)

Also: malicious developers that will befriend the honest dev in order to sneak an exploit.

Those scripts need to be universal, so there are hundreds of lines checking the Linux distro and what tools are installed, and ask the user to install them with a package manager. They require hours and hours of testing with multiple distros and they aren't easy to understand too... isn't it better to use that time to simply write a clear documentation how to install it?

Like: "this app requires to have x, y and z preinstalled. [Instructions to install said tools on various distros], then copy it in said subdirectory and create config in ~/.ofcourseinhome/"

It's also easier for the user to uninstall it, as they can follow the steps in reverse

[–] TrickDacy@lemmy.world 1 points 3 days ago

Yes I understand all of that, but also in the context of my docker containers I wouldn't be losing any data that isn't reproducible

[–] badbytes@lemmy.world -1 points 2 days ago

I wouldn't call anyone who does this, a developer. No offense, but its a horrible practice, that usually come from hacky projects.

[–] eager_eagle@lemmy.world 0 points 3 days 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).

[–] moonpiedumplings@programming.dev 2 points 3 days ago

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

Just because I trust the authors to write good rust/javascript/etc code, doesn't mean I trust them to write good bash, especially given how many footguns bash has.

Steam once deleted a users home directory.

But: I do agree with you. I think curl | bash is reasonable for package managers like nix or brew. And then once those are installed, it's better to get software like the Bun OP mentions from them, rather than from curl | bash.

[–] possiblylinux127@lemmy.zip 3 points 3 days ago* (last edited 3 days 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