要約

  • LACNICが8月10日に公開した手順書は、Ubuntu Server 26.04でfort-1.7.0.experimental.tar.gzを取得し、展開、設定、コンパイルしてsudo make installを実行するが、チェックサムや分離署名の確認を含まない。
  • リリースには7月16日の時点でtarball、.asc、fort.keyringがそろっていた。8月31日に取得した3ファイルはAPIのSHA-256と一致し、GnuPGは指紋8F9ABC7EF3BA565F9DF1578C72160FD57B242967についてGOODSIGとVALIDSIGを返した。
  • この結果は取得したtarballを強く支持する一方、鍵の権限までは証明しない。同じ隔離環境はTRUST_UNDEFINEDを返し、GitHub API上のリリースは観測時に非immutableだった。
  • 必要なのは、タグ、commit、assetのdigest、独立に信頼した鍵、ビルド入力、導入されたバイナリ、稼働開始とロールバックを一つの受領記録に結ぶことだ。

最も重いコマンドの前に、最も軽い確認がない

手順書の到達点はsudo make installである。これは単なる最後のコマンドではない。一般ユーザーの作業領域で作った成果物に、システムへ書き込む権限を与える境界だ。

そのため、直前までの丁寧さが目を引く。文書はUbuntu Server 26.04、amd64/x86_64、FORT 1.7.0.experimentalという環境を特定する。テストした.debはlibmicrohttpd12とlibxml2を要求し、Ubuntu側では異なる名前のパッケージが提供されるため、ネイティブな開発ライブラリを使うソースビルドを選んだと説明する。このパッケージ挙動は手順書の報告であり、今回の資料確認が独自に再現したものではない。

実行列はwgetによるtarballの取得、tar -xzf、./configure、make -j"$(nproc)"、sudo make installと続く。その後はfort --version、ldd、最初のvalidation、出力ファイル、service、RTR listener、時計同期を確認する。

だが、取得と展開の間にはSHA-256も、.ascも、keyringも、署名検証コマンドもない。スペイン語PDFで「署名」に当たる語が扱うのは署名済みRPKIオブジェクトであり、ダウンロードしたソフトウェアではない。リリースcommitに固定された上流のinstallation文書も、パッケージやtarballを取得して導入するだけで、digestや分離署名を確認しない。

fort --versionが成功しても、この欠落を遡って埋めることはできない。version stringは自己申告する識別子であり、権限を与えたファイルのdigestではない。

署名は手順書より先に用意されていた

GitHubの記録では、1.7.0.experimentalは2026年7月16日01:52:42Zに作成され、03:45:33Zに公開された。annotated tagはcommit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7eを指し、tag object APIは署名をvalidかつverifiedと報告する。

tarball assetは03:47:16Z、分離署名は03:47:19Z、fort.keyringは03:51:35Zに作成された。8月10日のLACNIC文書より前に、確認に必要な3点は同じリリース上に存在していた。

8月31日にAPIと取得ファイルを照合した結果は次の通りだ。

対象 SHA-256
tarball 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
.asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

別途取得した3ファイルはAPIの現在値と一致する。提供されたkeyringを一時環境にimportし、.ascでtarballをverifyすると、GnuPGはGOODSIGとVALIDSIGを返す。主指紋は8F9ABC7EF3BA565F9DF1578C72160FD57B242967、署名時刻は7月16日01:55:02Zだった。

この肯定的な事実は省略できない。調べた記録には、tarballが悪意あるもの、差し替えられたもの、誤ったものだという証拠はない。現在のAPI digestと一致し、提供された公開鍵に対して分離署名は数学的に有効である。RPKI validationの失敗やrouting incidentを示す材料もない。

同時にGnuPGはTRUST_UNDEFINEDを返し、一時環境では鍵が信頼済み署名で認証されていないと警告した。これはVALIDSIGの否定ではない。署名した秘密鍵とimportした公開鍵の対応は確認できたが、その鍵を誰が管理し、FORT releaseを署名する権限があるかは独立には確認していない、という境界である。

権限の受け渡しは四回ある

最初はtagからcommitへ。署名されたtagはc67d14b…への参照を裏付ける。しかしReleasesにuploadされたassetがそのcommitと同一内容かどうかは、asset側の確認事項だ。

次はrelease recordからasset bytesへ。APIはfilename、timestamp、現在のdigestを結ぶ。観測時にはimmutable: false、draft: false、prerelease: falseだった。非immutableは改変の証明ではない。観測時刻を添えて保存し、過去の全downloadを現在値で代表させないための条件だ。

三番目はassetからsigning keyへ。valid signatureは対応する秘密鍵の使用を示す。鍵の所有者と権限を判断するには、同じdownloadページとは独立に認証された指紋、rotation、revocationの情報が要る。tarball、署名、keyringを同じ場所から取ることは便利だが、それだけでtrust anchorにはならない。

最後はsourceからinstalled binaryへ。compiler、configure flag、header、dependency version、install pathが結果に関わる。lddはruntime linkを見せるがbuild inputをすべて保存しない。資料はbit-for-bit reproducible buildを主張しておらず、今回もそれを検証していない。

四回の受け渡しを一つの製品名で省略しないことが、sudoに権限を渡す際の最低限の統制になる。

受領票は複雑でなくてよい

展開前のblockには、release tagとcommit、assetの正確なURL、期待SHA-256と実測値、独立channelから得たfull fingerprint、.ascのverify結果を置く。不一致なら展開を止め、記録を残し、訂正を確認する。

導入後は以下を残せば、実務上の鎖ができる。

境界 保存する記録
release tag、URL、commit、公開時刻、観測時のimmutability
asset filename、URL、期待/実測digest、取得・検証時刻
signature .ascとkeyringのdigest、指紋、独立情報源、trust decision
build OS、architecture、compiler、configure flag、dependency version
install binary pathとdigest、version出力、設定/service fileのdigest
operation activation、previous version、rollback、key rotation/revocation、訂正履歴

この表はLACNICに全責任を集めない。FORT projectはreleaseを管理し、GitHubはdistribution surfaceを提供し、Ubuntuはdependencyを供給し、operatorは鍵とbinaryを信頼するか決める。LACNICが担えるのは、推奨手順の中でその境界を見えなくしないことだ。

文書にないことと、現場でしなかったことは違う

公開手順にverificationがないからといって、利用者が確認しなかったとは言えない。組織は内部mirror、固定digest、approved key、controlled build、binary approvalを追加しているかもしれない。

また、APIのimmutable: falseからassetが変わったとも言えない。現在のdigestは過去のすべてのdownloadを証明しない。提供されたkeyringで署名が良好でも、signerの法的identityや組織上の権限は独立に確定しない。

本件はASPA情報の出力やRTR version negotiationとも別である。それらはvalidatorからrouterに向かう出口の問題だ。ここで扱うのは入口、つまりその出力を作る実行ファイルにどの根拠で権限を与えたかである。

結論は限定的だが、修正可能だ。LACNICの手順書は導入後の動作をよく確認する一方、すでに公開されていた署名材料を導入前の統制に使っていない。一つのverify blockと一枚の受領票を足せば、危険を断定せずに権限移譲を監査可能にできる。

出典