Linux

6466 readers

701 users here now

A community for everything relating to the GNU/Linux operating system

Also check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

276

Am in the only one who cringes at install instructions that require piping some curl output into bash? (programming.dev)

submitted 2 days ago by cschreib@programming.dev to c/linux@programming.dev

157 comments fedilink hide all child comments

curl https://some-url/ | sh

I see this all over the place nowadays, even in communities that, I would think, should be security conscious. How is that safe? What's stopping the downloaded script from wiping my home directory? If you use this, how can you feel comfortable?

I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written. Don't we have something better than "sh" for this? Something with less power to do harm?

you are viewing a single comment's thread
view the rest of the comments

[–] moonpiedumplings@programming.dev 2 points 12 hours ago (1 children)

The non-rolling distros can take a year to update a package, even if they decide to include it.

There is a reason why they do this. For stable release distros, particularly Debian, they refuse to update packages beyond fixing vulnerabilities as part of a way to ensure that the system changes minimally. This means that for example, if a software depends on a library, it will stay working for the lifecycle of a stable release. Sometimes latest isn't the greatest.

Distributions aren’t going to standardize on Arch’s APKBUILD, or Alpine’s almost identical but just slightly different enough to not be compatible PKGBUILD

You swapped PKBUILD and APKBUILD 🙃

I’m starting to think something like a yay that installs into $HOME.

Homebrew, in theory, could do this. But they insist on creating a separate user and installing to that user's home directory

[–] sxan@midwest.social 1 points 8 hours ago

There is a reason why they do this.

Of course. It also prevents people from getting all improvements that aren't security. It's especially bad for software engineers who are developing applications that need on a non-security big fix or new feature. It's fine if all you need is a box that's going to run the same version of some software, sitting forgotten in a closet that gets walled in some day. IMO, it's a crappy system for anything else.

You swapped PKBUILD and APKBUILD 🙃

I did! I've been trying to update packages in both, recently. The similarities are utterly frustrating, as they're almost identical; the biggest difference between Alpine and Arch is the package process. If they were the same format - and they're honestly so close it's absurd - it'd make packager's lives easier.

I may have mentioned I haven't yet started Void, but I expect it to be similarly frustrating: so very, very similar.

I’m starting to think something like a yay that installs into $HOME.

Homebrew, in theory, could do this. But they insist on creating a separate user and installing to that user's home directory

Yeah, I got to thinking about this more after I posted, and it's a horrible idea. It'd guarantee system updates break user installs, and the only way it couldn't were if system installs knew about user installs and also updated those, which would defeat the whole purpose.

So you end up back with containers, or AppImages, Snap, or Flatpack. Although, of all of these, AppImages and podman are the most sane, since Snap and Flatpack are designed to manage system-level software, which isn't much of am issue.

It all drives me back to the realization that the best solution is statically compiled binaries, as produced by Go, Rust, Zig, Nim, V. I'd include C, but the temptation to dynamically link is so ingrained in C - I rarely see really statically linked C projects.