Basically another shell scripting language. But unlike most other languages like Csh or Fish, it can compile back to Bash. At the moment I am bit conflicted, but the thing it can compile back to Bash is what is very interesting. I’ll keep an eye on this. But it makes the produced Bash code a bit less readable than a handwritten one, if that is the end goal.
I wish this nonsense of piping a shell script from the internet directly into Bash would stop. It’s a bad idea, because of security concerns. This install.sh script eval and will even run curl itself to download amber and install it from this url
url="https://github.com/Ph0enixKM/${__0_name}/releases/download/${__2_tag}/amber_${os}_${arch}"
…
echo “Please make sure that root user can access /opt directory.”;
And all of this while requiring root access.
I am not a fan of this kind of distribution and installation. Why not provide a normal manual installation process and link to the projects releases page: https://github.com/Ph0enixKM/Amber/releases BTW its a Rust application. So one could build it with Cargo, for those who have it installed.
I wish this nonsense of piping a shell script from the internet directly into Bash would stop. It’s a bad idea, because of security concerns.
I would encourage you to actually think about whether or not this is really true, rather than just parroting what other people say.
See if you can think of an exploit I perform if you pipe my install script to bash, but I can’t do it you download a tarball of my program and run it.
while requiring root access
Again, think of an exploit I can do it you give me root, but I can’t do if you run my program without root.
(Though I agree in this case it is stupid that it has to be installed in /opt; it should definitely install to your home dir like most modern languages - Go, Rust, etc.)
It is also terrible conditioning to pipe stuff to bash because it’s the equivalent of “just execute this .exe, bro”. Sure, right now it’s github, but there are other curl|bash installs that happen on other websites.
Additionally a tar allows one to install a program later with no network access to allow reproducible builds. curl|bash is not repoducible.
But…“just execute this .exe, bro” is generally the alternative to pipe-to-Bash. Have you personally compiled the majority of software running on your devices?
No, it was compiled by the team which maintains my distro’s package repository, and cryptographically verified to have come from them by my package manager. That’s a lot different than downloading some random executables I pulled from a website I’d never heard of before and immediately running them as root.
Yes, I agree package managers are much safer than curl-bash. But do you really only install from your platform’s package manager, and only from its central, vetted repo? Including, say, your browser? Moreover, even if you personally only install pre-vetted software, it’s reasonable for new software to be distributed via a standalone binary or install script prior to being added to the package manager for every platform.
No, I agree that a package manager or app store is indeed safer than either curl-bash or a random binary. But a lot of software is indeed installed via standalone binaries that have not been vetted by package manager teams, and most people don’t use Nix. Even with a package manager like apt, there are still ways to distribute packages that aren’t vetted by the central authority owning the package repo (e.g. for apt, that mechanism is PPAs). And when introducing a new piece of software, it’s a lot easier to distribute to a wide audience by providing a standalone binary or an install script than to get it added to every platform’s package manager.
It is absolutely possible to know as the server serving a bash script if it is being piped into bash or not purely by the timing of the downloaded chunks. A server could halfway through start serving a different file if it detected that it is being run directly. This is not a theoretical situation, by the way, this has been done. At least when downloading the script first you know what you’ll be running. Same for a source tarball. That’s my main gripe with this piping stuff. It assumes you don’t even care about the security.
I mean, you can always just download the script, investigate it yourself, and run it locally. I’d even argue it’s actually better than most installers.
Install scripts are just the Linux versions of installer exes. Hard and annoying to read, probably deviating from standard behaviour, not documenting everything, probably being bound to specific distros and standards without checks, assuming stuff way too many times.
Basically another shell scripting language. But unlike most other languages like Csh or Fish, it can compile back to Bash. At the moment I am bit conflicted, but the thing it can compile back to Bash is what is very interesting. I’ll keep an eye on this. But it makes the produced Bash code a bit less readable than a handwritten one, if that is the end goal.
I wish this nonsense of piping a shell script from the internet directly into Bash would stop. It’s a bad idea, because of security concerns. This install.sh script eval and will even run curl itself to download amber and install it from this url
And all of this while requiring root access.
I am not a fan of this kind of distribution and installation. Why not provide a normal manual installation process and link to the projects releases page: https://github.com/Ph0enixKM/Amber/releases BTW its a Rust application. So one could build it with Cargo, for those who have it installed.
I would encourage you to actually think about whether or not this is really true, rather than just parroting what other people say.
See if you can think of an exploit I perform if you pipe my install script to bash, but I can’t do it you download a tarball of my program and run it.
Again, think of an exploit I can do it you give me root, but I can’t do if you run my program without root.
(Though I agree in this case it is stupid that it has to be installed in
/opt; it should definitely install to your home dir like most modern languages - Go, Rust, etc.)I would encourage you to read up on the issue before thinking they haven’t.
Here is the most sophisticated exploit: Detecting the use of “curl | bash” server side.
It is also terrible conditioning to pipe stuff to bash because it’s the equivalent of “just execute this
.exe, bro”. Sure, right now it’s github, but there are other curl|bash installs that happen on other websites.Additionally a tar allows one to install a program later with no network access to allow reproducible builds. curl|bash is not repoducible.
Anti Commercial-AI license
But…“just execute this
.exe, bro” is generally the alternative to pipe-to-Bash. Have you personally compiled the majority of software running on your devices?No, it was compiled by the team which maintains my distro’s package repository, and cryptographically verified to have come from them by my package manager. That’s a lot different than downloading some random executables I pulled from a website I’d never heard of before and immediately running them as root.
Yes, I agree package managers are much safer than curl-bash. But do you really only install from your platform’s package manager, and only from its central, vetted repo? Including, say, your browser? Moreover, even if you personally only install pre-vetted software, it’s reasonable for new software to be distributed via a standalone binary or install script prior to being added to the package manager for every platform.
Everything you’ve ever needed was available in your distro’s package manager?
Are you seriously comparing installing from a repo or “app store” to downloading a random binary on the web and executing it?
P.S I’ve compiled a lot of stuff using
nix, especially when it’s not in the cache yet or I have to modify the package myself.Anti Commercial-AI license
No, I agree that a package manager or app store is indeed safer than either curl-bash or a random binary. But a lot of software is indeed installed via standalone binaries that have not been vetted by package manager teams, and most people don’t use Nix. Even with a package manager like apt, there are still ways to distribute packages that aren’t vetted by the central authority owning the package repo (e.g. for apt, that mechanism is PPAs). And when introducing a new piece of software, it’s a lot easier to distribute to a wide audience by providing a standalone binary or an install script than to get it added to every platform’s package manager.
It is absolutely possible to know as the server serving a bash script if it is being piped into bash or not purely by the timing of the downloaded chunks. A server could halfway through start serving a different file if it detected that it is being run directly. This is not a theoretical situation, by the way, this has been done. At least when downloading the script first you know what you’ll be running. Same for a source tarball. That’s my main gripe with this piping stuff. It assumes you don’t even care about the security.
That makes the exploit less detectable sure. Not fundamentally less secure though.
Link btw? I have not heard of an actual attack using this.
Whoa, that’s a real bad take there bud. You are completely and utterly wrong.
Convincing rebuttal 😄
deleted by creator
I mean, you can always just download the script, investigate it yourself, and run it locally. I’d even argue it’s actually better than most installers.
Install scripts are just the Linux versions of installer exes. Hard and annoying to read, probably deviating from standard behaviour, not documenting everything, probably being bound to specific distros and standards without checks, assuming stuff way too many times.