Community plugins are great and one of the great features of Obsidian is allowing the ecosystem to thrive. However, community plugins pose a lot of security challenges - even if we trust the developer of a plugin, supply chain insecurities and attacks through dependencies are quite problematic.
Currently, you’d have to check every plugin before installing by hand and continuously monitor changes - and you need to be capable in terms of skill to do so. This has been stated extensively on the plugin help page.
This is why there’s already the safe mode check in the settings in place - but the reputation risk of a widespread data leak through a community plugin will fall back on Obsidian - a “they accepted our ToS and disabled the safe-mode-check” is a bandaid for that at best. I think we can do better.
I suggest to add a developer agreement as a prerequisite for plugins to be listed in the official community plugin list / be accepted in to the Obsidian releases repository. This developer agreement should at the very minimum include:
- the pledge to include automatic security checks for production dependencies through dependabot or a similar product,
- the pledge of the plugin developers to handle security issues within 14 days (either by closing unfitting PRs from dependabot or merging them),
- the pledge to inform Obsidian through a PR to the deprecation-list, if they are unable or unwilling to continue this work in the future, and
- the pledge to continue this support for a grace period of at least 60 days, so that another maintainer can be found or the plugin can be deprecated and delisted
Additionally, a workflow from Obsidian should exist to check the listed community plugins against
npm audit or
yarn audit or utilizing the existing dependabot to automatically add a clearly visible
insecure tag in the plugin list to affected plugins, that have not fixed the security issues within the 14 day window. This could be e.g. done in the obsidian-releases CI pipeline once a day.
Obsidian should also warn any user, if they have installed and enabled an insecure or deprecated plugin.
This measure would
- allow non-technical users to spot and be warned on insecure community plugins
- put pressure on developers to stand by their commitment to fix security issues
- therefore trying to keep their dependency tree small to minize their necessary upkeep time (also has the benefit of smaller plugins and less memory usage)
- while having relatively low upkeep-cost for the Obsidian team through automation