要約

  • ファームウェア5130は、既存のハードウェアプローブで次世代ファームウェアを可能にするopenwrt-hwprobe構成を追加した。一方、RIPE NCCの四半期計画ではOpenWrt対応全体はなお進行中である。
  • 公開資料には、生産用ブランチ、版番号の規則、世代別の公開鍵、リリースノート、更新ファイルのチェックサム表示、プローブごとのファームウェア版といった有効な統制がある。
  • それでも5130という表示だけでは、固定コミット、OpenWrtツールチェーン、成果物、署名、機器の適格性、展開結果、ロールバックを一続きに検証できない。
  • ビルド侵害、不正署名、更新失敗、障害、測定の破損を示す証拠はない。公開用の集計マニフェストと、端末単位の保護された展開台帳を組み合わせるべきだ。

数字が見える時には、判断はすでに終わっている

プローブが5130を報告する前に、複数の主体が別々の判断をしている。開発側は採用するコードを決める。ビルド環境はOpenWrtの版、SDK、フィード、設定、対象プロファイルを組み合わせる。署名主体は生成物を承認する。更新サービスは機器が対象かどうかを判定し、プローブはダウンロード、検証、再起動、再接続を行う。

この流れの最後に現れるのが版番号だ。版番号は検索キーとして優れているが、それ以前の判断をすべて証明するものではない。「どのコードか」「どのバイト列か」「誰の権限か」「どの機器向けか」「正常に測定できたか」は異なる問いである。

5130のリリースノートは、その違いをよく示している。この版は全プラットフォーム、ハードウェアプローブ、ソフトウェアプローブ、CIの変更を含む。ハードウェア部分では、既存機器上の次世代ファームウェアを可能にするopenwrt-hwprobeを追加し、分割されていた基盤を共通基盤へ移した。更新ファイルを調べやすくするチェックサム出力、アプリ更新の不具合修正、保存済み静的ネットワーク設定の復元も含まれる。

つまり5130は、ビルド方式、起動、登録、ネットワーク設定、測定処理に関わる変更を一つに束ねる名称である。公開上は合理的だが、個々のプローブの経路を再現するには粗すぎる。

「進行中」と「リリース済み」は矛盾しない

RIPE NCCの2026年第3四半期RIPE Atlas計画は、ファームウェア工程を合理化し、ハードウェアプローブ向けOpenWRTに取り組んでいると説明する。状態は「進行中」だ。

5130の記録は、計画の一部がすでにコードと公開リリースに達したことを示す。しかし、全ての既存プローブが次世代基盤へ移ったとは書いていない。ここで二択にすると事実を壊す。コードが出たから移行完了だと考えるのも、計画が進行中だから運用上の変化はないと考えるのも誤りである。

実際の配布には細かな状態がある。ソースがマージされる。生産用成果物が承認される。署名される。小さなカナリア群が対象になる。適格範囲が拡大される。端末が接続して更新を試す。健全性確認を通過する。必要なら配布が止まり、旧版へ戻る。

これらを区別すれば、オフライン端末を失敗と誤認せずに済む。意図的な延期や段階配布も統制として評価できる。ロールバックは失敗の隠蔽ではなく、正しく働いた安全機構として記録できる。

公開リポジトリには統制の部品がある

確認対象のコミットに固定したBUILD文書は、masterを生産準備済みブランチとし、ハードウェア用ファームウェアはそこから構築すると述べる。testing、devel、チケット用ブランチの役割も分ける。さらに、10で割り切れる版番号を生産リリースとする規則を示す。

この区分は有用だ。開発途中のコードを生産物と取り違えにくくし、番号の意味を共有できる。ただし、masterという名前が指すコミットは動く。過去のビルドを調べる時、ブランチ名だけでは同じソースを指せない。

同文書のOpenWrt手順は、その問題への答えも持っている。フィードは既定でmasterを参照する一方、ブランチや^commitで固定できる。実際に使ったコミットをリリース記録へ残せば、後から日付を手がかりに推定する必要はない。

固定したOpenWrt Makefileは、PKG_VERSIONをVERSIONファイルから取り、ソース一式をビルド領域へコピーする。またv3、v4、v5ごとに開発・試験・生産の公開鍵ファイルを含み、ハードウェア用パッケージはRIPE NCCの指示に従ってのみ導入すると明記する。

ここでは、コードの成熟度、リリースの身元、成果物の真正性、機器との互換性、運用上の許可が分離されている。いずれも版番号と関係するが、版番号に吸収してよいものではない。

