摘要

  • RIPE Atlas 固件 5130 新增 openwrt-hwprobe 架构，用于在现有硬件探针上支持下一代固件；与此同时，RIPE NCC 第三季度计划仍把整体 OpenWrt 打包工作标为进行中。
  • 公开材料已经显示出多项真实控制：生产分支、生产版本编号规则、按硬件世代划分的公钥文件、发布说明、用于排查更新文件的校验和输出，以及探针记录里的固件版本。
  • 这些控制不能让“5130”自动等同于构建或部署证明。完整证据还应连接不可变源码提交、OpenWrt 工具链、产物摘要、签名权限、硬件资格、批次结果与回滚状态。
  • 本文不指称构建遭入侵、签名错误、更新失败、服务中断或测量受损。建议公开聚合、机器可验证的发布清单，并以受保护的逐设备部署账本作为底层依据。

版本号站在流程末端

一台探针报告固件版本时，很多决定已经发生。开发者选择了代码，构建系统组合了依赖、目标配置与工具链，签名权限批准了某组字节，更新系统判断设备是否符合条件，探针完成下载、校验、启动和重新连接，然后才把版本字段暴露给页面或 API。

这些动作回答的问题完全不同。代码审查回答“允许构建什么”；产物摘要回答“实际构建了什么”；签名回答“谁授权这组字节”；批次规则回答“哪些设备现在可以接收”；设备状态回答“更新是否成功”；测量验收则回答“设备是否仍能履行 RIPE Atlas 的功能”。

5130 发布说明之所以重要，不只是因为它列出一个新版本。它同时覆盖所有平台、硬件探针、软件探针和持续集成。硬件部分新增 openwrt-hwprobe，说明该架构可让现有硬件探针使用下一代固件；它还把分裂式基础改为共同基础，增加更新文件的校验和调试输出，修复应用升级问题，并让探针在没有收到 reginit 回复时也能解析已保存的静态网络配置启动。

同一个版本号因此容纳了构建、启动、注册、网络配置和测量等不同变化。发布时采用一个编号很合理；审计时把所有事实压缩成一个编号则不够。两台都显示 5130 的探针，只有在产物、目标配置和部署状态相同的情况下，才可以被当作经历了同一次交付。

版本号最适合做连接键。问题在于，它目前更像一块路牌，而不是一张能沿途核对的交接单。

路线图进入代码，不等于所有设备已经迁移

RIPE NCC 的第三季度 RIPE Atlas 计划说，团队继续简化探针固件流程，目前正在为硬件探针开展 OpenWRT 工作，状态为“进行中”。这一表述谨慎而准确：它描述的是一个包含多步交付的项目。

5130 则证明其中一个步骤已经成为公开代码与发布说明：新架构存在，并被描述为下一代硬件固件的基础。两条信息可以同时成立。项目尚未结束，不表示尚无可运行成果；架构已经发布，也不表示所有现有设备都已安装。

真正的部署由中间状态组成：代码合并、生产构建批准、产物签名、金丝雀批次开放、扩大资格、设备尝试、健康检查、暂停、例外和回滚。若公开记录只有“进行中”与“已发布”两种状态，外部读者会被迫在两个错误结论之间选择。

这不仅影响透明度，也影响对工程团队的公平判断。离线设备不应被算作失败；主动延期可能是风险控制；成功回滚说明保护机制起作用。只有把状态分开，数据才能说明这些差异。

公开仓库已经给出控制语法

固定在被审查提交上的 BUILD 文档把 master 称为生产就绪分支，并说硬件探针固件从该分支构建。testing、devel 和任务分支承担不同成熟阶段。文档还规定，能被 10 整除的版本号属于生产发布。

这些规则有实际价值。分支隔离降低了开发代码被误认为生产版本的风险；编号约定让使用者可以理解一个版本的预期身份。但 master 会不断移动。几个月后，仅凭分支名无法知道某个二进制到底取自哪个历史状态。

这份文档本身已经承认问题：OpenWrt feed 默认可跟随 master，也可通过 ^commit 固定到具体提交。因而，发布清单应把实际构建使用的提交写成必填标识，而不是让后来的人从发布日期和分支历史猜测。

固定的 OpenWrt Makefile又显示出其他边界。PKG_VERSION 从仓库 VERSION 文件取得；源码树被复制到 OpenWrt 构建目录；v3、v4、v5 硬件分别包含开发、测试与生产公钥文件；硬件包只应在 RIPE NCC 指示下安装。

