Radicle 披露网络协议安全漏洞

Radicle 是一个基于 Git 构建的点对点、本地优先代码协作栈。

摘要

发生了什么？

有人报告了 Radicle 节点所使用的网络协议中存在两个严重的安全漏洞。

哪些版本受影响？

迄今为止发布的所有 Radicle 版本均存在此漏洞。

问题是什么？

节点之间的网络流量既没有加密，也没有经过身份认证。通过 Signed References 对仓库内容进行的身份认证仍然能够检测到位于两个节点之间网络路径上的攻击者是否篡改了传输中的对象。因此，主要顾虑是信息泄露，即位于两个节点之间网络路径上的攻击者读取传输中的对象。对于公共仓库而言，信息泄露的顾虑较小。然而，对于私有仓库来说，传输过程中的加密至关重要。

用户应该怎么做？

我们建议在修复版本发布之前停止使用私有仓库。

修复版本何时发布？

由于缺乏版本协商功能，加上该修复在传输层上不兼容，因此向后兼容的缓解措施不可行；这意味着修复该问题的版本将是破坏性变更，从而需要提升主版本号。相关工作正在进行中。通过此次披露，我们首要目标是坦诚清晰地说明现状，以便用户能够评估并相应采取行动，同时我们正在致力于解决方案。

相关漏洞

1. Radicle 使用的网络协议未提供预期的保密性。任何能够观察两个节点之间网络路径的人都能读取他们交换的数据，因为数据是以明文形式发送的。该问题由 Konstantinos Maninakis 于 2026 年 6 月 24 日报告给我们。你可以阅读他关于此问题的博文：https://maninak.com/blog/radicle-cleartext-transport-vulnerability/。我们已向上游报告，请参见此 Issue。
2. 连接握手阶段的对等认证机制存在缺陷，允许冒充攻击。攻击者可以连接到你的节点，并出示一个并非其自身的 Node ID。私有仓库仅与白名单中的 Node ID 共享。如果攻击者伪造了白名单中的 Node ID，他们可以直接拉取私有仓库，而无需位于网络路径上。该问题于 2026-08-12 由 cryptocode 报告给我们。我们已在上游提出了修复方案，参见此 Pull Request。

第二个缺陷虽然听起来严重，但单独利用的难度较大。若要冒充白名单中的 Node ID，攻击者首先必须知道其中一个 Node ID。由于白名单并非公开，不在网络路径上的攻击者只能靠猜测。

在实践中，这两个缺陷同时利用时危害最大：处于路径上的攻击者可以看到连接两端的 Node ID，而这两端通常都在白名单中。 该攻击者在监控期间可以读取交换的任何数据，随后利用观察到的 Node ID 按需拉取整个仓库。 现实中的威胁是位于你的节点与同步节点之间路径上的任何人，没有任何设置或白名单能防御此类攻击。

我们在安全更新可用之前发布此公告。你可以立即采取行动，因为后续发布的任何修复都无法撤销已经发生的泄露。

临时解决方案

• 在安全更新发布之前，停止使用私有仓库（通过网络）。 如下文所述，停止共享（seed）私有仓库。 然而，你可能希望保留存储中的私有仓库，即不要完全删除它们，以便在修复版本发布后可以重新开始共享。
• 请将你通过其他节点传输过的所有私有仓库视为已泄露。 如果其中包含未加密的凭据、密钥或令牌，请立即轮换它们。
• 使用额外的加密传输通道（如 Tor、I2P 或其他覆盖网络或 VPN 解决方案）不足以保护你的数据。 它们只是向两节点间网络路径上的攻击者隐藏了网络流量。 尽管这限制了攻击面，但无法防止对等节点冒充，定向且精密的攻击仍可能导致私有仓库内容泄露。

如何停止共享私有仓库

列出存储中的私有仓库：

rad ls --private --all

将每个仓库的 seed 策略改为 "block"：

rad block <RID>

注意： 如果你的节点 seed 策略设置为 allow，我们建议使用 rad block 而不是 rad unseed。

rad unseed 会移除某个仓库的 seed 策略，节点随后回退到默认策略。 默认策略是 block，所以在默认配置下 rad unseed 就足够了。 但如果你把默认 seed 策略改成了 allow，unseed 之后节点仍会继续提供该仓库。 rad block 则是设置一个显式的 block 规则，节点会优先检查它，所以无论哪种配置都有效。

如果要彻底停止节点：

rad node stop

上述操作的三个局限：

• 它只是让节点不再提供该仓库，并不会删除本地副本。副本仍保留在 $(rad path)/storage/<去掉 rad: 前缀的 RID> 目录下。 只有在你明确知道自己在删除该仓库及其所有 fork 的情况下，才应删除该目录。 如有疑问，不要删除 storage 中的内容。
• 它无法影响已授权节点之前拉取到的副本。这些节点仍持有数据，且同样存在这些缺陷。请让它们也屏蔽该仓库。
• 它无法消除过去的暴露。已经同步到网络上的数据应视为已泄露。

受影响范围

两个缺陷都在节点传输层，与仓库数据模型无关。Git 对象和签名引用仍然像往常一样在存储层进行验证，攻击者无法伪造代码或身份。

机密性缺陷存在于迄今为止发布的所有 Radicle 版本中。

解决方案

我们正在积极开发修复方案。

解决方案是用开源点对点网络协议栈 iroh 替换 Radicle 当前的网络协议（该协议基于 Noise 协议自定义实现）。iroh 建立在开放标准之上。我们此前已分享过迁移计划，此次发现的安全漏洞进一步增强了我们推进迁移的动力。除了修复漏洞，iroh 还引入了 NAT 穿透等额外功能，有助于提升 Radicle 网络的可靠性与韧性。

这种网络传输层的变化在本质上是不向后兼容的。因此，它会导致网络分裂为已升级和未升级两个集群，两者之间无法互通。

尽管这意味着一次重大版本更新，但我们正努力使升级路径尽可能平滑。我们的策略是将兼容性问题集中在网络端，同时保持存储布局的兼容性。

致谢

我们感谢 Konstantinos Maninakis 和 cryptocode 负责任地向我们披露这些漏洞，并保持沟通。

如果您希望报告安全问题，请参阅 https://radicle.dev/.well-known/security.txt。