速评：Radicle 9 月 23 号自曝两个漏洞，从第一个版本到最新发布全中。
节点之间传数据明文裸奔，握手阶段还能冒充别人的 Node ID。真正该看的不是"有没有洞"，是这俩洞长在哪儿。
不是数据模型，不是签名那一层。
官方自己交代得很干脆：Git 对象和 signed references 照常在存储层被验证，伪造不了代码，也伪造不了提交。换句话说，砸了最多设计预算的那一层——本地优先、内容可寻址、verifiable——它是对的，这次一点没塌。
塌的是那根管子。
两台节点中间那条线，从头到尾不加密，连身份都没验过。
这个圈子的项目我见得太多了，设计文档最厚的一章永远是验证层，最薄的一章永远是传输层。验证层能上白皮书、能拿去论坛跟人吵三个小时；传输层是水管，水管有什么好聊的。然后出事的永远是水管。你在密码学上做到滴水不漏，只要字节是裸着出村口的，前面全白算。
两个洞单独拉出来看，都还算"难利用"。明文那个，主要风险是泄露——公开仓库泄了也就泄了，私有仓库才是命门。身份冒充那个更绕，攻击者得先知道一个白名单里的 Node ID，而白名单根本不公开，不在路径上的只能靠猜。
组合起来就完全不是一回事了。
坐在你和同步节点之间路径上的任何人，能直接看见连接两端的 Node ID——通常这俩都在白名单里。看完，拿看到的 ID 冒充一下，整个私有仓库按需拉走，连路径位置都不用占。官方在那份披露里的原话挺狠，大意是现实威胁就是路径上的任何人，没有任何设置、任何白名单挡得住。这种话让他们自己说出来，我信。
顺手把那个反射性答案也堵死了：Tor、I2P、VPN 都不够用。它们只能对路径上的攻击者把流量藏起来，挡不住节点冒充。这圈子一碰网络层问题，第一反应永远是"套个 Tor 呗"——这回套了也没用。加密和身份认证是两件独立的事，很多人到今天还当一件办。
缓解措施里有个细节，我觉得比漏洞本身更能说明问题。官方让停掉私有仓库做种的时候，特意点名要用 rad block，别用 rad unseed。理由很实：unseed 只是摘掉这个仓库的做种策略、让节点回落到默认策略，默认确实是 block——可你要是当初手贱把默认改成 allow 了，unseed 完它还在继续供。这种坑不写在文档里根本猜不到。而这一整条建议的前提，是用户得先在自己机器上敲命令，才能把自家产品的核心功能关掉。
私有仓库。现在的官方建议就是：停用，等修复版本。
到这儿我得留一段让步，不然我就成那种看见任何事故都只会说"早说了吧"的货。
这波披露的处理，我给正面。第一个漏洞 6 月 24 号报上来，第二个 8 月 12 号，公开披露是 9 月 23 号——三个月，没拖到补丁那天，也没等来一个能用的补丁。他们选择先公开，理由说得直白：事后发的补丁挽不回已经漏出去的东西，而用户此刻就能动手，轮换密钥、停做种、把每一个曾经走网同步过的私有仓库都当成已泄露。这笔账算得对。行业里更常见的剧本是捂着，等哪天补丁跟着大版本一起发，顺带配一句"我们一贯重视安全"。这剧本，眼熟。Radicle 挑了难受的那条路走。
代价也在那儿摆着：修复方案是把整个网络层换掉。自研的 Noise 协议不要了，换成 iroh，基于开放标准的开源 P2P 网络栈，顺带把 NAT 穿透那些特性带进来。官方说迁移本来是既有计划，这次漏洞只是让他们更坚决。翻译一下——自研传输层这个决定，从根上被否了。
传输层一换