Looking into an apparently scammy looking zsh plugin manager called “zi” | Hacker News Reader

Looking into an apparently scammy looking zsh plugin manager called “zi”

recurse.social

180 pointseffdee40 comments

The project tells people to put a line in their zshrc which fetches and runs a script. To spell out why that's worse than a normal auto-updater would be: it enables the server operators to distinguish users who have installed it in a way where they can serve malware, from users who are downloading it once for inspection purposes. For example, they could serve malware only to IP addresses that have fetched the script every day for a month. Random curious developers and security researchers are very unlikely to do that, but someone who actually put this line in their zshrc would.

This would also explain why it's pointed at the developer's server, rather than a GitHub URL: if it were a GitHub URL, it would be impossible to do malicious substitutions like this.

Nevermind that it's possible to detect server-side if the content is being simply downloaded, or piped into a shell for processing so that you can change the content based on the way it's accessed.

http://web.archive.org/web/20240406132938/https://www.idontp... (archive because HSTS and the cert is expired).

Some time ago I reviewed my usage and dependency on one of the most popular zsh plugin managers, boiled down everything that I needed into a single .zshrc, removed this thing and have never looked back.

The point is: all these zsh kitchen sink projects try to be all-in-one-fits-everyone tools that unfortunately fail this way or another and sometimes are very opinionated. I have to admit they are good for starters and for those who want to delve into the guts of zsh (and shells in gerenal) in order to tailor your own config in the end. But not this one! This looks like hell from all perspectives.

Same for these "lightning fast" bashrc frameworks. I boiled down my main cases into 15 lines in my rc:

https://mstdn.science/@mtekman/111861830339082890

I will get ahead of this since my name is in this Mastodon thread.

- I volunteered to help make the Bash and ZSH logos

- I have nothing to do with "zi", I never heard of that project or the people involved.

Thank you.

Piping curl into sh is bad enough. Piping curl into sh in your rc file is nightmarish. Even with the "verified" version they seem to provide, I can't think of a benevolent explanation for that.

It's just auto-updating. Would be better if it was using the github url directly. Should also be using a method less prone to corruption

It sort of isn't though. You put it there and you don't take it away. You don't put anything else in there to load it. It stops loading entirely if you take out the ethernet cable. That kind of seems like it's loading from the internet every single time. The setup function doesn't add anything to load it without the init script running. That's kind of weird, to me at least.

Oh, I didn't mean to imply it was a good way of doing things, just that the intent was to auto-update. Regardless of how the auto-update works, if a program like this is auto-updating then you're giving arbitrary execution permission to the project.

In Linux there is a package manager for auto-updating.

They suggest to verify a hash of downloaded script which means that after update the script will not be executed. So it just doesn't make sense.

Probably it is an experiment to see how many people will fall for this.

Don't we all do this in our vimrc though with direct links to GitHub plugin repos. PlugUpdate?

This is one of the reasons why I like Lazyvim's plugin spec. It allows you to lock plugins down to the commit/tag/etc.

No?

Well then there is Emacs which is like an entire ripscrip BBS in your terminal if you configure it that way. If the Lisp you hand edit to actually make the plugin start up works you may want to also see what it’s doing apparently. Even though that happens sometimes Emacs is very good at what it does.

No, I absolutely do not do this. For one, I don't have any network requests in my vimrc. I also keep my plugins versioned using an external tool that pulls them from a given git hash rather than request them from some other server.

Clone the plugins you use to a snapshot you trust, and then use the plugins from your trusted forks.

To update, do an upstream merge after comparing the diff

The "verification" downloads the file twice... seems like one could easily make a custom HTTP server to change the second consecutive response to a malicious one.

I am a bit fascinated[1] by the "verified" version, as it fetches from the same URL twice. First I found it inefficient, but since they are doing these request for every zsh startup an extraneous request is probably not seen as a performance problem. Then I realised that the data they verify the hash of is not the same copy of the data that they load: An attacker controlling the server at the curl'ed URL could serve a different file on the second request, which in turn reminded me of a blog post describing how to detect `curl | bash` server side[2][3].