这里至少有四类权限：分支表示代码成熟度，版本表示发布身份，公钥类别验证更新权限，RIPE NCC 的部署指示决定运行层面的许可。它们互有关联，却不能互相替代。

固定源码提交仍不是完整构建证明

即使两个构建使用同一个 RIPE Atlas 提交，OpenWrt 版本、SDK、编译器、软件包 feed、补丁或构建选项不同，输出字节仍可能不同。源码提交是必要条件，不是充分条件。

因此，机器可读清单至少应记录：不可变提交；OpenWrt 发行版和 SDK 标识；依赖或 feed 锁定值；硬件目标配置；构建选项；产物与清单摘要；生产签名公钥的指纹或非机密类别；批准角色；版本号与发布说明地址。

这不要求任何人公开私钥，也不必承诺任何第三方都能在任意机器上逐字节复现。更低但关键的标准是：同一身份所指的产物究竟是哪组字节，使用者能够核对；若出现两个不同输出，也能知道它们是否本来就属于不同目标。

5130 说明提到增加校验和输出，以便调试更新文件。这个细节说明，产物完整性不是外部评论者凭空附加的仪式，而是交付过程中已有的工程需求。发布回执只是把这套做法延伸到构建、签名、授权和部署之间的交接处。

“很可能升级”保留了必要的不确定性

RIPE Atlas 的探针管理文档说，探针连接后“很可能”升级到最新固件，然后开始预定义测量；详情页会显示固件版本。公开探针 API也提供 firmware_version 过滤。

这是很有价值的可观测性。不过，“很可能”不是“所有设备在同一时刻完成”。硬件探针由不同网络和主机承载，有的长期离线，有的晚些时候重连，有的可能不属于当前资格批次。更新还可以在安装后因健康检查而暂停或回滚。

公开逐台设备的失败时间与位置并非合适答案。那会增加主机识别和攻击面风险。合理结构应分两层。

受保护的设备层保存：设备标识、硬件世代、更新前后版本、产物摘要、资格规则、尝试与确认时间、签名校验、启动与连接结果、测量验收、错误类别、重试、回滚授权与例外原因。访问范围和保存期限应受到控制。

公开层则按足够大的硬件世代或批次汇总：符合资格、已经尝试、成功、延期、失败与回滚的数量；部署窗口；分母口径；测量测试版本与通过规则；当前状态是活跃、暂停、替代还是撤回。

其中分母最容易被忽略。“99% 已升级”若没有说明是否排除离线设备、不合资格设备和主动延期，几乎无法复核。“零失败”若只统计收到成功回执的设备，也没有意义。数字必须与资格快照和观察时间绑定。

能启动，不等于能测量

硬件探针不是以开机为最终目的。它的价值在于持续生成测量结果。因此，部署状态至少要区分产物安装、控制器重连和测量验收。

验收可以包括签名验证、身份连续性、静态与动态网络恢复、时钟行为、DNS、ping、traceroute，以及本次版本实际触及的其他功能。为避免暴露安全细节，具体目标和敏感阈值可留在受保护层；公开层应给出测试套件版本、判定规则和聚合结果。

这样做还能避免把“报告 5130”误读为“5130 下的所有测量都已被验证”。版本字段说明设备自报状态，而测试回执说明平台是否根据既定标准接受了这次状态转换。

回滚也应成为明确状态。记录需要说明触发阈值、决策权限、影响批次、回滚产物，以及在相关时间窗产生的测量是否需要注释。回滚不是羞耻性事件；无法解释回滚的对象与范围才会破坏信任。

需要的是自动清单，不是另一个委员会

RIPE Atlas 已有固件发布索引、详细说明和 GitHub 上的版本 5130 对象。仓库公开分支、构建方法、目标配置和公钥类别，探针页面与 API 又公开运行版本。多数词汇都已经存在。

缺少的是稳定连接。构建和部署系统应自动生成签名清单，而不是让工程师事后撰写冗长报告。紧急修复也可以先发布最小身份——版本、提交、产物摘要、签名类别、批准角色——再在限定时间内补充批次结果与例外。

这一建议不假定 RIPE NCC 内部没有软件物料清单、构建证明或部署账本。公开材料无法证明内部系统的缺失。它提出的是更窄的问题：当 5130 被作为测量数据解释的公共边界时，外部读者至少需要哪组可验证连接。

共同基础会提高维护效率，也会让一个共享缺陷可能触达更多硬件世代。正确结论不是拒绝共同基础，而是让证据链随复用范围一起加强。

来源