kepano

That would not have been accurate though.

That's effectively how the new system works. We just need to add filters so users can choose their preferred level of strictness.

Huh? The old review process has always been well-documented and occurred via PRs on GitHub completely in the open. It was a known limitation and something that we set out to revamp with the new system.

From the docs:

> The Obsidian team is small and unable to manually review every new release of community plugins. Instead, we rely on the help of the community to identify and report issues with plugins.

https://github.com/obsidianmd/obsidian-help/blob/master/en/E...

An update:

https://obsidian.md/blog/future-of-plugins/

Try Obsidian Web Clipper's Reader feature for Firefox :)

https://obsidian.md/help/web-clipper/reader

You can automatically check for updates but it's off by default, and still requires a manual click. Also the new plugin review system automatically scans every release.

It's the first I am hearing about it, but I'll take a look!

Every update is scanned, and we will be regularly re-scanning all the latest versions of every plugin as we improve the system. The review system is based on our eslint plugin which itself open source and reproducible, so anyone can contribute to improving it: https://github.com/obsidianmd/eslint-plugin

And since plugins are open source, users can also audit the code and flag issues via the Community site.

The app has had light mode since 2020 :)

Obsidian is a small team and I am pretty much the only person working on the website but I hope to add it soon.

Speaking as someone who spends most of his time making open-source software, open source still requires trust. Almost all Obsidian plugins are open source, yet the reason for this new review system is that people don't have the time or ability to vet every line of code of every piece of software. Open source software is only as reliable as the maintenance infrastructure around it. It makes promises that can't be guaranteed about its dependencies, its maintainers, the formats it uses, etc.

See also: https://stephango.com/self-guarantee

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.

That's exactly how it works. A plugin is just a folder that you can copy into the .obsidian/plugins folder within your vault.

That's because Obsidian is black. But we're planning to add light mode in the near future :)

Obsidian CEO here. We've been working for nearly a year to launch this new Community site and review system. I'm very excited about this first version but there are many more improvements to come.

I've tried to be exhaustive with the blog post, FAQs, and next steps on our roadmap, but I am sure I forgot some things, so feel free to ask!

This has been an incredibly challenging project for a number of reasons. We're only seven people but we have thousands of plugin developers and millions of users. There are many competing priorities to balance.

We wanted to make sure the new system would be easy to adopt, backwards compatible, and not completely break people's workflows, while still being a major improvement over the old approach, and allow us to gradually continue enhancing security and discoverability of plugins.

Consider it a work in progress. We're listening to everyone's ideas and gripes, and will keep iterating :)

Yes. That's fixed! There will be some false positives and false negatives as we iron out kinks in the new system, but we're working feverishly in the #plugin-dev channel on Obsidian Discord to help devs. Please be patient, we're only a handful of people working on it :)

We haven't shared anything about sandboxing yet. Yes, to start disclosures will be opt-in because we have to help thousands of developers with existing plugins migrate.

However, a permissions system alone is not enough. For example if a user allows a plugin with network connections, it would be easy for a plugin to abuse that permission. That's why scanning the code is still necessary to give users trust in the plugin.

Take a look at scorecards on the Community site, you'll see why some issues are not something a permissions system or sandboxing could catch.

Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams.

All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch.

The blog post contains details about the rollout, but it will be a phased approach because it requires changes to the plugin API.

No. The attack does not depend on the presence of a specific plugin. The ones listed in the article are just the ones that were used in the POC. Any plugin could be modified by the attacker if the user trusts the attacker and accepts 1. the vault, 2. the shared plugins, 3. disables restricted mode.

I agree. https://news.ycombinator.com/item?id=48097206

It's not one pop-up. To fully replicate the concept you have to agree on three separate screens (and these are not in quick succession):

1. exit restricted mode to allow third-party plugins

2. trust the author of the vault that's being shared with you

3. trust the plugins being shared with you via sync

Obsidian is only seven people but we are working on this from all three angles:

1. Make community plugins less necessary over time as basic features become part of core

2. Improve the security of community plugins

3. Make it easy to create your own plugins that you can fully trust, e.g. with the recent release of Obsidian CLI

You're looking at a different screen than the ones required to replicate this attack. To replicate this attack you have to agree three separate times to increasingly scary messages.

Yes it would be good to make it less easy to shoot yourself in the foot. However, I believe users should be in control. People should be able to do powerful things if they choose to. But that will always come with the risk of misuse or social engineering.

To replicate this attack you have to also reject two more safety warnings. The user has to accept a shared vault (you have to click "trust author of this vault"), and you have to activate syncing remote plugins.

The headline on HN is different: "Obsidian plugin was abused to deploy a remote access trojan". It's not a plugin that was abused, but the ability for shared vaults to contain plugins.

> More batteries-included

Can I ask, what basic functionality is Obsidian missing in 2026? (I work on the app)

Consider a quick search. I have answered this question many times over the years, e.g. https://x.com/kepano/status/1701359669791670416

If you look at my GitHub profile[1] you'll see that the majority of my time is spent on open source. But my priority is open sourcing the tools and libraries I would want if I were building an alternative to Obsidian (Defuddle, JSON Canvas, Web Clipper, Importer, Flexoki, etc) because I believe all software is ephemeral and that files matter more than apps[2].

Obsidian is a free app made by seven people. If we were purely financially-motivated there are many levers we could have pulled, e.g. adding feature gates, not allowing alternatives to our paid services into the official directory, etc. But as I wrote in the tweet linked above, I have spent decades making open source projects and those have never paid the bills. So yes, there is some financial motivation behind that decision.

[1]: https://github.com/kepano

[2]: https://stephango.com/file-over-app

The specific plugins don't matter for this attack. The attack relies on the user accepting a shared vault and trusting the shared plugins. A shared vault can contain plugins that don't come from the official directory.

In the near term artifact attestation will be visible to users in the directory, and part of the overall scorecard of a plugin.

The recommended way to do this is via artifact attestation:

https://docs.github.com/en/actions/how-tos/secure-your-work/...

How would that make a difference for plugin security? Almost all plugins are already open source.

If you mean for the security of the app without plugins you can currently inspect the app's code in app.js and review third-party audits:

https://obsidian.md/security