|
Top-level
 @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. 6 comments
@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. :) |
Gregory's Server
@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".