I hope I'm speaking as a minority but when I first started using Obsidian the Youtube videos I watched encourage the usage of community plugins, even with these warnings I would enable the community plugins. You may very well have good actors that eventually turn bad for these plugins and users won't know.

Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have enabled the community plugin option. Again, hope I'm just the minority here and not most user behaviour.

One thing that bugged me when I made a community plugin was that you have to attach non-git-controlled files to the release (e.g. main.js).

To check if any community plugin is safe, it seems like you'd have to not only review the code on github, but also analyze the github release files to be sure nothing malicious packed in there.

Maybe I'm misunderstanding something about the process, I'd appreciate if anyone could confirm or explain otherwise.

Hopefully this improves workflow for installing plugins offline. It's not bad already but it's not as good as the connected experience.

Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.

Obsidian sounds like a nightmare security wise in general.

You say Trojan.

I say shiny horse statue.

I use the plugin for Git, and the one for tasks. Hope those are safe!

Obsidian does not have auto update for community plugins. The steps for updating them right now is checking for updates and then updating all or individually.

A bad update to one of the popular plugins could compromise lot of systems.

I think it’s fundamentally wrong to base your plugin architecture on running user code in the same space as the application. The proper way is to evaluate plugin scripts in an interpreter running in the application, where you expose functionality through functions and state exposed to the script runtime. This means you can A) sandbox everything and B) check for things like permissions or even request permissions at runtime. It’s harder if you use a language like JavaScript for the application since you essentially have a runtime inside a runtime, but it’s possible to run something like Lua inside JS. Since I use an actually good language like Rust I have many good options for scripting, like Rhai. Lua is also a good option. Go also has multiple options including a couple good Lua libraries. These libraries tend to have performance comparable to Python which is more than enough for most plugins in most apps.

Yet another reason to not install anything third-party made. Favor batteries, built-in functionality and reject “Unix philosophy” or whatever bullshit people use to ship incomplete software under guise of.