|
Top-level
@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. 4 comments
 @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
@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.