Obsidian通过减少对第三方代码的依赖来降低供应链攻击的风险。其设计原则是尽可能从零开始实现功能，避免使用现成库，对于必须使用的库则选择已知安全的版本并严格控制更新。这种策略使Obsidian能够完全掌控代码运行环境，确保应用的安全性和隐私性。

标题：少即是安全：Obsidian如何降低供应链攻击风险

主要内容：

Obsidian通过减少对第三方代码的依赖，有效降低了供应链攻击的风险。供应链攻击是指恶意更新潜入开源代码中，进而影响使用这些代码的应用程序。Obsidian在设计上采取了多种措施，确保为用户提供一个安全、私密的环境。

减少依赖： Obsidian的核心策略是尽量减少对第三方代码的依赖。与其他同类应用相比，Obsidian的依赖项较少。许多功能如Bases和Canvas都是从零开始实现，而不是直接使用现成的库，这使得Obsidian能够完全控制其内部运行的代码。

• 小型实用功能：几乎总是在代码中重新实现。
• 中型模块：如果许可证允许，会将其分叉并保留在代码库中。
• 大型库：如pdf.js、Mermaid和MathJax，仅包含已知良好的、版本锁定的文件，并且仅在必要时或安全修复发布时进行升级。升级前会仔细阅读发布说明，检查上游变更，并进行全面测试。

这种方法使得Obsidian的依赖关系图较为简单，子依赖项较少，从而降低了恶意更新潜入的风险。

实际发布的应用程序： 只有少数几个包（如Electron、CodeMirror、moment.js）是实际发布的应用的一部分。其他包（如esbuild或eslint）仅用于构建应用，不会发布给用户。

版本锁定和锁文件： 所有依赖项都严格锁定版本，并通过锁文件进行管理。锁文件是构建的权威来源，确保安装过程的可重复性，并为审查变更提供了清晰的审计线索。此外，Obsidian不运行安装后脚本，防止包在安装过程中执行任意代码。

缓慢而谨慎的升级： 在进行依赖项升级时，Obsidian会： 1. 逐行阅读依赖项的变更日志。 2. 检查新版本引入的子依赖项。 3. 当变更集较大或风险较高时，进行上游差异比较。 4. 在多个平台和关键用户路径上运行自动化和手动测试。 5. 只有在这些审查通过后，才会提交新的锁文件。

实际上，Obsidian很少更新依赖项，因为它们通常运行良好，不需要频繁更改。每次更新时，都会像引入新依赖项一样谨慎对待。

时间作为缓冲： Obsidian不急于进行升级。在升级任何依赖项和发布新版本之间会有一段延迟。这段时间作为早期预警窗口，社区和安全研究人员通常能迅速发现恶意版本。等到Obsidian准备发布时，生态系统通常已经标记出任何有问题的版本。

总结： 虽然没有单一措施能完全消除供应链风险，但通过选择较少的依赖项、简单的依赖关系图、精确的版本锁定、不运行安装后脚本以及缓慢且审查严格的升级节奏，Obsidian大大降低了受到供应链攻击的可能性，并在代码到达用户之前提供了较长的检测问题的时间窗口。

如需了解更多关于Obsidian的安全策略，请参阅其安全页面和过去的审计报告。

评论主要围绕Obsidian的安全性、依赖管理和插件模型展开，观点分为支持和批评两方。

支持观点： 1. 减少第三方依赖有助于降低供应链攻击风险： - "The primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code."（“减少供应链攻击风险的主要方式是避免依赖第三方代码。”） - "Yes, you are responsible for all the code you ship to your users."（“是的，你对所有交付给用户的代码负责。”）

2. Obsidian的核心功能受到用户喜爱：
   • "I love Obsidian and wish I could make it my default markdown handler on Windows."（“我喜欢Obsidian，希望它能成为我在Windows上的默认Markdown处理器。”）
   • "One of my favorite pieces of software ever."（“这是我最喜欢的软件之一。”）

批评观点： 1. 插件模型存在严重安全隐患： - "Obsidian has a truly terrible security model for plugins."（“Obsidian的插件安全模型非常糟糕。”） - "Obsidian plugins have full, unrestricted access to all files in the vault."（“Obsidian插件对保险库中的所有文件拥有完全、无限制的访问权限。”）

2. 依赖管理问题被忽视：

   • "Does the Obsidian team review all these and who owns them?"（“Obsidian团队是否审查了所有这些依赖，谁拥有它们？”）
   • "Any one of these dependencies can be compromised."（“任何一个依赖都可能被攻破。”）

3. Electron框架的资源消耗和兼容性问题：

   • "Electron has always seemed resource intensive and not native."（“Electron似乎总是资源密集且非原生的。”）
   • "Electron apps don’t play well with Wayland."（“Electron应用在Wayland上表现不佳。”）

总结：Obsidian在减少第三方依赖方面受到认可，但其插件模型的安全性和依赖管理问题引发担忧。同时，Electron框架的资源消耗和兼容性问题也受到批评。