Don't pipe curl/wget a script to a shell without reading what you've downloaded. This should be common sense. Do `wget $url; most install.sh` and only if you're satisfied with what you read, execute `sh install.sh`.
That’s exactly what they are saying.
Maybe I'm too naïve.
Mostly it is the same though shrug. There thankfully don’t seem to be many hackers going after the niche of desktop Linux users.
Of course open source projects rarely sign their exes because those certificates are expensive ($300+/year).
Actually even if the file is correctly signed but is new users will see the warning banners. (Unless using the more expensive EV Code Signing certs)
> Of course open source projects rarely sign their exes because those certificates are expensive ($300+/year).
I'm not sure where the $300/ year comes from but one can get valid certs for less than 50 EUR a year (https://shop.certum.eu/open-source-code-signing-on-simplysig...). I got a physical key one for 65 EUR and it worked just fine.
If the open source project is widely recognizable I'd suggest contacting https://signpath.org/ to get code signing for free (as in beer) via simple Github Action workflow.
Long answer: Windows has a few conventions that make it "better", like a predictable place to install your files, a global authoritative "registry", and never having dynamically linked (and separately installed) dependencies. By sheer virtue of not having a good package manager, Windows has avoided dependency hell. That does, however, still leave it without the utility of a package manager.
Just like security through open source, it's more a nice myth than a reality.
In this case, I assume the reason to inspect the script is not so much that the script might be doing something bad, but rather that you may have downloaded the wrong file to begin with.
With that in mind:
> Distributors usually give you a way to verify that what you've downloaded is correct
The first thing is that not all software is downloaded from Linux distribution repositories. This technique doesn't work if you're just downloading an installer from a website or Github releases page, etc. Sure, many also provide you with a checksum that you need to manually verify, but the shell script in question can also do the same. In fact, it can help by automating the check after it inevitably downloads the application's binary package.
In this case, the vector is you getting something different from what the vendor intended you to download. An example would be if your connection had been MITM'ed and a malicious package had been sent in its place.
This is largely a non-issue these days with TLS certs everywhere, SNI, OCSP stapling and other protections that more or less ensure you're connected to the right server.
> What if you make a typo and somehow pipe an HTML document to your shell?
That's quite the bad luck!
In this case, the user made a typo.
Most `curl | bash` commands are copy-pasted from a website rather than typed out, so this is _mostly_ a non-issue as well.
For those cases where the user typed the command and got it wrong, for it to become a problem, at least these 2 things need to be true:
* the typoed URL actually downloaded something that the shell can interpret
* there are commands in this downloaded document that actually wreak havoc to the system where they ran
Everyone is asleep at the wheel.
It's unrealistic to expect software to never have security holes, bugs, or vulnerabilities. How they're handled matters more than the fact that they were introduced to begin with.
A fair number of upstream developers are unhappy with what maintainers and how they deal with bugs and updates.
The real problem is that software packaging and distribution is so very broken. I had a systems admin say "I love containers, they are a circle of salt around demonically bad software"... He wasnt wrong.
But security!
Basically, if you believe that code signing is a good thing (and I hope we all can agree on that), curl to shell is not great security practice.
Unless you're read to fully analyze all the code and look for problems in the whole code, instead of just the install script, don't be an eager early adopter of every project you see posted somewhere, wait for it to have some social validation, give it sometime so smarter people with more time than us had their time looking for vulnerabilities in the whole code, not only on the script. Or if you really want to check it, use an isolated VM first.
curl -fsSL https://ollama.com/install.sh | sh && ollama run llama3 "Why it is bad to curl | sh?"