Gregory's Server@marcan And yet the alternative - to download the script, glance at it without anything really sinking in, then run it - feels better despite being exactly as (in-)secure.
It is, indeed, a very human problem.
|
11 comments
 @marcan @theartlav No, an OS installer is creating a known system not modifying an existing one. (Well short of multiboot which I have Opinions™ about anyway)  @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. @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". @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 @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.) @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. @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. :) |
@theartlav @marcan That alternative is not much better but also unacceptable. No users should be instructed to run privileged scripts from random sources that don't and can't understand the nuances of their system and make unstructured, undocumented, non automatically reversible changes to it. The security aspect is not just "someone may sub in a malicious script when UA is curl". It's "random changes to system break security invariants".