I think the lesson of this small aspect of the "zi" tale is that one should strive to have a single source of truth (a single copy of the data served at the URL), and that in security contexts one needs to be very precise with exactly which guarantees have been established for which data at which point in time: it is surprisingly easy to implicitely add an assumption like "GET requests returning 200 OK behave like pure functions".

[1]: Though this might just be me piling on the mockery of their project, for my own amusement and schadenfreude.

[2]: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b..., alternatively https://web.archive.org/web/20240406132938/https://www.idont..., discussed here e.g. https://news.ycombinator.com/item?id=11532599 (122 comments)

[3]: I am not sure if zsh behaves like bash in this case, as in: Does zsh only read part its input before it starts executing commands?

I get what this post is about, but isn’t it hyperbole to say you can’t think of a benevolent reason when the reason given is auto update/install

I don’t use zsh plugin managers myself, but it looks like zinit already had the ability to update itself. Why on earth replace a working solution with a broken one? Unlike zinit, zi won’t be able to load plugins when the computer is offline for no good legitimate reason that I can possibly think of.

https://web.archive.org/web/20200309073226/https://github.co...

https://archive.is/hmvEh

https://github.com/z-shell/zi?tab=readme-ov-file#%E2%84%B9%E...

Well, it appears they do acknowledge it's a fork at least, but agreed I wouldn't want this on my computer. The toctou issue is ... Bleh.

Another red flag, bought stars. Lots of stargazers that are blank profiles, no contributions or any presence.

.social site seems down or slow

Seems to load fine for me right now

