I am deep in the rabbit hole of looking into an apparently deeply scammy looking zsh plugin manager called "zi".

I think it's an extremely bad idea to use "z-shell/zi" or anything else from the same "creators". There's an entire field of red flags here.

I'll start with its origin: it's apparently a fork of zinit, which was a project created by zdharma (Sebastian Gniazdowski).

I say apparently because the "fork" was created by bulk importing all the original zinit code: https://github.com/z-shell/zi/commit/2f749f9c3f49d872d4d277a450d36d8a6e64ac08.

This happened a few weeks after zdharma disappeared off the internet and deleted all their repos. That makes it a bit less of a red flag—it might be the only way to rescue the code—but rescue forks should still acknowledge they are forks.

zinit code logic · z-shell/zi@2f749f9

✨ A Swiss Army Knife for Zsh - Unix Shell. Contribute to z-shell/zi development by creating an account on GitHub.

GitHub

Making a rescue fork of an abandoned project is normal (e.g. https://github.com/zdharma-continuum/zinit).

You know what's not normal? Creating an organization with the same name as their deleted GitHub username so that anyone who comes to find the old repos finds the projects you now control.

Props for making it look creepy as fuck, though.

GitHub - zdharma-continuum/zinit: 🌻 Flexible and fast ZSH plugin manager

🌻 Flexible and fast ZSH plugin manager. Contribute to zdharma-continuum/zinit development by creating an account on GitHub.

GitHub

That's not their main org though.

Their main org is called...z-shell. This is the first thing that threw me when I stumbled on this—this isn't official zsh docs, but it's all hosted at wiki.zshell.dev, which feels like an attempt to _seem_ official.

Here's the site: https://wiki.zshell.dev/

They're good at throwing together believable looking project websites, so long as you focus on the visuals. Lots of flashy imagery (some of these icons are animated, too) to distract from sentences like "Instant prompt postponing plugins loading to a moment when the processing of .zshrc file is finished."

Oh, it's not a "wiki" in any sense except that I guess you could submit a PR to it on Github, if you were wondering.

Z-Shell

Swiss Army Knife for Zsh Unix shell

The project is a plugin manager for zsh, because that's what zinit was, though they don't make that clear here.

There's a minute long asciinema on the page of the installer script running, which shows that they like flashy colorful outputs but doesn't really give me any impression of the claimed "speed" (https://asciinema.org/a/509113). Why would this be your "see it in action"?

Also their install script starts with "Installing interactive feature-rich plugin manager (z-shell/zi)". Gotta love that.

A Swiss Army Knife for Zsh - Unix shell.

https://github.com/z-shell/zi

asciinema.org

So how do you install this?

Well it's easy, you just...wait, you WHAT?

You um...you add a curl directly to your .zshrc. You're sourcing this from the website _every time you open a shell_.

That's gotta be the slowest possible option, to say nothing about the security concerns.

That page is a redirect to the init script on Github. At the moment. It sure could change.

But if you're concerned about that, they have "verified" installation instructions, and I...I can't even.

Just put a hardcoded checksum in your zshrc and if the script you download doesn't match it, refuse to do anything.

Why wouldn't you just download the current version? Why constantly re-download it on every shell invocation just to check that it's unchanged?

...I can't even

@dylnuge for anyone following along and still not sure why this is so bad (and even the check doesn't save you):

One could code the web server to:
* provide the nice version of the script on someone's first load & on subsequent loads if enough time has passed since the last request (human may in the loop)
* provide the malicious script on the second load if there are two in quick succession or if records show they regularly download via the first formula and aren't paying attention anymore

@dylnuge it's not bulletproof, though—if you launch multiple shells in quick succession, they might give the wrong copy to the download that's checking against the fixed hash by mistake

But since there's no permanent copy kept (if you do it the way they say to), they can always blame bad mirrors or something and "fix" it

@dylnuge at least it's not a sha1sum, which would be really easy to fake into having a valid hash every time while still having the above algorithm to avoid humans tripping over the malicious version
@dylnuge but honestly, you only need to infect a machine once, so once it delivers the malicious payload successfully once, it never needs to do it again

@igrok Very true.

I highly doubt a sophisticated attacker controls this project, but if they did, an essentially undetectable version of an attack here would be to serve a malicious version for a short period of time, and only to known users (e.g. match on IPs based on prior downloads; that matching is easy when legit users download every time they open a shell).

Of course, I also doubt anyone is using the "verified" version of this script, and it's even easier to do this on the "instant" one.

@dylnuge their "verified" snippet has been invalid for some time, so probably not