@dalias @theartlav So you're opposed to running any...

So you're opposed to running any OS installer? Because that's what all OS installers do.

We actually make *zero* changes to the running macOS other than an online resize of the partition, and all the actions are user-driven (the script doesn't just run off doing stuff, it's interactive). Plus the way platform security is designed on Apple Silicon, different OSes have no privileges over each other (assuming you enable FDE to provide the core isolation), and no machine-level global changes are made at all.

I don't see how you expect an OS installer to work in any other way, short of asking the user to do the installation as a completely manual process.

Like 23 May at 10:57 | Open on social.treehouse.systems

9 comments

Rich Felker

@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)

23 May at 11:01 | Open on hachyderm.io

Hector Martin

@dalias @theartlav Then you're not in fact against our use case, so I rest my case :)

23 May at 11:04 | Open on social.treehouse.systems

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.

23 May at 11:27 | Open on hachyderm.io

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".

23 May at 11:32 | Open on hachyderm.io

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.

23 May at 12:56 | Open on mastodon.social

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.

23 May at 13:02 | Open on mastodon.social

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.)

23 May at 13:32 | Open on hachyderm.io

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.

23 May at 13:29 | Open on hachyderm.io

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. :)

23 May at 13:31 | Open on mastodon.social