摘要

  • LACNIC 在 8 月 10 日发布的指南中，要求 Ubuntu Server 26.04 用户下载 fort-1.7.0.experimental.tar.gz，随后解压、配置、编译并运行 sudo make install，但没有给出摘要或分离签名核验步骤。
  • 该发行版早已同时发布压缩包、.asc 签名和 fort.keyring。8 月 31 日取得的三份文件与 GitHub API 的 SHA-256 全部一致；GnuPG 对压缩包返回 GOODSIG 与 VALIDSIG，完整指纹为 8F9ABC7EF3BA565F9DF1578C72160FD57B242967。
  • 有效签名是重要的正面证据，却不是完整的信任结论：隔离环境同时返回 TRUST_UNDEFINED，GitHub API 也把发行版记为非不可变。签名标签、发行资产、签名密钥和已安装程序是四个不同对象。
  • 指南若要留下可审计的安装凭据，应记录发行与 commit、预期和实测摘要、独立取得的可信指纹、构建输入、本地二进制摘要、启用时间和回退版本。

验证器的第一个输入其实是它自己

FORT 的工作是验证 RPKI 对象，并把结果提供给后续路由决策。阅读安装指南时，人很容易把“验证器”这个名称带来的安全含义一路延伸到软件本身：只要程序能够验证签名对象，它似乎也自然拥有可信来源。

这两个命题并不相同。验证器判断输入对象是否满足密码学和协议规则；操作者还要判断执行这些规则的程序从何而来、由谁授权发布、经过哪些构建步骤，最终落成了哪一个本地文件。

LACNIC 的八页西班牙语指南称其为在 Ubuntu Server 26.04、amd64/x86_64 环境中验证过的分步安装路径。文中解释，测试时 .deb 依赖 libmicrohttpd12 和 libxml2，而新系统提供的包名不同，因此改用本机开发库从源码构建。本次核查没有复现该 .deb 问题，只能把它准确归因于指南作者的测试结论。

后面的命令非常具体：下载 fort-1.7.0.experimental.tar.gz，执行 tar -xzf，再运行 ./configure、make -j"$(nproc)" 与 sudo make install。安装完成后，指南查看 fort --version，用 ldd 检查动态链接库，进行第一次验证，检查输出文件，配置服务和 RTR 监听，并提醒校准系统时钟。

也就是说，文档细致检查了压缩包进入系统之后的很多结果，却没有在它进入解压器之前核验身份。PDF 中没有 SHA-256、checksum、.asc、keyring 或 gpg --verify。其中与“签名”有关的西班牙语词根只在说明已签名的 RPKI 对象时出现，并非软件发行资产的签名。

发行页上已经摆着三份材料

根据 GitHub 记录，1.7.0.experimental 于 2026 年 7 月 16 日 01:52:42Z 创建，03:45:33Z 发布。其附注标签指向 commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e；标签对象 API 报告签名有效且通过验证。

发行资产紧随其后：压缩包在 03:47:16Z 上传，分离签名在 03:47:19Z 上传，fort.keyring 在 03:51:35Z 上传。它们都比 8 月 10 日的 LACNIC 指南早。因此，缺失步骤不是因为签名材料尚不存在。

8 月 31 日观察到的 API 记录给出三个摘要：

发行资产 SHA-256
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
fort-1.7.0.experimental.tar.gz.asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

分别取得的文件字节与 API 当前摘要一致。把提供的公钥环导入临时环境，再用 .asc 核验捕获的压缩包，GnuPG 返回 GOODSIG 和 VALIDSIG；主指纹是 8F9ABC7EF3BA565F9DF1578C72160FD57B242967，签名时间为 7 月 16 日 01:55:02Z。

这是一项很强的反证约束：现有记录没有显示压缩包恶意、被替换、错误或造成路由故障。捕获到的压缩包符合 API 当前公布的摘要，并且分离签名在所提供公钥下具有数学有效性。