It's a pretty small Mastadon instance and I didn't expect that this would get the attention it has. effdee shared an archive link (https://archive.is/hmvEh) which will work if the server isn't responding well, though our server admin has done some work to try and fix it.

FWIW, I've used zshell for years now and had a great experience. When vetting it against the other zinit fork, it seemed better documented and more active (new features still being added) while the other fork was simply archival. The dev has been extremely responsive whenever I've had issues or questions.

This is all that is in my zshrc:

  # Install Zi if not already installed
  if [[ ! -f $HOME/.zi/bin/zi.zsh ]]; then
    print -P "%F{33} %F{160}Installing (%F{33}z-shell/zi%F{160})…%f"
    command mkdir -p "$HOME/.zi" && command chmod go-rwX "$HOME/.zi"
    command git clone -q --depth=1 --branch "main" https://github.com/z-shell/zi "$HOME/.zi/bin" && \
      print -P "%F{33} %F{34}Installation successful.%f%b" || \
      print -P "%F{160} The clone has failed.%f%b"
  fi

This seems like a bit of an overreaction to someone contributing open source software. Every component of zshell is open (including the website) under the github organization. If they fucked up the checksum version of the download (didn't exist when I started using zshell), submit a PR maybe? As far as the accusation that they're trying to look like official Zsh: the description for the website and repo is literally "A Swiss Army Knife for Zsh - Unix Shell." You cannot miss it.

I don't have a dog in this but this is clearly an overreaction. ss-o has put a lot of time into this and made the best zsh plugin manager imo. Calling it "scammy looking" and "boo hoo he works in marketing" is a cheap blow.

I'll say it's entirely possible this is an overreaction. I was writing up a fun weekend investigation of a weird looking project as I dug into it. There's a reason it's a series of posts on Mastadon and not anything more formal than that.

To clarify one thing, I'm not concerned that they "work in marketing". I am concerned that that the marketing page is fake: it's a bunch of AI generated faces and fake LinkedIn profiles. This does not lead me to the conclusion that they work in marketing at all.

As for your version of the script, it still strikes me as a _little_ weird (why put a self-install inside the .zshrc that is only expected to run once per system you have it on), but clearly far less concerning than the version they have in the current docs.

All code execution involves some degree of trust. There's enough here to make me personally not trust the developer, but if the information here doesn't give someone else the same qualms, that's entirely fine.

It's entirely open source and pretty comprehensible. That being said, of course the dev could tear up years of work and go rogue at any moment, like any other solo open source project dev.

It's not my version of the script, it's what his auto-installer did to my zshrc, which I've retained.

And the purpose of a self-install in the zshrc is twofold: portability to new systems, ie when I moved from macOS to Arch, my zshrc could stay mostly the same, and package management stuff. You may not be familiar with zshell/zinit forks but one can also use them as general package managers (https://wiki.zshell.dev/ecosystem/packages/synopsis) and do pretty cool shim stuff as well (https://wiki.zshell.dev/ecosystem/annexes/bin-gem-node) (https://zdharma-continuum.github.io/zinit/wiki/Annexes/).

I don't think the genuine issues brought up (his new silly way of auto-installing zshell, etc) warrant the reaction this is getting (unixorn taking it off of awesome-zsh-plugins, etc).

> It's entirely open source

Not very reassuring in the context of the xz backdoor and sketchiness of this particular author. I think it's better to avoid it, regardless of whether the author is actually malicious. Giving the vibe of being somehow official and having this fake "company" is rightly criticized. That's not the behavior of the developer whose code I would want to run.

> of course the dev could tear up years of work and go rogue at any moment, like any other solo open source project dev

Given the sketchiness I'd say it's much more likely than with average dev.

Also just discovered this issue was acknowledged by ss-o months ago; it's on his project board here https://github.com/orgs/z-shell/projects/4/views/10

Issue was from last september so he's pretty behind but--accusations of being malicious/scammy are not credible.

A couple weeks ago anyone calling Jia Tan of xz untrustworthy (without having discovered the backdoor) would have been laughed at, but apparently we're in a world where long-time maintainers of open-source projects can be malicious. And here there are even actual ongoing red flags, and multiple of them. There's even an open issue on curl-ing[0], with no action for 6 months (and given that the "verified" version seemingly would fail to load anything at all if the script really updated, it's pushing users to not use it). Even if it's discernible from zsh, similarities can nevertheless provide a feeling of credibility/officiality.

It can of course all be unfortunate accidents (and still has a good chance to be such), but that means nothing - a malicious person would of course try to make all their actions seem as such.

[0]: https://github.com/z-shell/zi/issues/287, though it doesn't notice the double-curl in "verified" being a massive security issue which makes it worse than useless

My only question is... why?, I understand pretending to be something official when you're really not at all so you can profit off the confusion, that trick is a dime a dozen on the internet... but zsh? Really? Surely there are more profitable ventures wearing the skin of a free shell for Unix operating system?

mksh/oksh and simple setup for life.

For instance:

        alias ls='ls -F'

>But Salvydas isn't lying about one thing. He's good at "SEO".

>By which I mean, his project is beating zsh.org itself in my search for "zshell"

Ouch! This is probably the most damning thing in this whole article. If I worked at Google I would hang my head in shame at how lousy Search results have gotten, but I think the staff at Google have been too busy playing in the company ball-pit to care

Not to ruin your villain buzz, but a quick check shows that the same thing (zshell.dev ranks above zsh.org) is true of Bing and DDG also. It's probably closer to a root cause to say that zsh.org appears to be pretty pessimal from a search perspective, like it's being penalized for some reason. ohmyz.sh and the wikipedia page routinely rank at the top.

I have rarely (if ever) seen anyone write "z shell" or "zshell". Maybe in spoken language some people say "z shell", but Google can't search that. Everyone just writes it as "zsh". It's not surprising that another site which uses exactly that word ranks higher – zsh.org barely mentions the word "zshell".

And no one is searching for zshell either: https://trends.google.com/trends/explore?q=zshell,zsh,ksh,cs...

In short, the example is invalid.

That said, my ranking on Google for "zshell" is Oh My Zsh, the Wikipedia article (which is titled "Z shell"), zsh.sourceforge.org, and zshell.dev, in that order. DDG is similar, except the spam site https://zshwiki.org is ranked just before zshell.org ("The Zsh framework can be used to develop LGBT inclusion initiatives [..] One of the first steps in promoting LGBT inclusion is increasing awareness of the issue among porno gay employees").

Yeah, the example was artificial to illustrate that it does come up in search results. I think I noted this later in the thread, but I originally stumbled onto this while specifically searching for some stuff on zprof. I don't recall the exact query I used, since I got pretty deeply sidetracked once I landed here.

This project's docs are way better than zsh.org, that's why. People actually find it informative and use it. Meaning you navigate to it, click around, put it on a side window, and use it while configuring zsh.

It may have better SEO as well, but the main point is that, to rise above the authoritative source, it actually also is performing way better in terms of user metrics.

Reply on news.ycombinator.com