TUF 更新框架仓库信任与安全轮换手册
桌面客户端连续几轮都显示“已是最新版本”，服务器也能返回签名有效的 metadata。安全团队后来发现边缘缓存一直重放旧 timestamp；它尚未过期，客户端就没有立刻报错，真正修复发布始终不可见。等 timestamp 到期后，更新终于失败，却被运维当成网络抖动清空缓存，客户端随即失去了已信版本记录，回滚检测也被一起清掉。
另一次根密钥轮换中，仓库直接发布了相隔多个版本的 root.json，并只用新 key 签名。新安装客户端因为应用包内已带新 root 而工作，存量客户端却从旧 root 开始，只会请求下一版本，也无法用旧 threshold 授权这次变化。团队拥有“最新 root”，却没有一条从旧信任到新信任的连续链；绕开失败需要重新分发可信 bootstrap，而不是让客户端下载任意最新文件。
TUF 保护的是更新工作流而不是下载链路本身
TUF 是一套更新安全框架和元数据协议，不是唯一 CLI、单一服务端或软件包格式。仓库发布目标文件及签名 metadata，客户端从随应用交付的可信 root 开始，按规定顺序更新 root、timestamp、snapshot、targets 和 delegated targets，再根据目标 path、length 与 hashes 下载。HTTPS 可以保护一次连接，却不能在镜像、缓存或仓库被控制时独立抵御旧元数据重放、不同批次拼接和密钥泄露后的权限扩大。
TUF 规范 1.0.35属于 1.x Living Standard。实现版本与规范版本独立，接入时要固定所选实现、其 POUF 或兼容约定、序列化规则和支持的规范线。Python 参考实现、Go、JavaScript、Rust 实现以及 RSTUF、tuf-on-ci 等仓库系统各自提供不同 API 和运维面，不存在一条适用于所有环境的“安装 TUF 服务端”命令。
TUF 的安全承诺也有明确边界。控制网络或仓库的攻击者始终可以拒绝响应、隐藏新 root、拖慢委派查找或返回超大恶意输入，从而造成 DoS。框架努力保证客户端不会静默接受不可信、陈旧或相互矛盾的状态，并给出可分类失败；它不保证攻击发生时一定能取得最新更新。
安装实现之前先固定 bootstrap root 和状态目录
以 Python 参考实现为例，隔离虚拟环境安装客户端库；仓库签名工具需要额外算法能力时，再按官方安装说明启用相应 securesystemslib crypto 依赖。依赖和 hashes 应由项目锁文件固定：
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install --require-hashes -r requirements-tuf.txt
python3 -c "from importlib.metadata import version; print(version('tuf'))"初始 root.json 不能从准备受它保护的同一仓库临时下载。它必须经应用安装包、只读系统镜像、受控设备配置或另一条可信 out-of-band 渠道交付，并经过独立摘要或发布审批。bootstrap root 放在只读路径；客户端工作 metadata 放在可持久化、原子写入、单写者控制的目录。不要让 updater 账号覆盖 bootstrap，也不要把两者混在一个默认可写缓存里。
目录可以这样分离：
/opt/example/trust/root.json # 随应用交付，只读 bootstrap
/var/lib/example/tuf/metadata/ # 当前 trusted metadata，持久化、单写者
/var/lib/example/tuf/targets/ # 已验证下载，可按策略清理
/var/lib/example/tuf/decision/ # 更新决定与脱敏审计当前 Python Updater 构造器要求显式传入 bootstrap bytes；实现会把它写入 root history，再逐版加载本地或远端后继 root。不要在每轮刷新前手工覆盖 metadata 目录中的 root.json。之后 metadata 目录中的 root history、timestamp、snapshot 和 targets 是持续演进的客户端安全状态，备份恢复也必须保持版本单调。Python Updater 不支持多个实例并发共享同一 cache directory；HA 客户端应每副本拥有独立状态，或由一个更新代理串行刷新后向本机消费者发布经过验证的目标。
root、targets、snapshot 与 timestamp 各自缩小权限
root 定义顶层角色的 key IDs、threshold、过期时间和 consistent_snapshot，并授权下一版 root。root key 通常离线分权，因为达到 root threshold 的泄露足以重写信任关系。root metadata 不是“根证书文件”的同义词，它是带版本、角色、key 和签名的可信状态对象。
targets 不直接把签名附到每个目标字节上，而是签目标 metadata：path、length、hashes 和可选 custom。它还能把部分 path 授权给 delegated targets role。目标发布者因此签的是“哪些字节位于哪个逻辑路径”，客户端最终必须同时验证 length 和至少一种受支持 hash，不能只验证 metadata 签名。
snapshot 绑定顶层 targets 及所有 delegated targets metadata 的版本，并可携带 hash 和 length。它声明哪些 metadata 同属一个仓库状态，阻止攻击者把旧 delegation 和新 targets 拼成从未存在过的组合。timestamp 只描述最新 snapshot metadata，通常由在线 key 频繁更新并使用较短有效期，以缩小旧 snapshot 可被重放的窗口。在线不代表低价值：timestamp 或 snapshot key 泄露仍可制造冻结、快进或资源消耗。
四类角色串成的是授权和新鲜度链，而不是四个平行 JSON：
可信 bootstrap root
-> 逐版本验证并持久化 root N+1
-> timestamp 指定当前 snapshot 版本，并可绑定 hash/length
-> snapshot 指定 targets 与 delegated metadata 版本，并可绑定 hash/length
-> targets/delegations 授权目标 path、hashes、length
-> 下载目标字节并逐项匹配，才交给应用官方 metadata 概览给出了各角色职责。把 timestamp 和 snapshot 合并成“索引文件”，或让所有角色共用一把在线 key，会失去分权和泄露恢复价值。阈值、有效期和在线/离线安排必须从威胁模型、发布频率与恢复时长推导，规范示例数字不是生产推荐值。
配置字段改变的是攻击窗口和恢复路径
每份 metadata 的 _type、spec_version、version、expires 与 signatures 是验证入口。version 必须按角色单调递增，客户端保存已信版本来检测回滚；expires 由本轮刷新开始时固定的可信本地时间检查，避免一次更新过程中时间漂移导致前后角色使用不同判断。系统时钟异常会表现为潜在 freeze 或过期，不得用全局忽略过期来恢复。
root 中 roles.<role>.keyids 决定哪些 key 可以签该角色，threshold 是需要多少个唯一 key ID 的有效签名。同一 key 重复签多次只算一次。threshold 签的是对应 role metadata，不是要求多人直接给 target 文件逐字节签名。consistent_snapshot: true 会让 metadata 和目标使用版本或 hash 相关命名，降低并发发布时镜像混读风险，但增加对象数量、复制和 GC 约束；切换该字段必须与全部客户端和镜像兼容。
targets 的 targets.<path>.length 与 hashes 绑定最终字节；custom 可承载应用语义，却不自动获得额外验证含义，消费者必须按 schema 解析并限制大小。snapshot/timestamp 的 meta 条目把下游 metadata 的版本以及可选 length/hash 固定下来。省略可选 hash/length 会减少绑定强度和提前拒绝能力，不能用 HTTPS 弥补。
委派中的 name、keyids、threshold、paths 或 path_hash_prefixes、terminating 共同定义查找空间。paths 与 path_hash_prefixes 只选一种；过宽 path 扩大发布权限，过细 path 增加 metadata 和查找成本。客户端还要配置每轮 root 下载数、metadata 大小、委派访问角色数、总下载量和超时上限，防止合法签名的恶意图耗尽资源。
客户端持久状态是回滚防护的一部分
客户端至少持久保存当前 trusted root、timestamp、snapshot、targets 与已经访问的 delegated metadata。刷新不是每次从零开始验证：新 metadata 要与这些版本比较，较低版本必须拒绝。清空缓存、把备份恢复到旧快照，或让多个 updater 竞争写同一目录，会抹掉或破坏版本连续性，使“签名仍有效的旧状态”重新变得可接受。
Python 参考实现的入口可以保持很薄，应用只能消费 get_targetinfo() 找到且由 download_target() 完成 length/hash 验证的对象：
from pathlib import Path
from tuf.ngclient import Updater
metadata_dir = Path("/var/lib/example/tuf/metadata")
target_dir = Path("/var/lib/example/tuf/targets")
bootstrap = Path("/opt/example/trust/root.json").read_bytes()
metadata_dir.mkdir(parents=True, exist_ok=True)
target_dir.mkdir(parents=True, exist_ok=True)
updater = Updater(
metadata_dir=str(metadata_dir),
metadata_base_url="https://updates.example.test/metadata/",
target_dir=str(target_dir),
target_base_url="https://updates.example.test/targets/",
bootstrap=bootstrap,
)
updater.refresh()
info = updater.get_targetinfo("releases/example-linux-amd64.tar.gz")
if info is None:
raise RuntimeError("target is not authorized by current metadata")
path = updater.download_target(info)
print(path)refresh() 依次处理 root 链、timestamp、snapshot、targets；delegated metadata 在目标查询时按需抓取。每次接受新 root 后都要原子写入非易失存储。更新过程固定一个起始时间，最终 root 追到最新后再依据这个时间检查过期。客户端进程崩溃时，临时文件不能覆盖最后一份完整可信 metadata；恢复后要么看到旧完整状态并继续，要么看到新完整状态，不能看到半个 JSON。
备份策略也不能只复制文件。应记录各 role 已信版本、root 文件 digest、状态目录所有者和最后一次成功刷新决定。恢复演练必须证明版本没有倒退；若只能恢复旧状态，需按安全事件处理并重新建立可信 bootstrap，而不是静默删目录。
root 轮换必须逐版本完成双阈值验证
客户端从 trusted root N 开始，只请求 N+1，接受后再请求 N+2，直到仓库表示下一版不存在。每个 N+1 必须同时满足旧 root N 中 root role 的 threshold，以及新 root N+1 自身声明的 root threshold。前者证明旧信任授权变化，后者证明新信任集合认可自身；版本还必须恰为 N+1。
安全轮换通常分四步：先生成新 key 并让旧、新集合共同签 N+1；发布后等待存量客户端持久化；再用后续 root 移除旧 key；最后按离线 ceremony 销毁或封存旧材料。不能直接跳到只含新 key 的最终 root。若 timestamp 或 snapshot 任一角色的 key 被轮换，客户端接受新 root 后应同时删除 trusted timestamp 和 trusted snapshot，再按新授权刷新，以便从被泄露在线 key 制造的 fast-forward 中恢复。
少于 root threshold 的 key 泄露可以经正常轮换撤销；达到 threshold 时，攻击者可能构造被客户端接受的新根，已经越过在线轮换的恢复假设。此时要启用 out-of-band 恢复：发布带新 bootstrap 的应用、设备配置或人工介质，隔离受影响仓库，并评估每个客户端最后可信 root。仓库控制者即使没有 root 私钥，也能隐藏新 root 造成冻结，所以轮换监控既看签名 ceremony，也看存量客户端追版本水位。
委派查找是有顺序的深度优先授权
顶层 targets 可以声明多个 delegated role，同一路径允许被多个 role 覆盖，数组顺序就是优先级。查找从顶层 targets 开始，按声明顺序做 preorder depth-first search。每进入一层，目标都必须满足委派链上每一层的 path 约束；叶子 role 自己声称拥有目标，不足以越过上级授权。
terminating: true 表示当前 delegation 及其后代搜索结束后，不再考虑后续匹配声明。它适合明确排他的命名空间，却很容易被过宽路径或错误顺序误用：前置 role 没找到目标，也可能压住后面的合法发布者。撤销 delegated role 由直接委派者发布新 metadata，移除 delegation 或 key，再由 snapshot 绑定新版本；删除服务器上的旧 JSON 不能替代授权撤销。
可以把查找行为写成可测试契约：
targets
1. security-hotfixes paths=["releases/*"] terminating=true
-> security-linux paths=["releases/linux/*"]
2. product-releases paths=["releases/*"] terminating=false
查询 releases/linux/app.tar.gz：
先查 security-hotfixes，再查 security-linux；若未命中，因父级 terminating，
不会继续 product-releases。调整顺序或 terminating 会改变可发现结果，而非只影响性能。客户端必须检测 delegation cycle，并限制访问 role 总数、metadata 字节数与递归深度。仓库发布检查则扫描路径交集、不可达 role、terminating 遮蔽和 threshold key 可用性。委派规模很大时，path_hash_prefixes 可分片，但会降低人工可读性，并增加 role 数、请求数和镜像对象数。
第一组夹具验收验证目标字节和持久化回滚检测
实验仓库要交付三套可审计 fixture，而不是引用仓库中不存在的 tuf-client.py 或 serve-metadata-fixture.sh。正常 fixture 发布版本 N 的顶层 metadata 和 releases/demo.bin；篡改 fixture 保持 metadata 不变，只改变目标字节；回滚 fixture 返回低于客户端已信版本的、签名仍有效的 metadata。客户端使用前述 Updater 代码，且三轮中的回滚轮必须复用正常轮已经写入的同一 metadata 状态目录。
正常轮应零退出，并保存落盘后的 role/version、root history、目标摘要和下载路径。篡改轮必须在 download_target() 把文件交给应用前因 length 或 hash 不匹配而失败。回滚轮必须因版本下降而失败，并证明最后可信 metadata 未被覆盖。夹具生成器、启动方式、监听地址、仓库文件 digests 和预期版本矩阵必须随测试工程交付；缺少这些输入时，运行状态必须是 not-run，不能生成成功证据。
正向证据包括落盘后的 role/version、最终 target hash 和零退出。篡改反例必须在文件交给应用前失败；回滚反例必须使用同一 metadata 状态目录，证明本地状态参与判断。为了演示而清空目录后，旧 metadata 可能重新通过当前 bootstrap 的验证，这恰好证明“删缓存修复”破坏安全边界，不能成为生产操作。
第二组夹具验收验证逐版 root、threshold 与委派顺序
第二组从已信 root N 出发准备四套仓库状态：正向状态含恰好 N+1 且同时满足旧、新 root threshold 的 root；跨版状态只提供 N+3，单边状态提供只满足新 threshold 的 N+1；阈值状态让 threshold=2 的 delegated role 只带同一 key ID 的重复签名；遮蔽状态让目标落在 path 外，或位于前置 terminating role 覆盖而未找到的路径中。每套 fixture 都必须包含完整 targets/snapshot/timestamp 绑定，不能只手改一份 JSON 后跳过上游签名。
正向状态应逐版接受并持久化 N+1。跨版和单边状态必须保持最后可信 root 为 N；阈值状态必须报告唯一授权 key 数不足；遮蔽状态的 get_targetinfo() 必须返回未授权或不可达。证据保存 bootstrap digest、请求顺序、所有候选 metadata digest、唯一签名 key IDs、最终 root version、目标查找结果和异常类型。测试工程没有实际 fixture 生成器时，本组状态必须保持 not-run，不能用示意命令替代运行入口。
关键证据不是错误文本，而是客户端未覆盖最后可信 root、唯一 key 数不足、目标查询返回未授权或不可达。清理时停止 fixture 服务，恢复完整合法 metadata 集，重新刷新并核对版本单调；删除实验私钥和 target 临时文件，但保留脱敏后的 role/version、文件摘要和失败分类。
冻结、回滚、快进与 mix-and-match 有不同证据
冻结攻击返回旧但签名仍有效的 metadata。客户端以本轮固定起始时间检查 root、timestamp、snapshot、targets 的 expires；过期后中止并报告潜在 freeze。未过期旧 timestamp 在窗口内仍可能隐藏新更新，因此有效期越长，冻结窗口越大；越短则越依赖在线 timestamp 签名服务、可信时钟和发布可用性。
回滚是返回低于客户端已信版本的 metadata。客户端比较本地版本、timestamp 指向的 snapshot 版本和 snapshot 中各 targets/delegated metadata 版本，任何下降都应失败。签名完全正确也不能覆盖版本下降。备份恢复、容器无状态化和共享缓存最容易无意中制造这一攻击条件。
快进来自泄露的在线 key：攻击者可把 timestamp、snapshot，或 snapshot 所列 targets/delegated metadata 的版本推到异常高值，合法系统恢复后发布的正常版本反而看似回滚。root 轮换 timestamp 或 snapshot key 后，客户端同时删除 trusted timestamp 与 trusted snapshot，才能按新授权接受合理版本。实现还需限制单轮 root 更新数、metadata 大小、整数与版本处理、委派访问量和总刷新预算；TUF 能拒绝不可信状态，但无法阻止仓库或网络攻击者持续制造下载、解析和超时型 DoS。
mix-and-match 把不同发布批次的 timestamp、snapshot、targets 或 delegated metadata 拼在一起。timestamp 对 snapshot 的 version/hash/length 绑定，snapshot 对全部 targets metadata 的绑定使拼接失败；consistent snapshot 又降低 CDN 在原子发布窗口混读同名对象的概率。仓库发布必须先上传版本化 targets 和 metadata，最后原子切换 timestamp，不能先暴露一个指向尚未复制完成对象的新 timestamp。
这四类失败都不应被笼统记录成“签名错误”。冻结看过期和新鲜度，回滚看本地版本连续性，快进看异常高版本与 key 轮换恢复，mix-and-match 看上下游 meta 绑定。网络超时或仓库拒绝响应则是 DoS/可用性失败；它可以阻止更新，但不能因此放宽验证。
仓库和流水线接入要维持单一发布权威
生产侧将 root/targets 离线或受控签名 ceremony、timestamp/snapshot 在线自动化和对象发布分成权限域。构建流水线先生成 target，计算 length/hash，再由有资格的 targets 或 delegated role 更新 metadata。snapshot 收集这一批全部 targets metadata 的最终版本，timestamp 最后指向 snapshot。任何中途失败都不发布新 timestamp，因此客户端继续看到上一份完整仓库状态。
一个简化的发布清单可以记录：
tuf_publication:
repository_generation: "release-batch-id"
root_version: "<monotonic>"
targets_roles:
- name: "product-linux"
version: "<monotonic>"
threshold_key_ids: ["<key-a>", "<key-b>"]
snapshot_version: "<monotonic>"
timestamp_version: "<monotonic>"
target:
path: "releases/linux/demo.tar.gz"
length: "<bytes>"
hashes: {sha256: "<digest>"}客户端接入把 refresh 和应用安装分开。更新代理只读远端仓库、写本地 TUF 状态和下载区；应用只读已验证 staging，并根据结构化 decision 做原子切换。更新失败保留上一已验证版本，不把“暂时取不到新包”转换成“安装未验证镜像”。镜像和 CDN 需要复制版本化 metadata、targets 与最终 timestamp，健康检查要从一个真实 bootstrap 客户端完成全链刷新，而不是只探测 HTTP 200。
排障从本地可信状态和第一处绑定失败开始
遇到“无法更新”，先保全 metadata 状态目录和当前 root digest，禁止清缓存。读取本轮固定起始时间、系统时钟、各 role 已信版本、远端候选版本和第一个失败角色。root 失败检查是否恰为下一版、旧/新双 threshold、key ID 和过期；timestamp 失败检查在线 key、过期与 snapshot meta；snapshot 失败检查 targets/delegated 版本、hash、length；目标失败检查授权 path、最终 length/hash。
目标“明明存在却找不到”通常不是下载问题。沿顶层 targets 的 delegation 数组按 preorder depth-first 顺序展开，记录每层 path 是否匹配、threshold 是否满足、是否遇到 terminating、是否触发 cycle/role 访问上限。直接请求 target URL 得到 200 只证明文件存在，不能证明它被当前 metadata 授权。
大量客户端同时报 freeze 时，先区分 timestamp 签名服务停摆、发布任务没有切最终 timestamp、CDN 缓存旧对象、可信时钟偏移和攻击者隐藏更新。修复是恢复签名/发布/缓存和时钟，再发布合法更高版本；不能延长已经发布的旧 metadata 或关闭过期检查。只在单个客户端失败则检查状态目录权限、磁盘满、半写临时文件和并发 updater。
出现 rollback 或 fast-forward 提示时保留异常 metadata 和 key 事件证据。合法版本下降通常意味着仓库从旧备份恢复、镜像落后或错误重用版本号；异常高版本则可能是在线 key 泄露。前者重新发布更高合法版本，后者通过 root 轮换 key 并执行规定的状态恢复。任何情况下都不把本地版本手工改小。
权限、敏感数据与审计要围绕 role 分权
root、targets 和 delegated role 私钥决定长期授权，应离线、分人或分 HSM 保护；timestamp/snapshot key 在线也要最小权限、轮换和审计，不能访问 root key。threshold 的组织价值来自独立故障域，若多把 key 位于同一 runner、同一 secret 或同一管理员账户，数字上的多签无法抵御单点失陷。
bootstrap root 的真实性和只读性、客户端 metadata cache 的完整性与单写者约束同样敏感。Repository URL、mirror token、签名服务凭据、HSM PIN、CI OIDC token、离线 ceremony 介质和备份密钥都不进入 metadata custom 或日志。targets metadata 的 path、版本和依赖信息可能暴露软件清单，客户端请求也可能泄漏安装分布；TUF 不以隐藏这些信息为目标，需要额外访问控制和隐私设计。
审计事件至少包含 role、metadata version、签名唯一 key IDs、旧新文件 digest、target hashes、发布批次、审批主体和客户端拒绝原因。离线 ceremony 的输出通过只写介质或受控导入区进入在线仓库，导入端再次验证 threshold 和文件 digest。签名者不能直接发布 timestamp，在线发布者不能修改 root 授权，客户端运维也不能无审计替换 bootstrap。
容量、成本与 HA 取决于元数据图和发布扇出
容量模型包含 target 数、每个 targets role 的条目数、delegation 数和深度、metadata 字节、签名数、consistent snapshot 产生的版本化对象、镜像/CDN 副本、客户端状态和审计保留。大而单一的 targets metadata 会让每次小更新都重下载；过度分片则增加 snapshot 条目、委派搜索请求和签名 ceremony。应从真实客户端访问路径压测，而不是只统计 JSON 文件数量。
客户端限制单 metadata 大小、单轮 root 更新数、访问 delegated role 数、总下载字节、并发数、重试预算和超时。监控 timestamp 剩余有效窗口、root/targets ceremony 延迟、发布批次原子性、CDN 水位、refresh p95/p99、各角色失败率、rollback/freeze 告警和状态目录写入失败。阈值和有效期是安全与可用性的联动参数，变更前用断网、时钟偏移、在线 key 故障和镜像延迟演练。
仓库 HA 要保证对象存储、签名服务、发布协调、镜像和 DNS 的故障域，但 timestamp 只能由一个逻辑发布权威推进。两个区域独立递增同一角色版本会产生分叉；应由主发布序列化，备用接管时先读取最后权威状态。客户端多副本各持独立 cache，避免共享目录竞争；边缘代理模式则由代理成为单写者并向本机应用提供只读已验证结果。
成本不仅是存储目标文件，还包括离线签名 ceremony、HSM/KMS、在线签名可用性、CDN 请求、版本化对象保留、跨区复制、客户端状态备份、日志和恢复演练。托管系统的配额与价格属于实现选择，采购时读取当前服务说明，不把某个演示部署的免费额度写成架构假设。
升级、迁移、回滚与退出要保持协议状态连续
升级客户端库前保存代表性仓库 fixture：多版 root、threshold 不足、过期 timestamp、回滚 snapshot、深层/terminating delegation、mix-and-match、篡改 target 和大 metadata。候选版本从同一 bootstrap 与持久状态副本刷新，比较接受的 role/version、请求顺序、目标查找和失败分类。状态副本只能用于隔离测试，不能让两个 updater 同时写生产目录。
仓库实现从 Python、Go、Rust 或托管系统之间迁移时，必须保持 metadata 格式与 POUF、canonical serialization、key IDs、root 版本链、consistent snapshot 命名、delegation 顺序、threshold 和客户端缓存兼容。先让新系统从现有权威 metadata 导入，只读生成候选，使用多种客户端双读验证；再由单一写者推进一个新版本。回滚切回旧系统时，旧端必须先导入迁移期间产生的更高版本，不能从旧备份继续发低版本。
角色或 key 迁移遵循授权层级：root 用逐版本双 threshold，delegated key 由直接委派者的新 metadata 撤销，timestamp/snapshot key 经 root 更新并触发客户端相关状态恢复。调整 delegation 顺序或 terminating 属行为变更，即使 schema 不变也要重放目标集合，确认没有合法 target 变得不可达。
退出 TUF 时先停止新 target 写入，完成最终一致发布并等待客户端水位；导出 bootstrap 与完整 root 链、所有顶层/委派 metadata、targets、key ID 映射、序列化规则、状态迁移说明和审计。替代系统必须从相同 target hashes 建立新信任，再通过应用或设备渠道交付新 bootstrap。随后撤销旧签名服务、镜像写者、HSM/KMS 权限和仓库 token，保留只读归档直至旧客户端退出。最终反向证明是旧角色无法再发布可接受 metadata、旧客户端不会静默接受低版本，而归档链仍能解释历史目标为何被信任。