自動ビルドプロセスにより、プレースホルダーのタグからイメージが公開されました。メンテナーによると、イメージは差し替えられ、すべてのタグから誤ったマニフェストへの参照が削除されました。しかし、不具合のあるイメージを保持している運用者は、起動時に表示されるバージョンだけでパッチが適用されたと確認することはできません。
8月28日のリリースでは、ソースの公開に14日間のエンバーゴが設定され、9月11日に開示する予定が示されました。9月8日時点で、告知ではその公開は引き続き今後の予定とされています。メンテナーによると、この遅延によって、攻撃者になり得る者が修正内容をリバースエンジニアリングする前に、運用者がアップグレードする時間を確保できます。
Lightningのバグを修正するためのDockerイメージの確認方法
メンテナーは、以前に4つのタグのいずれかを取得した人に対し、イメージを識別するハッシュであるダイジェストを、修正済みの値と照合するよう求めています。
標準のバージョン付きイメージについて、告知ではローカルイメージを調べるために次のコマンドが示されています。この出力だけでは、既存のコンテナがどのイメージを実行しているかは確認できません。
docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7
ダイジェストが異なる場合、対応するイメージのダウンロードコマンドは次のとおりです。
docker pull elementsproject/lightningd:v26.06.7
告知では、このタグ用としてdocker pull elementsproject/lightningd:latestも示されています。VLSユーザーは、表にある別個のVLSダイジェストを使う必要があります。また、VLS_CLN_VERSIONの設定もv26.06.7と一致していなければならず、一致しない場合はremote_hsmd_socketが起動を拒否します。署名者自体は引き続きVLS v0.14.0です。
v26.06.6以前に固定していたユーザーは、このパッケージング上のミスを免れていました。この免除が対象とするのは不具合のあるパッケージングであり、新たなセキュリティ修正はv26.06.7に含まれています。
パッケージングの修正によって、運用者が直ちに直面する問題は、アップグレードを試みた後に再確認が必要となる可能性があるというものに変わりました。この猶予期間はまだ続いています。
エンバーゴ期間中には、別のダウンロード上の落とし穴もあります。GitHubが自動で添付するソースコードのアーカイブはv26.06.7のソースではないとメンテナーは警告しており、それらのアーカイブからビルドしても、告知されたパッチ適用済みバイナリは生成されません。