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?

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.

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

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? 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://github.com/zdharma-continuum/zinit#upgrade-zinit-and...

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.