Rich Felker
@marcan @theartlav > not just "someone may sub in a malicious script...
Not only is that still relevant, just not usually the biggest problem; validating the curlbash antipattern by copying it, even in a context where it's less dangerous, seems bad too.
Rich Felker
@jpetazzo @puppygirlhornypost Yes, it's basically the difference between trusting one party you chose to mediate these things and make good decisions for you, and N parties who at best are sloppy, if they don't have outright conflicts of interest that disqualify them from making these decisions for you.
Jérôme Petazzoni
@puppygirlhornypost @dalias I agree with you; I'm going to try to rephrase my initial question 😅
Given that virtually all¹ package managers have some way to run arbitrary postinstall scripts (as root!); what makes a deb/rpm/AUR/... better than curl|sh?
My stance is that if I install packages from "core" repos, I'm probably good, because these maintainers usually care *a lot* and to a fantastic job (at least compared to the average dev trying to package their stuff).
But with 3rd party stuff…
Amber
@dalias@hachyderm.io @jpetazzo@hachyderm.io It defeats the purpose of the package manager which is supposed to be the one deciding what goes where. If you are shipping software standalone that is fine, but you should realize that if you want people to use it with systems that rely heavily on a package manager to do the heavy lifting you should focus on your post installation instructions. Not a minified, code golfed shell script that does god knows what. Let people figure out how to package that in their ecosystem (or, maintain your packages if you want strict control of the process) this is how it has been, this is how it should be, and anyone who deviates should be ousted. https://wiki.archlinux.org/title/PKGBUILD we have things like PKGBUILD on arch, we have all these native to a package manager's ecosystem way of doing "post install" scripts. do not just write some posix shell, or python, or perl script that requires a BUILD TIME dependency just to make your shit work.
Why is curl | sh bad? Because it's easy to see if it's curl pulling unless someone bothers to type out user agent flags and so on. Would it be bad practice to curl and then review a script? No. That requires the script to be readable though which most of these curl | sh scripts are absolutely not. I am talking about those horrific thousands of lines posix scripts that have multiple cases, falling through because no adequate testing. https://github.com/valvesoftware/steam-for-linux/issues/3671 do not be that person. it's easier to provide instructions of how to configure the software than to maintain a monolithic script that does everything for them. Not to mention that most of the time these scripts exist to bypass package manager ecosystems. cough https://rustup.rs/
Amber
@dalias@hachyderm.io @jpetazzo@hachyderm.io unironically though, really i want you to realize something. I am going to provide an example of why this is the case, and why we have to rely on things such as fakeroot with proot or what have you to sandbox packaging your apps. https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 WHY? Actually horrific this happened, and impacted a non insignificant amount of people installing bumblebee before NVIDIA wanted to play nice.
Amber
@dalias@hachyderm.io @jpetazzo@hachyderm.io post install scripts are the bane of any package maintainers' existence.
Rich Felker
@jpetazzo My understanding is that the prevalence of tooling for automating deployments to *your own systems* has somehow made people shipping software think they can do the same thing for other people's systems...
That, or they come from Windows-land where the 🤮 professional thing to do is ship installers rather than self-contained zips that you extract and execute in place that don't touch anything outside their dir.
Rich Felker
@jpetazzo "Postinstall scripts" are the same evil as curlbash and should not exist.
There is no excuse for "scripted modification of the user's system". You document what has to be done and either they do that manually, write their own script, or use their trusted distro provider to install it.
Jérôme Petazzoni
@dalias not wanting to be pedantic, but if I build a package (in a sandboxed environment), then install that package, and the postinstall script of the package backdoors my system, how am I being more secure than curl|sh?
(My stance is that curl|sh per se isn't bad; the key thing is to look at provenance: https on a well-known domain with legit-looking URL = good; anything else = beware. And same thing for any package or any artifact in any form. I'm happy to revise said stance tho!)
Geoffrey Thomas
@dalias @marcan @theartlav But there is no such rule! Plenty of projects that are _not_ security clowncars recommend curl|bash for thoughtful reasons. Plenty of projects that are security clowncars ship source tarballs with unreproducible ./configure scripts.
There is a _perception_ that it's bad, yes. I think a respected project using curl|bash is just as likely to to rehabilitate curl|bash and fix that perception, especially if (as here, as Sandstorm did, etc.) they write about why it's okay.
Rich Felker
@geofft @marcan @theartlav curlbash should not be "rehabilitated". It's *always wrong*, just to varying degrees.
Your comparison of "unreproducible configure scripts" doesn't work because the scope of those is such that they run fine in a build sandbox where you discard everything but the build artifacts. curlbash on the other hand is full of commands to install packages, modify config files, etc.
Rich Felker
@marcan @theartlav The flip side is it detracts from your credibility when you do it. Folks know "curlbash bad, projects recommending it are security clowncars" as a rule but don't understand the subtleties to evaluate "well in this instance it's not as bad".
Rich Felker
@geofft @marcan @theartlav The core problem with curlbash is the *philosophy* - presume the user doesn't know how to admin their own system, install deps they need, etc. and ask them to let a script you wrote play admin on their box. (Along with that, it acts as license *not to document* what the user would need to do things themselves.)
Geoffrey Thomas
@dalias @marcan @theartlav One argument in favor of curl|bash: all realistic alternatives - third-party rpm/deb/etc., pip install, building from source, etc. - are just as capable of running arbitrary code but they _look_ less dangerous. curl|bash is honest about its risk and makes people think whether they trust the source.
If a project can use a sandboxed app store or run on a web page, that's meaningfully better, but almost no project considering curl|bash can do that.
Rich Felker
@geofft @marcan @theartlav The sandbox I use for builds is not claimed to be tight against outright intentional malice, but at least against malice that folks shipping software think is them being "helpful". If you want to play with escapes I'd love to hear your results. https://github.com/richfelker/usand
Rich Felker
@geofft @marcan @theartlav The question is not whether users unaware of the risks of curlbash do that.
The question is whether users who are aware of the risks have a viable path to install without reverse engineering the curlbash garbage somebody shipped in place of build/installation instructions.
Geoffrey Thomas
@dalias @marcan @theartlav Do any users who are not aware of the risks of curl|bash run ./configure in a build sandbox?
Also what build sandbox do you use? I would like to try to escape it. :)
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.