版本号更大也可能不是可靠更新：回滚、冻结与镜像不一致怎样识别

同一下载页在两个网络显示不同版本：一个文件名数字更大，另一个文件的签署资料更新；两次下载的大小和时间也不一致。若只挑最大的版本号直接覆盖，读者仍不知道它是否属于一次完整、未过期且可追溯的发布。

版本号只有放进发布关系中才有意义。网页日期、本地修改时间和文件名都可以在复制或同步时改变；旧文件也能在今天重新下载。可靠判断需要同时看到受信任历史、签署元数据、过期边界、同一快照与目标文件摘要。

版本号必须放进经过签署且有过期约束的一致元数据视图中解释；单独的网页日期、文件名或本地修改时间无法排除回滚、冻结和混搭。

更大的版本号为何仍需要上下文

数字更大通常表示发布者想表达较新的顺序，却不自动证明数字由有权角色发布。攻击者可能提供异常大的元数据版本，使后续真实更新看起来像倒退；网页也可能先更新文字，而镜像文件尚未同步。

TUF规范把这种风险单独称为快进攻击。它要求客户端不仅比较“现在看到什么”，还要保存已经信任的元数据状态，并让不同角色的版本、摘要和签名互相约束。

同一软件还可能同时使用营销版本、内部构建号、包版本和元数据版本。它们服务不同流程，不能只按字符串大小合并。真正需要回答的是：当前文件是否由可信目标元数据描述，这份目标元数据是否属于当前快照，快照是否由未过期时间戳指向。

镜像差异也不自动等于攻击。缓存传播、分阶段发布和区域同步会形成短暂不一致；但在发布方给出一致记录前，用户不应覆盖两个样本，也不应把任一文件当作已经证明的新版本。若差异跨过时间戳有效期仍未收敛，或文件摘要与同一份签署目标记录冲突，就不能再用普通同步延迟解释。

目标元数据把摘要、长度和路径绑在一起

只比较文件名很弱。名称可以复制，版本号可以写进名称，本地修改时间还会随复制、下载或解压过程改变。要核对文件字节，需要一个来自可信发布记录的摘要，而不是让文件和摘要从同一个未经核验的地方一起出现。

TUF的目标元数据列出目标文件路径、加密摘要和长度。客户端取得目标文件后，会依据已经验证的目标元数据核对长度与摘要。两者都匹配，才能说明取得的字节与该份元数据描述的目标一致。

摘要的作用也有边界。摘要匹配说明字节一致，不等于软件没有漏洞。若错误文件和它的摘要一起由错误来源提供，本地计算结果仍会匹配。因此，摘要必须和经过授权角色签署的元数据、可信根以及明确的发布渠道连在一起。

文件大小看似普通，却能帮助快速发现截断或替换。单独看大小当然不够，因为不同内容可以有相同长度；把长度与加密摘要共同写进签署记录，才形成更明确的目标描述。

普通下载页未必采用TUF，也未必公开机器可读的目标元数据。此时可把这些机制当成判断问题的框架，而不能反过来宣称某个客户端已经实现同样保护。TUF规范不证明任何具体客户端采用TUF。

快照防止不同发布时间的记录被拼在一起

即使每份目标元数据都带签名，仓库里也可能同时存在多代记录。若客户端从一个镜像取得新版文件列表，又从另一个缓存取得旧版委派记录，单独验证每份签名仍可能看见一组从未共同发布过的组合。

快照角色记录全部目标元数据的版本。客户端验证快照的签名、版本和摘要，再要求目标元数据与该快照一致。这样做的目的不是证明程序功能正确，而是让一次更新看到同一时点的仓库状态。

TUF把这种跨时期组合称为混搭风险。用户在两个网络看到不同文件时，不应马上断定遭到攻击，因为缓存、镜像同步和分阶段发布也会制造暂时差异。但差异值得记录，尤其是页面版本、文件大小、摘要和签名主体无法互相对应的时候。

仅重新下载同名文件，无法解决一致性问题。较好的做法是保留两次取得文件的时间、来源页面、大小和发布说明，再等待发布方给出能够解释差异的同一份记录。不要同时改文件名或覆盖原文件，否则会丢失对照依据。

时间戳处理的是陈旧记录，不是下载时间

“今天下载”不代表“今天发布”。旧文件可以在今天重新传输，过时的签署元数据也可能在有效期内被缓存。要判断新鲜度，客户端必须记住过去已经信任的版本，并对新取得的元数据设置不能倒退的规则。

TUF的时间戳元数据指向最新快照，并带有版本和过期时间。客户端比较已信任版本，拒绝更旧版本。新时间戳若倒退，更新流程会把它当成潜在回滚；若时间戳已经过期，则停止接受并报告潜在冻结。

回滚与冻结并不相同。回滚是把客户端带回较旧的可信状态，可能重新暴露已经修复的问题；冻结则持续提供同一份旧记录，让客户端不知道已有更新。网页上的“最新版”字样和本地文件日期都不足以排除两者。

过期机制也不是无限保证。检查依赖合理的时间来源，而且攻击者仍可在有效期内扣留更新。有效期越短，持续冻结的窗口通常越小，但发布端需要更频繁地更新在线元数据，并承担密钥暴露和可用性管理成本。

