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