Radicle 披露了其 wire protocol 中的两个严重安全漏洞：攻击者可能读取私有仓库的明文数据，并冒充合法节点。问题影响所有节点版本，而且根源位于协议架构，而不是某个可以快速打补丁的实现细节。因此，单纯升级现有版本并不足以恢复安全边界，当前更重要的动作是停止 clearnet 运行、保存调查证据，并准备迁移到新的 Iroh 协议。
为什么这不是一次普通的版本升级
这次事件同时破坏了两个关键安全属性。
- 机密性失效：原本应当保持私有的仓库内容可能通过网络协议以明文形式暴露。
- 节点身份失效：攻击者能够冒充节点，节点名称、连接状态或表面上的身份信息不再足以证明对端可信。
当问题发生在协议设计层时，即使传输进程仍然正常、同步结果看起来也没有异常，也不能据此判断连接安全。继续让节点暴露在公网，会延长数据可能被读取或节点被冒充的时间窗口。
团队应采取偏保守的事件响应假设：凡是在受影响节点通过 clearnet 可达期间同步、托管或缓存过的私有仓库，都应被列入潜在暴露范围。这个假设不等于确认数据已经泄露，但能避免因缺少日志或攻击痕迹而过早排除风险。
先隔离，而不是继续观察
首要目标是切断受影响节点的公网通信。不要为了等待正式迁移工具而保持服务在线，也不要把“尚未发现异常访问”当作继续运行的理由。
如果节点由 systemd 用户服务管理，可以这样停止。运行前将 SERVICE 改成机器上的真实服务名：
#!/usr/bin/env bash
set -euo pipefail
SERVICE="radicle-node.service"
# 先记录服务状态，供后续调查使用。
systemctl --user status "$SERVICE" --no-pager > radicle-service-status.txt || true
journalctl --user -u "$SERVICE" --since "7 days ago" --no-pager \
> radicle-service-journal.txt || true
# 停止服务并取消自动启动。
systemctl --user stop "$SERVICE"
systemctl --user disable "$SERVICE"
# 验证服务已停止，同时检查是否还有相关进程和监听端口。
systemctl --user is-active "$SERVICE" || true
pgrep -af 'radicle|rad' || true
ss -lntup
# 为导出的调查材料生成校验值。
sha256sum radicle-service-status.txt radicle-service-journal.txt \
> radicle-evidence.sha256
如果服务运行在容器中，可先暂停容器，确认数据卷位置后再决定是否停止或移除：
# 将容器名改成实际名称。
CONTAINER="radicle-node"
docker inspect "$CONTAINER" > radicle-container-inspect.json
docker logs --timestamps "$CONTAINER" > radicle-container.log 2>&1 || true
docker pause "$CONTAINER"
docker ps --filter "name=$CONTAINER"
sha256sum radicle-container-inspect.json radicle-container.log \
> radicle-container-evidence.sha256
docker pause 只是临时遏制措施，主机重启或编排平台重新调度仍可能恢复服务。还应同步关闭自动重启策略、外部负载均衡入口和云防火墙规则。若无法马上停机，至少应把节点限制在经过控制的隔离网络内；但 VPN 或私网并不能修复协议缺陷，只能缩小攻击面。
调查范围不能只看仓库提交记录
协议漏洞造成的访问不一定会留下 Git 提交，也不一定修改仓库内容。因此，仅检查 git log 无法证明数据没有被读取。
事件调查至少应覆盖以下材料：
- 节点在受影响期间监听过的地址和端口。
- 公网防火墙、云安全组、NAT 网关及负载均衡日志。
- 节点连接记录和异常对端信息。
- 节点托管、同步或缓存过的私有仓库清单。
- 与仓库一起保存的密钥、令牌、部署配置和敏感历史文件。
- 自动启动任务、容器重启策略以及其他可能重新拉起节点的机制。
如果私有仓库中曾提交 API 密钥、云凭据、部署证书或数据库口令，应按“内容可能已被读取”处理并轮换这些秘密。即使秘密后来从最新版本删除，只要仍存在于 Git 历史中，也应被纳入轮换范围。
可以在仓库副本中用以下命令寻找常见敏感文件名。它只是辅助检查，不能替代专业的秘密扫描工具：
git rev-list --objects --all \
| grep -Ei '(^|/)(\.env|id_rsa|credentials|secrets?\.(ya?ml|json)|.*\.(pem|key))$' \
|| true
不要因为节点存在身份冒充风险，就默认“重新生成节点密钥”可以解决全部问题。若身份校验缺陷属于旧协议本身，密钥轮换只能作为凭据治理的一部分，无法替代协议迁移。
迁移到 Iroh 要按不兼容升级来设计
修复方向是转向 Iroh，这意味着团队需要接受向后不兼容的现实。迁移不应被当成在原节点上覆盖安装一个新版本，而应被设计为新旧信任域之间的切换。
可以按以下方式组织迁移：
- 为 Iroh 节点建立独立的配置目录、数据目录和身份材料。
- 在隔离环境中导入仓库副本，不直接复用正在调查的运行目录。
- 重新确认节点身份及授权关系，不沿用旧协议中观察到的对端身份。
- 用非敏感测试仓库验证发现、同步、权限和故障恢复。
- 明确哪些旧节点无法与新协议通信，并为协作者设定升级窗口。
- 在生产切换前验证回滚方案，但不要把恢复不安全的 clearnet 节点作为常规回滚路径。
下面是一个可改造的迁移目录脚本。它不依赖尚未确定的 Iroh CLI，只负责建立隔离工作区和只读源副本；请根据正式迁移工具补充导入命令：
#!/usr/bin/env bash
set -euo pipefail
SOURCE_REPO="${1:?用法: $0 /path/to/repository.git}"
WORKDIR="${2:-$PWD/iroh-migration}"
mkdir -p "$WORKDIR/source-snapshot" "$WORKDIR/new-node-data" "$WORKDIR/logs"
# 对裸仓库或普通仓库创建独立镜像，避免迁移工具改写原始调查对象。
git clone --mirror "$SOURCE_REPO" "$WORKDIR/source-snapshot/repository.git"
# 记录快照中的引用，便于迁移后核对。
git -C "$WORKDIR/source-snapshot/repository.git" show-ref \
| sort > "$WORKDIR/source-refs.txt"
sha256sum "$WORKDIR/source-refs.txt" > "$WORKDIR/source-refs.txt.sha256"
chmod -R a-w "$WORKDIR/source-snapshot"
printf '迁移工作区已创建：%s\n' "$WORKDIR"
printf '请把 Iroh 节点数据写入：%s\n' "$WORKDIR/new-node-data"
迁移完成后，可以再次导出新仓库的 show-ref 并与 source-refs.txt 对比，以确认分支和标签是否完整。这个检查不会验证协议安全性，但能减少迁移过程中遗漏 Git 引用的风险。
恢复服务前的决策清单
在重新开放任何节点之前，至少确认以下事项：
- 旧协议的 clearnet 入口已经关闭，且不会被自动任务重新启用。
- 潜在受影响的私有仓库已经完成分类和所有者通知。
- 仓库历史中的令牌、证书和密码已完成风险评估与必要轮换。
- 新节点使用 Iroh，而不是继续依赖存在架构缺陷的 wire protocol。
- 团队已经验证新旧节点之间的兼容性边界，并通知无法直接互通的协作者。
- 迁移测试覆盖身份验证、授权、同步完整性和断线恢复。
- 日志、配置和网络记录已被保存，后续调查不会因清理旧节点而失去证据。
这次漏洞的关键教训不是“及时升级”这么简单，而是要识别何时安全边界已经在协议层失效。面对明文泄露和节点冒充风险，正确顺序应当是先停止暴露、再调查影响、轮换可能泄露的秘密，最终通过不兼容迁移重建可信通信。