同一次核验也返回 TRUST_UNDEFINED，并提示该密钥在临时环境中未由受信签名认证。这不等于签名失败，而是提醒操作者区分两道题：VALIDSIG 证明文件与持有相应私钥者之间的密码学关系；独立信任来源才回答谁控制密钥、它是否被授权为 FORT 发行签名密钥。

四段证据不能靠产品名自动拼接

第一段是标签到 commit。GitHub 所报告的有效签名，把附注标签连到 c67d14b…。它不会自动证明发行页另行上传的 tarball 恰好包含这个 commit。Git 对象与 Release 资产具有不同的存储和生命周期。

第二段是发行记录到资产字节。API 把文件名、时间与当前摘要放在一起；同一观察还显示 immutable: false、draft: false、prerelease: false。非不可变不等于曾经改动。它要求把观察时间与摘要一起保存，不能拿今天的值替所有历史下载作证。

第三段是资产到签名密钥。分离签名证明捕获字节与某把私钥对应。密钥权威还需要另一个经过认证的渠道公布完整指纹，并说明授权、轮换和撤销规则。若压缩包、签名和公钥环都从同一发行页取得，这个页面提供了方便，却没有自动产生渠道独立性。

第四段是源码到本地程序。编译器版本、configure 参数、依赖头文件和系统库都会参与生成结果。fort --version 只给出版本字符串，ldd 只展示链接关系；两者都不等于已安装文件的摘要。现有资料也没有提出或验证逐位可复现构建。

这四段没有哪一段应被夸大成事故证据。但当最后一步是 sudo make install 时，保留拼接记录的价值上升了：提权命令把写入系统的能力交给构建结果，操作者应该能够回看究竟是哪一份结果获得了这项权限。

一张安装凭据就能补上大部分缺口

指南无需改写成供应链教科书。它可以在 tar -xzf 前加入一个可直接执行的验证块：固定发行标签和资产 URL，写出预期 SHA-256，计算实测值，通过独立认证渠道取得完整指纹，核验 .asc，并明确任何不一致都应停止安装、保留证据、等待更正。

完成构建后，再记录一张紧凑凭据：

边界 应保存的最小信息
发行 标签、发行 URL、目标 commit、发布时间、观察到的不可变状态
资产 精确文件名与 URL、预期/实测摘要、下载与核验时间
签名 .asc 和 keyring 摘要、完整指纹、独立来源、信任决定与结果
构建 操作系统、架构、编译器、参数、依赖包名和版本
安装 可执行文件路径与摘要、版本输出、配置和服务文件摘要
运行 启用时间、上一版本、回退方法、密钥轮换/撤销状态、更正历史

凭据也能阻止权责漂移。FORT 维护者管理项目发行；GitHub 提供分发界面；Ubuntu 提供依赖；网络操作者决定信任和启用；LACNIC 通过指南影响推荐路径。LACNIC 并不单独控制项目、平台、系统软件包或路由器策略，但它能够把这些交接点写清楚。

上游随发行 commit 固定的 docs/installation.md 也没有摘要或签名步骤，因此只链接上游文档不能补齐缺口。真正有效的改动必须给出完整操作数和失败处理，而非一句抽象的“请验证下载”。

证据所允许的结论很窄，也很有用

本次发现针对公开说明，不针对任何网络的实际操作。不能因为 PDF 未写签名核验，就断言读者没有执行自己的下载校验、内部镜像、受控构建或二进制审批。

同样，immutable: false 不是资产被替换的证据；当前摘要不能证明过去每次下载的内容；随发行页取得的密钥下出现良好签名，也不独立证明签名者法律身份或组织权限。现有材料没有显示 RPKI 验证失败、路由泄漏或劫持。

这也不是 FORT 的 ASPA 输出或 RTR 协商问题。那些问题位于验证结果向路由器交付的一端；本文关注的是更早的一端——产生结果的可执行文件能否追溯到一份明确资产和一项被授权的信任决定。

恰当结论是：LACNIC 认真记录了安装后的运行检查，却没有利用发行版已经提供的验证材料，连接下载与构建。现在补上这一小段，无法消除所有依赖和密钥风险，却能把一次提权安装变成可重复、可纠正、可回退的控制事实。

来源