因此，时间戳角色与快照角色分开有实际意义。时间戳需要频繁在线更新，快照则描述更大的元数据集合。把角色与密钥分开，可以限制一把在线密钥失守后能够改变的范围。

密钥分工让局部失守不必等于全部失守

若同一把在线密钥既能改变可信根，又能宣布目标文件和更新时间，那么一次密钥泄露就可能改写整个更新判断。TUF采用角色分工，是为了缩小每把密钥能够作出的声明范围，而不是假设密钥永远不会失守。

根角色负责授权顶层角色，目标角色说明哪些文件可被接受，快照角色固定元数据集合，时间戳角色则提供较短的新鲜度窗口。各角色可以使用不同密钥，也可以要求达到多个签名的门槛。

门槛签名的意义是，攻击者取得少于门槛数量的根密钥时，仍不能单独完成受信任的根轮换。发布团队也能撤销受影响密钥，并用既有信任关系引入新密钥。客户端必须逐个版本更新根元数据，不能直接跳过中间授权关系。

这种设计仍然不是“某把密钥失守也没关系”。不同角色失守会留下不同风险，多个关键角色同时受控时，保护会显著减弱。规范要求的隔离、离线保存、门槛和轮换，是把故障范围变得可管理。

对普通用户来说，这一层通常不可见。能看见的信号是发布方是否解释签名主体、证书轮换、旧证书撤销和版本迁移。主体突然改变而没有说明时，应暂停运行新文件并查找发布方的独立公告。

发布流程要留下事后可核验资料

更新框架描述客户端怎样验证，发布组织还要回答资料怎样产生、保存和复查。若发布结束后只剩一个安装包，出现漏洞或签名争议时，就很难重建当时使用了哪些组件、哪份摘要对应哪个文件，以及谁批准了发布。

NIST SSDF要求向软件取得者提供完整性验证信息。PS.2列出的做法包括在受良好保护的网站发布加密摘要，也包括使用可信证书机构支持代码签名，并定期检查证书续期、轮换、撤销和保护流程。

这不是要求用户自己审计整个开发过程，而是说明发布者需要提供可核验的外部证据。摘要和签名都是证据，却没有任何一项能单独代替发布来源、版本关系与记录保存。

NIST的PS.3进一步要求安全归档每次发布需要的文件、完整性资料和来源数据。来源数据可包括组件清单等记录；每当组件更新，也应维护相应资料，并保护资料本身的完整性。

归档的价值在发布之后才更明显。若某个组件后来被发现有漏洞，团队需要知道哪些发布包含它。若文件被质疑，团队可依据归档中的发布文件、摘要、签名和来源资料重建当时的交付记录。

普通用户通常看不到全部内部记录。NIST SSDF本身也是高层实践，不规定所有组织必须使用同一种工具。因此，公开资料不足时可以把结论停在“目前无法核验”，不能因为看不到记录就直接声称文件恶意，也不能因为签名存在就补齐缺失证据。

下载时怎样保留一组可复查记录

准备运行新客户端前，分别记录页面地址与时间、文件名与大小、签名主体、版本说明和发布摘要。若发布方没有提供摘要，就明确记为未提供，不要从第三方评论或搜索摘要中拼出一个值。

系统签名界面应读取完整主体和状态，不只截一个绿色图标。若签名无效、证书被撤销、主体与预期发布者明显不符，或系统无法完成验证，应停止运行文件并回到已知渠道复查。

有发布摘要时，在本地计算同一种算法的摘要并逐字比较。算法名称也要一致；把SHA-256结果与另一种算法的字符串比较没有意义。结果不符时不要反复覆盖下载，应保留样本名称和取得时间供反馈。

版本说明要和文件属性、安装后的版本显示分开记录。页面可能先更新文字，镜像文件稍后同步；客户端也可能使用内部构建号而不是营销版本号。短暂差异不自动等于攻击，但发布方应能给出一致解释。

若两个网络给出不同文件，先固定设备、浏览器和页面地址，再比较响应时间、文件大小、摘要和签名。不要为了消除警告而关闭系统保护，也不要从陌生镜像寻找一个“能安装”的版本。

这些记录不能把普通用户变成供应链审计员，却能把模糊的“下载不对”变成可核验问题。发布方也更容易据此区分缓存未同步、页面说明滞后、签名验证失败或文件内容不一致。

结论仍要守住证据边界。签名有效不证明软件没有漏洞，摘要匹配不评价程序行为，版本更大也不保证适合当前设备。可信根、目标元数据、快照、时间戳和发布归档共同提高可核验性，但它们不是绝对安全承诺。

版本、签名与更新链的判断依据如下：

• The Update Framework，The Update Framework Specification, Version 1.0.28，2021年12月14日。
• National Institute of Standards and Technology，Secure Software Development Framework (SSDF) Version 1.1，2022年2月3日。

资料来源

• The Update Framework：《The Update Framework Specification, Version 1.0.28》，发布或更新于 2021-12-14
• National Institute of Standards and Technology：《Secure Software Development Framework (SSDF) Version 1.1》，发布或更新于 2022-02-03