This is usually a PoC (Proof of concept) way to install something on a temporary container or temporary VM, but not for production use during daily desktop operation.
I was hoping their documentation would provide better installation instructions. But strangely, only for Windows do they recommend "npm install -g @mimo-ai/cli," which is a much better approach to managing installed packages.
For Mac/Linux, they have the strange recommendation to use the dangerous "curl <some_url> | bash." Quote:
> (for the best experience, Mac users are strongly encouraged to use iTerm or the VSCode Terminal)
> curl -fsSL https://mimo.xiaomi.com/install | bash
This is how everyone does it now. Including Anthropic.
To be fair, is that any different from naively trusting NPM? It's not like NPM is doing any vetting. They're every threat actors favorite sandbox these days.
You're right that it's as dangerous as it's executing random third-party code on your machine, but the method also has propagated far beyond PoCs and such at this point. All of these projects and many others push that install method: Bun, Deno, rustup, k3s, Docker (if using their helper script), Homebrew, Tailscale...
Frankly, it's not really more insecure than any other installation method. Apt packages and the like generally have the ability to specify pre/post-install scripts, so `sudo dpkg -i ./random.deb` is equivalent to `sudo bash ./random.sh`. Even if they didn't have pre/post-install scripts, they're still writing arbitrary files to arbitrary locations on your disk, so they can trigger execution the next time you boot or log in or whatever.
And at the end of the day, no matter the installation method (even just unpacking a tarball and executing the program directly from that directory), you're going to run their program on your computer, and then the program can do whatever it wants. Maybe you don't run it with sudo, but https://xkcd.com/1200/ seems relevant.
A package (like a .deb) is a static artifact. It can be hashed, mirrored, and GPG-signed. Package managers usually verify that signature before any pre/post-install scripts. A "curl <some_url> | bash" pipe is a dynamic stream; the server can perform targeted attacks: sending a clean script to 99% of users and a malicious payload only to a specific IP address or User-Agent. This allows for targeted attacks that are invisible to the rest of the community.
Yes, running third-party code is always a leap of faith, but why choose a delivery method that removes the possibility of verification and opens the door to targeted injections? Convenience shouldn't be an excuse to ignore basic security hygiene.
The problem is that npm, cargo, etc. set the standard in people's minds for how package managers work, when the Linux community has been working on securing the supply chain issues for decades.
Like requiring a WoT (usually with physical meetups) vetting people creating packages, FTP-masters, dedicated clean buildbots, etc. in addition to the packages themselves being signed and so on.
We've had this discussion since Eazel Linux desktop popularized bash | curl in 2001.
> npm install ... is a much better approach to managing installed packages.
No. Until the upcoming version of npm is out, npm will also run arbitrary code. Almost all common installation tools run arbitrary code. Not doing that is sadly the exception for now.
I get what you mean, but an NPM package is just a tarball of arbitrary code and some metadata. The whole point of it is to eventually run that arbitrary code, presumably. Otherwise why would you want to download the tarball and extract it? In fact, what purpose does NPM even serve if it's just a way to host tarballs?
I get the install time and run time execution might feel different, but I don't see how that's a security boundary at all.
I suspect that everyone will just get into the habit of typing --allowScripts all or whatever and nothing will actually change, because there's no point in a version of NPM that doesn't properly set things up for most people.
The code in the module isn’t arbitrary: it’s what the user intended an install, provided the package hasn’t been compromised. I do see your own version though.
Most apps don’t need install scripts so disabling them by default is fine.
This appears to be an LXC-style alternative for macOS; however, unlike native LXC on Linux, this tool relies on VMs. While Docker and Podman also utilize a VM on macOS, they offer the advantage of the Docker Compose format. In my view, the ability to use YAML for declarative configuration is the most critical feature for any container tool. I have nothing against CLI tools in general, but I prefer avoiding repetitive manual commands that could be easily automated via Docker Compose or Kubernetes manifests.
You can't browse the modern web with Presto. I used to work at Opera and we were sad to switch to Chromium/Blink but a company the size of Opera just didn't have the resources to keep up with Google.
That's a nice idea, but I'm hesitant to use automatic installation scripts like this, even if I review them carefully. I prefer manual steps – downloading the file, placing it in the correct directory. Also, I use custom profile directories for my web browsers, so this script wouldn't apply to my setup.
do you carefully review those files you've downloaded and placed into said correct directory, or do you just double click an YOLO your way through the install? at least a bash script allows for you to read it vs a pre-compiled binary installer. either way, you are trusting code created by someone else.
Honestly, I'm reacting a bit against the "YOLO" install culture common on Windows and macOS – just double-clicking and hoping for the best. I specifically use CachyOS, an Arch-based Linux distribution, because it emphasizes a more deliberate, package-managed approach. I prefer relying on the maintainers' work and pre-defined steps within packages whenever possible. It allows me to understand what is being installed and how it's being configured, rather than an all-in-one script potentially making changes I didn't anticipate.
This is usually a PoC (Proof of concept) way to install something on a temporary container or temporary VM, but not for production use during daily desktop operation.
I was hoping their documentation would provide better installation instructions. But strangely, only for Windows do they recommend "npm install -g @mimo-ai/cli," which is a much better approach to managing installed packages.
For Mac/Linux, they have the strange recommendation to use the dangerous "curl <some_url> | bash." Quote:
> (for the best experience, Mac users are strongly encouraged to use iTerm or the VSCode Terminal) > curl -fsSL https://mimo.xiaomi.com/install | bash
:(
reply