F-Droid 源码审查机制：为什么可以放心安装开源应用

F-Droid 的核心假设

F-Droid 的一个核心假设是：源码公开 = 可以被审计。这意味着任何对某个应用有疑虑的人——从普通程序员到安全研究员——都可以：

1. 拿到完整的源代码
2. 通读或自动化扫描代码
3. 检查是否有恶意行为、隐私泄露、隐藏追踪
4. 在社区中公开发现

F-Droid 自己不负责「绝对安全」的背书——但它负责让安全审计成为可能。

提交审核流程

当开发者通过 RFP（Request for Packaging）向 F-Droid 提交一个新应用时：

步骤 1：自动检查

fdroidserver 工具链自动执行：

• 检查应用是否能从源码编译成功
• 检查应用元数据是否完整
• 检查许可证是否合规（必须是 FSF/OSI 认可的开源许可证）
• 扫描是否包含非自由依赖

步骤 2：人工审查

F-Droid 维护者会查看：

• 源代码是否结构清晰（避免混淆代码）
• 权限申请是否合理（和功能匹配）
• 是否有明显的追踪或广告组件
• 构建脚本是否有可疑操作
• 是否引用了已知有问题的库

步骤 3：发布

通过审核后，fdroidserver 将源码拉取到构建服务器，从源码编译 APK，签名发布。

持续审查

应用上架后，审查不是一次性的。每当应用发布新版本，都会重新走一遍编译检查流程。此外：

• F-Droid Monitor（monitor.f-droid.org）持续监控仓库健康状况
• Exodus Privacy 独立分析应用中的追踪器，F-Droid 引用结果作为反特性标注
• 社区可以在 GitLab 和论坛上提交 issue，指出问题

审查的局限性

公平地说，F-Droid 的审查有其边界：

不可能逐行审计 4500+ 应用 — F-Droid 是志愿者项目，人力有限。审查重点在编译通过、许可证合规、明显问题检测，而非逐行代码分析。

混淆代码难以自动化分析 — 如果开发者使用了 ProGuard/R8 混淆，反编译后的代码几乎不可读。F-Droid 会标注这种情况。

运行时行为难以静态分析 — 有些恶意行为只有运行时才表现出来。F-Droid 通过要求公开源码来降低风险，但不能杜绝。

社区驱动的审查

F-Droid 很大程度上依赖社区参与审查：

• 安全研究员可以独立审计应用并发表报告
• 用户可以报告发现的问题
• 维护者之间互相 review 对方的代码
• 可重现构建验证让整个社区可以独立重建 APK

这种「让每个人都能审」的模式，是 F-Droid 安全保障的真正根基——不是说一定不会出问题，而是问题一旦出现就很容易被发现和修复。

与其他应用商店的对比