摘要

  • Rapport在2026年9月4日拆分出的一个RFC 9286场景，先建立成功缓存，再移除ca2.mft，并要求第二轮仍得到六条VRP，其中包括受影响CA实例先前缓存的两条。
  • 同一脚本明确写着验证器必须就缺失清单发出警告，但唯一的check_logfile行以#开头；在固定提交中，shell不会执行这项检查。
  • RFC 9286把两种行为分别规定：取回失败必须产生说明终止原因的警告，并建议通知人类操作员；与此同时，依赖方应在对象失效或成功刷新前继续使用该CA实例的缓存对象。
  • 因而，完整的验收记录至少要有两列：缓存究竟保留了什么，以及系统向操作员发出了什么可核验的语义事件。任何一列都不能替另一列作证。

六条仍亮着的路由来源

最有价值的测试往往不是制造最大声的故障，而是把系统推入一个外表平静、证据却已变旧的时刻。Rapport的这个场景正是如此。第一轮运行建立一个已知良好的状态：两个CA实例各贡献两条VRP，共四条。随后，脚本准备第二个状态，引入第三个CA实例，再把第二个CA的清单文件ca2.mft移走。它关闭HTTP取回后重新运行选定的依赖方，迫使验证器面对一个非常具体的问题：同一CA实例的清单暂时不可取回时，先前通过验证的对象是否还可继续使用。

第二轮预期不是四条，也不是只留下完全新鲜的对象，而是六条。第一CA的两条仍在，第三CA新加入的两条出现，第二CA先前缓存的两条也继续出现。测试由此钉住了一个重要的连续性属性：一个取回故障不应自动把同一CA实例最近一次成功验证的路由来源全部抹掉。对RPKI依赖方而言，这不是对坏状态的姑息，而是避免把仓库的暂时不可达误译为路由授权突然改变。

恰恰因为输出看起来可以保持完整，警告才不是装饰。脚本在六条VRP断言之前留下一句说明：验证器必须对缺失清单发出警告。下一行本来要以FORT的日志为对象做匹配，却被注释掉了。POSIX shell把这一行当作说明文字，而非命令；所以固定版本确实验证了保留后的输出集合，却没有通过这条路径验证警告出现。

这个判断边界必须保持狭窄。注释行并不能证明FORT或其他依赖方没有发出警告，也不能证明测试失败、预期VRP有误，或任何生产仓库发生过异常。它只证明：在所检查的Rapport版本里，这个同实例回退场景没有执行源码中紧邻结果检查的警告断言。我们也不知道维护者为何暂时注释它，是否在别处覆盖了相同语义，或何时会启用它。

RFC把连续性与告警写成两个动作

RFC 9286给出了理解这段测试的正确尺度。RPKI清单是与某个CA发布点相关联的证书、CRL及签名对象的已签名清单。一个发布点可以由多个CA实例共享，但每份清单只描述与其对应的CA实例。因此，故障处置不能只看目录路径是否相同；处理要按照CA证书SIA中的清单URI，逐个CA实例进行。

当清单无法取回时，规范先把这次取回判为失败，再把处理交给失败路径。在那条路径中，规范使用了两个不同的规范性动词。第一，失败必须产生警告，并给出该CA实例终止处理的原因；文档还建议把情况通知人类操作员。第二，依赖方应继续使用与同一CA实例关联的缓存对象，直到它们变陈旧，或下一次成功取回用新对象替换它们。

这些要求互相配合，却不是同一件事。缓存延续保护路由判断不被短暂的发布故障突然翻转。警告保护操作环境不把一组沿用的旧结果误认成一次完全新鲜的成功验证。前者回答“现在用哪组对象”，后者回答“为什么仍在用它们，以及谁需要注意”。六条VRP能够证明第一问的某个答案；它们的存在本身无法证明第二问已经传达到日志、指标、事件总线或值班屏幕。

这也是“绿色”最容易误导的地方。依赖方可能仍输出与正常轮次相同的VRP数量，网络侧没有明显跳变，自动化测试也通过数量比较，但此次输出的证据路径已经不同：其中一部分来自缓存，而不是本轮成功取得的清单。若验收只记录最终集合，运营团队就会失去区分“六条全都新鲜”和“六条中两条因取回失败而续存”的能力。

RFC给缓存留出空间，是因为立即丢弃可能产生更坏的错误。仓库稍后恢复时，取回问题或许自然消失；在此之前，沿用上次成功状态可以防止依赖方把有效路由误判为无效，或把本应无效的路由误判为有效。但这种连续性并不等于静默许可。它把安全从“立即终止”改成“有条件延续”，也把新责任交给可观察性：操作员应能知道条件发生了变化、缓存有多旧，以及下一次重试会在何时发生。

相邻测试展示了缺失的那一半

