Hermes AgentコミュニティがMatrixの暗号化状態の競合を報告、複数プロセスからの送信で以降のDMを復号できなくなる可能性

Hermes AgentのMatrix連携で、複数プロセス間の暗号化状態に関する信頼性の問題が報告された。10月18日、ユーザーは、ゲートウェイの実行中に同じプロファイルから別途 hermes send でメッセージを送ると、その後のボットからのDMを復号できなくなる可能性があると指摘した。エージェントが自ら起動したサブプロセスも、引き金になり得るという。報告環境はHermes 0.22.2で、操作手順と送信側のログが添えられている。現時点で問題は未解決のままだ。出典：問題報告

この問題を理解するには、Matrixの暗号化状態を2つの層に分けて考える必要がある。公式ドキュメントによると、Olmはデバイス間の暗号化通信に使われ、Megolmはルーム内のメッセージを暗号化する。新しいMegolmセッションキーは、デバイス間の安全なチャネルを通じて共有する必要がある。つまり、ルームメッセージがサーバーに正常に送信されても、受信デバイスが復号に必要なキーを取得できたとは限らない。出典：Matrixの暗号化実装ガイド

報告者によるコード分析では、コマンドライン側の処理が別のクライアントを作成し、ゲートウェイとデバイスIDおよび crypto.db を共有する。2つ目のプロセスがOlmの状態を更新して書き戻した後も、ゲートウェイがメモリ上の古いキャッシュを使ってルームキーを共有する場合があり、その結果、データベース上の状態とプロセス内の状態が食い違う可能性がある。注目すべき点として、送信側のログには共有成功と記録されるため、監視では受信側の障害を見落としやすい。ただし、この根本原因の見立ては、受信側のデバッグログがなく、メンテナーによる独立した確認もまだ得られていない。出典：根本原因の分析

チャットプラットフォームをエージェントの操作インターフェースとして使うチームにとって、これは実務上の課題となる。ヘルスチェックでは受信側がメッセージを読めることも確認し、変化し続ける暗号化状態をどのプロセスが管理するのかを把握する必要がある。報告者は、外部からの送信を実行中のゲートウェイに転送し、同じデバイスを使う暗号化クライアントを別途起動するのを当面避けるよう提案した。ゲートウェイの再起動後は以降のDMが復旧したが、過去のメッセージまで必ず復元されるわけではない。今後は、修正にプロセス間転送、状態ロック、競合状態のテストが追加されるか、また正式版でどのような導入環境が対象になるかを確認したい。出典：修正案と暫定対処