Recent searches
Search options
@marcan@treehouse.systems @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.
@marcan@treehouse.systems @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".
@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.
@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.
@geofft @marcan@treehouse.systems @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.)
@dalias @marcan @theartlav OK, yes, I buy that argument. It's not a security argument, but I would agree that any project (probably including Asahi) that has a curl|bash installer should also have a documented manual install option, both for pedagogical reasons and for the sake of anyone who wants to adapt the install into some package manager (which I do a lot of :) ).
I think I'd be okay with those docs being inline comments in the script.
@geofft @dalias @marcan@treehouse.systems @theartlav as a tangent, I've been working on Ansible at my day job, not as much to automate ongoing change as to document the actual install process and config for our internal software. A scripted install with comments that works is better than a verbose wiki page which is out of date, skips steps and presumes knowledge or terminology you don't have (eg an instruction to "frobnicate the whatsit in the usual way" is useless if you don't already understand what those are)
@geofft @marcan@treehouse.systems @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.
@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. :)
@geofft @marcan@treehouse.systems @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.
@geofft @marcan@treehouse.systems @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
@dalias @geofft @marcan @theartlav Similar tool based on unshare and overlayfs - https://github.com/binpash/try
It's not supposed to be secure against outrigh malice, but useful in figuring out what build/install script is going to do to filesystem.
You can also get a shell into the temporary "installed" FS to inspect changes.
@cr_mode @dalias @geofft @marcan@treehouse.systems @theartlav wow this is sick
@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!)
@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.
@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.