Rapport同一提交里还有一个很有用的对照场景。另一个测试改变CA证书以及SIA里的清单URI，让验证器面对的是破损SIA，而不是同一CA实例的清单短暂消失。该脚本实际执行了check_logfile警告检查；它预期受影响CA的VRP不再出现，同时保留兄弟CA和新CA的结果。

两段脚本的差异不能被夸大成产品评测，却足以说明测试框架具备两种表达能力。它能区分CA实例身份和发布点连续性，也能在至少一个相邻场景中对面向操作员的诊断进行断言。问题因此不是“Rapport能否检查日志”，而是同实例缓存回退的验收记录是否把这项能力接到正确位置。

相邻测试还提醒我们，警告不应脱离缓存决策单独存在。破损SIA场景和同实例缺失清单场景的输出策略不同：一个受影响集合被剔除，另一个受影响集合从缓存续存。两者都可能需要警告，但警告应说明其对应的CA实例、失败原因和采取的回退动作。若只匹配含“warning”的任意一行，测试也可能在错误的原因、错误的实例或错误的缓存处置下通过。

不要把FORT的一句话变成跨实现契约

启用被注释的行似乎是最直接的修补，但精确匹配某个产品的一句英文日志，容易把真正重要的保证缩小成标点、大小写和措辞的稳定性。Rapport面向多个RPKI依赖方时，更耐用的做法是定义语义事件，再为每个实现配置适配器。结构化事件、指标、系统日志或产品记录的诊断都可以成为证据，只要它们能回答同一组问题。

这个事件至少应包含：缺失清单这一原因类别；受影响CA实例的稳定引用；验证器选择继续使用缓存这一决策；缓存的年龄或新鲜度边界；事件严重性；发出时间；以及通知或升级的去向。实现可以用自己的词汇呈现这些信息，测试不必假装所有软件都应复制FORT的句子。相反，适配器负责把产品输出映射到Rapport的公共语义。

语义断言也应容忍合理差异而拒绝关键缺口。时间戳格式可以不同，消息顺序可以不同，产品名称可以缺省；但原因不能从“清单无法取回”退化为无上下文的普通错误，CA实例不能无法定位，缓存决策也不能靠操作员从最终VRP数量猜测。真正的跨实现兼容，不是把检查放宽到任何文本都算，而是把不可协商的信息与可变化的表达分开。

一张两列的验收回执

每次运行应留下与最终“通过/失败”不同的回执。第一列记录缓存决策：受影响CA实例的标识，当前证书及SIA指纹，上次成功取回时间，缓存对象集合或摘要，新鲜度截止点，本次失败原因，保留与移除的VRP差异，兄弟CA是否保持隔离，以及下一次重试安排。

第二列记录操作员信号：被匹配的语义原因，关联的CA实例，明确的回退说明，缓存年龄，严重性，事件发出时间，以及通知是否进入预定的日志、指标、值班或升级通道。回执还应保留两列各自的证据位置，使复核者能够看到数量断言来自哪里、警告断言又来自哪里。

这张回执避免两种常见的偷换。“VRP还在”不能简称为“操作员已经收到警告”；“日志里出现警告”也不能证明验证器保留了正确的对象集合。只有两列同时满足，测试才覆盖RFC所描述的完整故障姿态：控制面状态继续服务，但其新鲜度下降被清楚标记。

对缓存列而言，CA实例绑定尤其重要。RFC允许多个CA实例共享一个发布点，所以“同一目录里还有文件”并不足以证明缓存属于正确实例。证书和SIA指纹、上次成功结果以及兄弟CA隔离共同防止把一个实例的旧对象错误嫁接给另一个实例。对信号列而言，同一绑定则让值班人员知道哪个验证分支处在回退状态，而不是只收到一个无法行动的仓库级告警。

这项源码观察能说明什么

Rapport仍被LACNIC描述为早期阶段的依赖方测试项目。对早期工具而言，公开的测试脚本本身就很有价值：它们让外部读者看到规范如何被拆成可执行的场景，也让未完成的边界清晰可见。这里的价值不在于给工具或验证器打分，而在于发现一个可修订、可验证的验收缺口。

固定证据支持四项有限结论。其一，2026年9月4日的变更把RFC 9286场景拆成了“CA身份变化”和“同一CA实例回退”两种。其二，同实例测试明确要求缓存的两条VRP与其余四条共同存活。其三，脚本写明必须告警，但相关检查被注释，因此并未由这条脚本执行。其四，规范分别陈述告警和缓存延续，相邻测试也证明框架可以执行日志检查。

固定证据不支持对任何依赖方实际行为的裁决。它不说明某个运行是否真的沉默，不说明LACNIC把Rapport用于生产认证，也不说明被注释行背后的意图。最稳妥的下一步因此不是推断动机，而是让未来测试回执显示两个独立结果：缓存连续性通过或失败，操作员信号通过或失败。

资料来源