I have a bunch of projects with plugins and I've sometimes thought about introducing a "reviewed" mechanism where the project marks specific versions as reviewed and trusted.

One of the things that's held me back (aside from the huge time commitment) is my fear that people will come to depend on that review process, such that if the process misses an obfuscated exploit the project itself will be blamed for the subsequent attacks.

How are you thinking about that?

To me it feels like the difference between the Debian/Ubuntu approach - everything in their registry is tightly reviewed - and the PyPI/npm approach where there's no review guarantees at all.

I can't speak for other platforms but neither option you propose seems right for Obsidian. I think the right approach for us is somewhere in between.

If we were too controlling there wouldn't be the freedom of exploration that we see in the Obsidian community. There are so many niche use cases. Plugins can target a minuscule number of users, and that's a great thing. That's why malleability is one of our core principles: https://obsidian.md/about

I also believe in treating users with intelligence. Obsidian has always skewed towards giving you the maximum freedom at the cost of letting you shoot yourself in the foot.

It's impossible to guarantee that software has no bugs and no vulnerabilities, especially not third-party plugins. However that doesn't mean that we shouldn't try to detect dangerous or malicious behaviors. Any transparency we can provide in this regard seems helpful if it can be presented in a way that helps users make their own informed decisions.