摘要

  • RIPE NCC 表示，rpki.ripe.net 的 rsync 服务在 10 月 2 日一次软件更新后不可用。该组织从 rsync-3.1.3-28.el8_10.x86_64 回退，随后称降级软件包解决了问题。
  • 公开事故记录指出了受影响的仓库服务和修复措施，但没有披露依赖方数量、获取失败次数或验证后果。服务恢复并不等于已测得客户端影响。

分析

RIPE NCC 状态页于 10 月 2 日 09:45 CEST 建立事故记录，称 rpki.ripe.net 的 rsync 服务在软件更新后不可用。六分钟后，RIPE 报告已从 rsync-3.1.3-28.el8_10.x86_64 回退，并称问题得到缓解。10:57 的更新说，降级软件包解决了事故。这些时间点描述了公开状态更新，并不能确定实际影响的精确起止时间，也不能说明每个客户端多久无法取得对象。

这个仓库承载的是运行所需数据。RIPE 的说明称其中包含证书、清单、路由起源授权（ROA）及其他 RPKI 对象，供依赖方验证器软件使用。RFC 8182 将 rsync 描述为已有的仓库同步方式，并定义了另一种基于 HTTPS 的 RRDP 分发机制。但两种机制同时存在，并不能证明某个验证器实际使用了哪一种、是否切换到另一种，或此次事故期间是否出现验证失败。

RIPE 的结案说明还提到，将审查补丁策略，因为软件包安全更新可能包含影响生产服务行为的变化。这不是漏洞披露，也不是恶意活动证据，而是对生产仓库依赖软件包变更风险的确认。安全更新仍可能需要针对依赖服务的兼容性验证。

稍后查看的状态页将 rsync Repository 与 RRDP Repository 两个组件均标为 Operational。这只能确认查看时的状态标签，不能追溯计算漏取了多少数据，也无法说明依赖方的本地副本是否始终保持最新。事故条目没有发布客户端数量、错误率、对象新鲜度、验证结果或客户端侧恢复证明。

可由证据支持的结论应保持有限：软件更新之后，RIPE 指定的 rsync 服务不可用；软件包回退先缓解、继而解决了所报告的问题；RIPE 将复核补丁做法。公开记录没有量化验证器是否发生同步失败或延迟。缺失的影响分母，正是明确的运维恢复与完整的下游影响说明之间的差别。

来源