Plugin management - security concerns

[wojciech-kulik]

I think there should be some layer of security. Currently, every plugin can run any shell command. The project is in the early stage of development so most plugins have very few stars. It's easy to potentially create something useful and in some sneaky update introduce a malicious code. Users using ya pack -u won't even notice.

I think access to the shell should be limited and accessible through some layer of abstraction.
My second idea is to create an audited repository. Gather trusted maintainers who will be responsible for reviewing "trusted" updates. Otherwise, it doesn't seem to be safe using the ya plugin manager (or am I missing something?)

Any better ideas?

[SolitudeSF]

almost every popular program that has plugins/addons (except browsers) allows running whatever, and everyone is fine.

[wojciech-kulik]

Most plugin managers offer version control where you can disable updates like in Neovim, also you can stick to popular plugins provided by verified sources or recognizable developers. CIs like Bitrise offer a set of verified plugins to make sure that you are safe when using them.

Of course, this is a very small scale, but actually, because of that, it's easier to introduce malicious code. It's easier to introduce something in the repo with 20 stars that nobody is reviewing than in a repo with 2000 stars that is constantly screened by others. Currently, whenever you add a plugin via ya you give unlimited access to your shell to the author.

And no, not everyone is fine: https://medium.com/@bobcristello/millions-at-risk-dangerous-vscode-extensions-uncovered-d4e42e051cb8

almost every popular program that has plugins/addons (except browsers)

You haven't mentioned a single one. I can give you plenty of examples where it's not true and there is either review, closed store, verification, or other forms of prevention or at least differentiation between "verified" and "unverified" plugins.

[SolitudeSF]

You haven't mentioned a single one.

vim, emacs, mpv are popular ones.

the only reason vscode is not fine, is because it has large userbase and large potential attack surface. if the projects i mentioned, which are much more popular than yazi are fine, then yazi will be fine too.

also you can stick to popular plugins provided by verified sources or recognizable developers. CIs like Bitrise offer a set of verified plugins to make sure that you are safe when using them.

these arent the solutions you are proposing here.

you dont even need shell to write a malicious plugin, you have full fs access through yazi api.
and im not against safety, i just cant imagine the solution that would satisfy you and wont be complete cancer for everyone else.

[wojciech-kulik]

I guess the only reasonable solution would be to have a central repo with trusted plugins. A similar approach to Raycast. I think both worlds could co-exist. You choose either verified plugins from the central repo or install whatever from any repo.

However the central repo would require to find some maintainers who are willing to review updates. On the other hand, most of yazi plugins is very small so they shouldn't require a lot of updates and code-review.

[lpnh]

I see the Yazi package manager as a convenience tool, similar to AUR helpers like yay and paru. It simplifies the process of cloning and updating repositories. I don't see why using ya would make this process more or less secure. Plugins are usually created by the community, for the community, so I don't think it's necessarily within Yazi's scope to handle this kind of thing. In my opinion, the user is responsible for the software they install. If you don't trust the source, simply don't install it.

[wojciech-kulik]

Fair point, I guess the problem with ya is that it doesn't support fixed versions. It would be convenient to verify the source code and hardcode the version. However, when there is an update, we could be notified, verify changes and update the version if needed. Or if you trust the source, you can enable auto-update. That's the approach I use in Neovim, plugins that I trust are auto-updated and others have a fixed version set.

[Sonico98]

Fair point, I guess the problem with ya is that it doesn't support fixed versions. It would be convenient to verify the source code and hardcode the version. However, when there is an update, we could be notified, verify changes and update the version if needed. Or if you trust the source, you can enable auto-update. That's the approach I use in Neovim, plugins that I trust are auto-updated and others have a fixed version set.

It does support fixed versions. Append a "=" to the commit number in the package.toml file to prevent the plugin from being updated. Example:

[plugin]
deps = [
	{ use = "MasouShizuka/projects", commit = "=7a1dc37" },
]

[AnirudhG07]

My second idea is to create an audited repository. Gather trusted maintainers who will be responsible for reviewing "trusted" updates. Otherwise, it doesn't seem to be safe using the ya plugin manager (or am I missing something?)

I will take care of this, and review new plugins when added to awesome-yazi, currently I am only adding those which are present in the discord, resources webpage or mentioned here and there by sxyazi, but not present in the webpage. Any random ones I find, I am not adding.
But yes, Ill take care of reviewing the code once before adding anything new.

[AnirudhG07]

but before i actually add it, i would need some confirmation from @sxyazi about going about this for everyone's convenience.

[AnirudhG07]

@Vaisakhkm2625 I have update the repo with a similar format as u mentioned. Currently it only holds the downloading instruction. I am not sure how to go about updating each plugin latest commit.

[Vaisakhkm2625]

@Vaisakhkm2625 I have update the repo with a similar format as u mentioned. Currently it only holds the downloading instruction. I am not sure how to go about updating each plugin latest commit.

Wow, Thanks, that seems to be a lot of work

updating is the tricky part, i can help, if we could get a handful of trust worthy collaborators, we can do it manuvally, i don't think there is any automated way to review this... till then each has hash should be kept same..

edit: 👀 ho you said you just added just a installation instruction,
what i meant is adding a commit hash, cuz any of the extention maintainer can add malware to the extention in the future, like xz incident... so that needed to be done manuvally after reviewing the code for each extention
and user can update to the lastest one in the future if they trust the exntention

[AnirudhG07]

Yes I know, adding a commit hash directly was a long process, and adding it without a fixed plan wouldn't be wise. So just added the downloading instructions for now.
I am very much against doing things manually, cause no one has that much free time to keep updating. If any plugin has a malware, people would anyway report it very soon and it can be removed.

[Vaisakhkm2625]

Yes I know, adding a commit hash directly was a long process, and adding it without a fixed plan wouldn't be wise. So just added the downloading instructions for now. I am very much against doing things manually, cause no one has that much free time to keep updating. If any plugin has a malware, people would anyway report it very soon and it can be removed.

Fair enough :)

[schlich]

I agree with the security concerns and I am glad they are being raised. I agree more that we shouldn't burden development because unnamed people might be careless in their terminal.

Perhaps as a stopgap harm reduction measure, the docs can at least display a warning/disclaimer and link to a page describing a manual method of installation, similar to how projects with shell installers give disclaimers (see uv for example)

[wojciech-kulik]

I see that this repo exists: https://github.com/yazi-rs/plugins

So it looks like this request has been implemented after all.
I guess now the Yazi author reviews each update?