this post was submitted on 09 Jul 2025
27 points (90.9% liked)

Linux

8360 readers
460 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

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

founded 2 years ago
MODERATORS
 

We all know how common terminal one liners have became as a installation method on GNU/Linux and what are the issues with it but let's recap quickly.

You go to a pager of some project and it tells you to do curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs/ | sh or curl -fsSL https://deno.land/install.sh | sh. The only way to verify that this command will not delete all your files or install malware is to manually review the entire script.

So... why not create a secure script repository? On a central website you would create an account for a project and submit a script. On the other side we would provide a binary client that will download and execute the script (we can call it grunt from get and run it). So as a user you would run for example grunt rustup and it would get and execute the script created by rustup project. I imagine it shouldn't be that difficult to add a tiny package to the major distros.

I believe this would be a fairly simple project that would solve all the security issues typical terminal one liners have.

On the website for uploading scripts we could introduce:

  • multi user approval flow for script updates
  • 2FA
  • static checks of the scripts
  • reporting system for compromised scripts
  • verified project status

On the client side we could:

  • provide info about this script's security (how many people reviewed it, when was it last updated, is the project verified)
  • provide info about downloads (how many time was this script downloaded since the last update)
  • do additional checks (maybe the project could provide MD5 of the script on their servers and grunt could verify it?)

So it would look something like this:

# grunt rustp

Downloading rustp.sh from https://getandrun.it/...
Last updated 30 days ago.
Downloads since last update: 5
Verified project: No
Reviewed by 1 user

Execute script [y/N]

Clearly something is wrong...

# grunt rustup

Downloading rustup.sh from https://getandrun.it/...
Last updated 60 days ago.
Downloads since last update: 5342
Verified project: Yes
Reviewed by 3 users
Comparing MD5 checksum with https://rustup.rs/grunt_md5... Passed 

Execute script [y/N]

That's better!

Right? So why don't we have something like this? Or we do and it simply didn't get enough traction?

========

So just to address some of the comments. No, it's not a package manager. Package managers are complex tools that handle versioning, dependencies, updates, uninstalls and so on. Package mangers are also distro specific. A lot of devs decide not to use package managers and use bash scripts that are distro agnostic and don't rely on external maintainers and packagers. It would be ideal if everyone used secure package managers but the reality is they don't. This solution is a compromise that offers devs full control of software distribution while introducing decent security.

=======

Someone suggested brew. How do you install brew according to https://brew.sh/ ?

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

See the problem?

you are viewing a single comment's thread
view the rest of the comments
[–] ExLisper@lemmy.curiana.net 0 points 1 day ago (1 children)
  1. You're talking about difficulty packaging something not adding something to a distro. Standard installations of Ubuntu, Debian, Fedora, Mint and so on include hundreds of packages. Yes, minimal Arch docker image may be a different story but I think the main distros would accept a tiny package that solves security issues. Of course I don't know that but I think it would be worth trying. No one is trying to substitute package manager. It's just a way to make bash installers more secure.

  2. I didn't say that MD5 is enough. I'm saying that it's something tarball providers do to offer a slimmer of security. Because it's well understood that downloading unsigned archive from a webpage is not a secure method of distribution. Bash scripts offer even less security. What I'm describing is a secure method of distributing such scripts.

[–] moonpiedumplings@programming.dev 3 points 1 day ago (1 children)

It’s just a way to make bash installers more secure.

bash installers from the developers, and vendored/pinned dependencies in general will never be secure for the reasons I mentioned above. Developers are bad at security. Developers should not be installing software on people's machines.

[–] ExLisper@lemmy.curiana.net 1 points 1 day ago (1 children)

Well, they are doing it. And they are not using package managers because clearly they don't meet their needs. So we can either give up and keep doing it with 0 security or add some security to it. I don't understand why you treat it as all or nothing problem. It's clearly not. We can't have the perfect solution but we can improve on the current one.

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

don’t understand why you treat it as all or nothing problem. It’s clearly not

There are clear alternatives to using developer install scripts to install software though: package managers

And they are not using package managers because clearly they don’t meet their needs.

Developers incorrectly believe that they need to vendor dependencies or control the way software is installed, which package managers of distros do not offer them. So they don't mention the way that their software (deno, rust) is packaged in nixpkgs, and instead mention the install script. Actually Deno mentions nixpkgs, and Rust mentions apt on their less immediately visible docs, but the first recommendation is to use the install script.

The core problem mentioned here is one of packager control vs developer control. With an install script that downloads a binary (usually vendored) the developer has control over things like: the version of the software, how it is installed, and what libraries it uses. They like this for a variety of reasons, but it often comes to the detriment of user security for the reasons I have mentioned above. Please, please read the blog post about static linking or look into my cargo audit. Developers are not security experts and should not be allowed to install software, even though they want to and continue to do this.

One the other hand, with package maintainers, they value the security of users more than things like getting a new version out. With package maintainers however, they take control over how packages are installed, often using older versions to dodge new security vulnerabilities, at the cost of keeping the same set of non-security related bugs, and sometimes the developers whine about this, like when the Bottles devs tried to get unofficial versions of bottles taken down. Bottles even intentionally broke non-flatpak builds.

But I don't care about developer control. I don't care about the newest version. I don't care about the latest features. I don't care about the non-security bugs not getting ironed out until the next stable release. Developers care about these things.

But I care only about the security of the users. And that means stable release. That means package managers. That means developers not installing software.

[–] ExLisper@lemmy.curiana.net 1 points 1 day ago (1 children)

I get all that. What I don't get is what are you proposing.

For me it's obvious that developers will keep providing bash installers and users will keep running them. Everyone knows it's bad. I see comments about how bad piping scripts from curl to bash is daily yet it's still being done everywhere. What I described is a good compromise: dev can keep using bash but users get some security. Your solution is to keep complaining about it without doing anything to improve security.

Or course proper packages are better. Simply knowing this is not fixing anything.

dev can keep using bash

I don't want "devs to keep using bash". My security problems are with the developer distributions of these softwares themselves, rather than bash. Even if developers offered a rust binary as an installer (or a setup.exe), I would still be miffed and disappointed with them for doing things like vendoring CVE's into their software!

Simply having this discussion brings attention to the issue, and to alternatives for getting packages onto the users machine, thereby increasing their security. There's a reason why it's a hot topic whenever it's brought up.