177 comments • Comments Link

• Obsidian 团队只有七人。经过近一年的努力，他们推出了新的社区网站和自动化插件审核系统。该系统在设计上兼顾向后兼容，目标是提升这个拥有数千名开发者和数百万用户的庞大生态系统的安全性和可发现性。

• 新的自动化扫描系统基于开源 eslint 插件构建。每当插件更新时都会进行扫描，并会随着系统改进定期重新扫描所有插件。但系统仍在完善阶段，初期难免出现误报和漏报。

• 权限系统计划分阶段上线，需对数千名现有插件开发者进行 API 变更并提供迁移支持。不过仅靠权限不足以解决问题：即便授予了某些权限（例如网络访问），仍需通过代码扫描来检测恶意行为。

• Obsidian 的做法介于严格控制的注册表（如 Debian）和几乎不审核的注册表（如 PyPI/npm）之间，强调用户的自由与判断力，同时承认不可能做到绝对安全，尤其是针对那些面向小众用户群的插件。

• 审核系统依赖自动启发式检查和代码检查器（linter）的警告，以评分卡形式呈现，帮助用户做出更明智的决定，而不是保证绝对安全。团队也理解，在数千个现有插件迁移到新系统的过程中，自我披露在初期将是可选的。

• 尽管审核工具和大多数插件本身都是开源的，但根本挑战在于用户很少亲自审查代码，这使得自动化分析成为必要手段，以缓解因人工审查带来的瓶颈——小团队已经难以应付。

• 有人认为只有通过具备明确 API 与权限检查的沙箱机制，才能真正解决插件安全问题。但目前的 Obsidian 插件运行时没有任何沙箱机制，拥有完整的文件系统和网络访问权限，这使得供应链攻击成为重大隐患。

• 供应链攻击呈上升趋势，表明在实施沙箱机制之前，生态系统可能面临数月的高风险期。另一些人则反驳称，自动化检查可以作为过滤器，标记可疑插件供人工复核，而不是指望其能可靠地检测所有恶意意图。

• 对于如何解读充满 linter 警告的评分卡仍存在实际难题。关于某些标称仅具备特定网络访问权限的插件，如何在更新中通过微妙扩大权限范围来以看似合法的方式窃取数据的问题仍然持续存在。

• 团队规模小且收入有限（估计来自 Sync 订阅的收入约为 250 万美元），这带来了资源分配的疑问。但即便公司停止运营，应用仍可完全离线运行，数据以 markdown 格式保持可移植性。

讨论揭示了一个务实的社区正在努力在促使 Obsidian 插件生态繁荣的自由与日益紧迫的供应链安全之间找到平衡。大多数参与者都承认，没有单一解决方案——无论是自动化扫描、权限、沙箱还是开源审计——能够独自奏效，Obsidian 团队的渐进式做法是在其有限条件下的现实权衡。然而，针对以完全系统访问权限运行、且未沙箱化的 JavaScript 插件的固有脆弱性，部分人预测漏洞的出现几乎不可避免。讨论还提出了更广泛的问题：对大多数用户来说，开源是否真的重要——他们更多基于声誉与便利性而非对代码的验证来信任软件；以及当专有插件在迁移中造成摩擦时，markdown 的可移植性是否足以防止被锁定。 • The Obsidian team, consisting of just seven people, has launched a new Community site and automated plugin review system after nearly a year of work, designed to be backward-compatible while improving security and discoverability for a vast ecosystem of thousands of developers and millions of users.

• The new automated scanning system, built on an open-source eslint plugin, releases every plugin update and will regularly re-scan all plugins as the system improves, though it is acknowledged as a work in progress that will produce some false positives and false negatives initially.

• A permissions system is planned as a phased rollout requiring API changes and migration support for thousands of existing plugin developers, but permissions alone are insufficient since abuse of granted permissions (like network access) still requires code scanning to detect malicious behavior.

• Obsidian's approach positions itself between tightly controlled registries (like Debian) and unreviewed ones (like PyPI/npm), emphasizing user freedom and intelligence while acknowledging that perfect security guarantees are impossible, especially for niche plugins serving very small user bases.

• The review system relies on automated heuristic checks and linter warnings presented as scorecards to help users make informed decisions rather than guaranteeing safety, with the understanding that self-reported disclosures will initially be opt-in as thousands of existing plugins migrate to the new system.

• Despite open-sourcing the review tooling and most plugins themselves, the fundamental challenge remains that users rarely audit code themselves, making automated analysis a necessary scaling solution for a small team overwhelmed by manual review demands that had created a growing bottleneck.

• Some argue that only proper sandboxing with explicit APIs and permission enforcement could truly solve plugin security, but current Obsidian plugins run without any sandboxing at all, having full filesystem and network access, making supply chain attacks a significant concern.

• The escalating pace of supply chain attacks suggests the ecosystem may face challenging months until sandboxing is implemented, though others counter that automated checks need only serve as filters to flag suspicious plugins for manual review rather than reliably detecting all malicious intent itself.

• Practical challenges remain around interpreting scorecards full of linter warnings, and questions persist about how plugins claiming specific network access could subtly expand that scope in updates to exfiltrate data through seemingly legitimate permissions.

• The team's small size and revenue constraints (estimated around $2.5M from Sync subscriptions) raise questions about resource allocation, though the app continues to function fully offline and data remains portable in markdown format even if the company were to cease operations.

The discussion reveals a pragmatic security community grappling with the tension between the freedom that made Obsidian's plugin ecosystem vibrant and the growing urgency of supply chain security. Most participants acknowledge that no single solution (automated scanning, permissions, sandboxing, or open-source auditing) is sufficient alone, and that the Obsidian team's incremental approach represents realistic tradeoffs given their constraints. However, concerns persist about the inherent vulnerability of running unsandboxed JavaScript with full system access, with some predicting inevitable exploits. The conversation also surfaces broader questions about whether open-source status truly matters to most users who trust software based on reputation and convenience rather than verified code, and whether markdown's portability genuinely prevents lock-in when proprietary plugin syntaxes create friction in migration.