ソースのコミットだけを固定しても足りない

アプリケーションのコミットが同じでも、OpenWrtのリリース、SDK、コンパイラ、パッケージフィード、パッチ、設定が違えば出力は変わり得る。従ってマニフェストには、固定コミットだけでなく、OpenWrtとSDKの識別子、依存関係の固定値、対象機器のプロファイル、構成、成果物とマニフェストのダイジェストを含める必要がある。

署名について公開すべきなのは秘密鍵ではない。生産用公開鍵の指紋または非機密の鍵クラス、承認した役割、対象成果物のダイジェストで十分に統制を示せる。

第三者がどんな環境でも完全に同じバイト列を生成できると約束する必要もない。まず必要なのは、同じリリース名が何を指す予定だったのかを固定し、二つの成果物が同一なのか、対象別に意図して異なるのかを判別できることだ。

5130のノートが更新ファイルのチェックサム出力を増やしたと記す点は象徴的である。整合性確認は外部が押し付ける事務作業ではなく、更新をデバッグするために既に価値がある。提案する記録は、その考え方をビルド、署名、配布、受領へつなぐだけでよい。

一斉更新という瞬間は存在しない

プローブ管理の説明では、接続したプローブは「おそらく」最新ファームウェアへ更新し、所定の測定を開始するとされる。詳細画面には版が表示される。公開プローブAPIにはfirmware_versionフィルタもある。

この可視性は重要だが、「おそらく」という語は現実を残している。全機器が同時にオンラインになるわけではない。世代ごとに対象条件が異なる可能性がある。カナリア配布、延期、再試行、停止、ロールバックもあり得る。リリース日を全端末の移行日とみなしてはならない。

だからといって、端末ごとの失敗時刻や設置先を公開すべきではない。ホストの特定や攻撃に役立つ恐れがある。記録は二層に分けるべきだ。

保護層では、端末識別子、ハードウェア世代、更新前後の版、成果物ダイジェスト、適格条件、試行と応答の時刻、検証、起動、再接続、測定試験、エラー分類、再試行、ロールバック権限、例外理由を結ぶ。

公開層では、十分に大きな世代・群ごとに、適格、試行済み、成功、延期、失敗、ロールバックを集計する。観測期間、母数の定義、試験の版、現在のリリース状態、例外、後継版を示す。

母数は特に重要だ。「99%更新」と発表しても、オフライン機器、対象外世代、意図的延期をどう扱ったか不明なら再検証できない。「失敗ゼロ」も、試行されなかった機器を除外した数字なら別の意味になる。

起動成功と測定可能は違う

RIPE Atlasプローブの目的はOSを起動することではなく、測定結果を作ることにある。従って受け入れ状態は、少なくとも「導入済み」「再接続済み」「測定検証済み」に分ける必要がある。

試験には、署名検証、端末識別の継続、ネットワーク設定の復元、コントローラ再接続、時刻動作、DNS、ping、traceroute、そして今回変更した機能を含められる。悪用につながる具体的な対象や閾値は保護してよい。公開すべきなのは、試験スイートの版、合否規則、集計結果である。

ロールバックも明示的な状態とする。何が閾値を超え、誰が判断し、どの群を止め、当該期間の測定に注記が必要かを残す。ロールバックが発生した事実だけを失敗とみなすべきではない。説明可能なロールバックは運用能力の証拠になる。

求めるのは手書き報告ではなく、自動生成される接続

RIPE Atlasはファームウェア索引、詳細なリリースノート、GitHub上の5130リリースを公開している。リポジトリにはブランチ規則、機器世代、公開鍵クラスがあり、運用側には版フィールドがある。新しい用語を発明する必要はほとんどない。

欠けているのは、それらを安定して結ぶ機械可読なマニフェストだ。ビルドと展開のシステムから自動生成すれば、エンジニアが後から長文を書く必要はない。緊急更新なら、版、コミット、成果物、署名クラス、承認権限という最小記録で開始し、定めた期間内に群別結果を追記できる。

公開資料だけでは、RIPE NCC内部にSBOM、ビルド証明、署名ログ、カナリア規則、端末台帳が存在しないとは言えない。本稿もそう主張しない。問うのは、測定利用者が版を解釈するための公共的な接続がどこまで必要かである。

共通基盤は保守を速くし、同時に共通の誤りが届く範囲を広げ得る。速さを捨てるのではなく、速さが説明可能であるための記録を同じ工程から生成するべきだ。

出典