暗号ライブラリの名前を変えても古いクライアントは直らない

ローダーのエラーは順番に確認する。どのファイルが欠けているのか、バイナリはどのアーキテクチャを使っているのか、どのシンボルを求めていたのか、そして失敗はプロセス起動の前か後か。これは四つの別々の問題であり、シンボリックリンクが扱えるのは最初の一つだけだ。順番に進めれば、クライアントが起動した直後に最初のハンドシェイクで失敗するというよくある結末を避けられる。チェックリストの最後は手動テストではなく、実際のランチャーを通した検証で締める。

何かを変更する前に、実行ファイルのパス、そのアーキテクチャ、そして最初のエラーをそのまま記録する。

一つのエラーの裏にある四つの異なる失敗

共有オブジェクトの欠落はファイル解決の問題だ。ローダーは名前を探して何も見つけなかった。シンボルの欠落はインターフェースの問題だ。ファイルは存在するが、バイナリが参照するものをエクスポートしていない。シンボルバージョンの不一致は同じ分類で、より詳しい情報が付く。起動後に報告される未対応アルゴリズムは、正常に読み込まれたライブラリ内部の挙動変化だ。それぞれ対応が異なり、名前の問題であるのは最初の一つだけだ。

lddをバイナリに対して、そしてreadelf -dをその動的セクションに対して実行すると、何を要求しているかが分かる。これだけでファイルの問題とインターフェースの問題を切り分けられることが多い。

OpenSSL 3 が実際に要求するもの

OpenSSL 3 の移行ガイドは明快だ。以前のバージョン向けにビルドされたアプリケーションは少なくとも再コンパイルが必要で、ソース互換性は保証されない。インターフェースは変わり、いくつかは非推奨または削除された。ファイル名の別名は再コンパイルを行えず、古いバイナリに新しいインターフェースを教えることもできない。新しいライブラリを古く見える名前でリンクすると、起動はできても、はるかに分かりにくい場所で失敗するプログラムができあがる。

それは明確な失敗より悪い。ローダーのエラーは問題を即座に名指しするが、操作の途中で遅れて起きる失敗はネットワークや認証情報の問題に見え、調査を誤った方向へ送ってしまう。

ディストリビューションのライブラリが適切でない理由

一つのクライアントを満たすためにディストリビューションのライブラリを置き換えると、セキュリティ更新や既存のインターフェースに依存するものも含め、マシン上のすべてのプログラムの環境が変わる。古いライブラリをバイナリの隣にコピーするのは範囲が狭いが、それでも誰かが保守して修正すべき依存関係を作る。どちらも承認された互換性の道ではない。適用した当日に動いて見えたとしても同じだ。実験の後に残されたグローバルな別名はさらに悪い。なぜ存在するのか誰も覚えていないからだ。

実際の OS リリース、アーキテクチャ、ゲートウェイに対して、ベンダーがサポートするクライアントと依存関係の組み合わせを使う。一人の環境で動いたパッケージ形式は現在の正しい道を証明しないし、アーカイブされた手順は過去についての証拠にすぎない。

ランチャーを検証する。起動そのものではない

サポートされた置き換えの後は、通常のランチャーが何を解決するかを確認する。lddをインストール済みの実行ファイルに対して実行し、それが示すライブラリのバージョンと、サービスが渡す環境を見る。そのうえで意図した認証と実際の操作を一つ実行する。環境を変えた手動呼び出しは、自分のシェルが起動できることしか証明しない。利用者が実際に実行するのは、ランチャー、デスクトップエントリ、またはサービスユニットだ。

サポートされたビルドが存在しない場合は、VPN の管理者に代替案か移行の道を尋ねる。黙って別のプロトコルに切り替えたり、有名なベンダー名のクライアントならゲートウェイを満たすと決めつけたりするのは、失敗を直すのではなく移動させているだけだ。

一時的な互換性の取り決めが避けられない場合は、文書化し、そのバイナリに限定し、サポートされたビルドが届いたら削除する。