Git の gpg が PATH で優先されるため OpenVPN のインストールが失敗する

Chocolatey 経由の OpenVPN インストールが署名または鍵のエラーで失敗する場合、通常はダウンロードの問題ではありません。パッケージは gpg を呼び出す検証ステップを実行し、Windows はその裸の名前を PATH を通じて解決します。Git for Windows が先にインストールされていると、同梱の gpg.exe が OpenVPN の期待する GnuPG ビルドより前に置かれ、間違ったプログラムが呼び出しに応答します。表示されるエラーは、その別のプログラムが訴えることに決めた内容であり、だから本当の原因が決して示されません。

PATH の順序がどの gpg を実行するかを決める

Windows には実行ファイル名の中央レジストリがありません。プロセスが完全なパスなしで gpg を要求すると、ローダーは PATH のエントリを順にたどり、最初の一致を実行します。Git for Windows は署名済みコミットを機能させるために usr/bin ディレクトリ内に最小限の GnuPG ビルドを同梱しており、そのインストーラーは通常そのディレクトリをユーザーの PATH の先頭付近に配置します。

GnuPG は独自のディレクトリ、通常は C:\Program Files (x86)\GNU\GnuPG\pub にインストールされ、そのエントリは一覧の後方にあるか、ユーザーの PATH から完全に欠けていることがあります。二つのプログラムは名前とコマンドライン界面の多くを共有しますが、状態は共有しません—Git のビルドは別の場所でキーリングを探し、バージョンが異なることがあり、インストーラーが渡すオプションを受け付けないこともあります。この不一致は署名または鍵のエラーとして現れ、それは間違ったバイナリが見た内容の正直な報告です。メッセージにはローダーを指すものは何もありません—ローダーは命じられたとおりに動いたからです。

どのシェルから開始するかが結果を決める理由

継承の規則こそが内面化する価値のある部分です。子プロセスはそれを起動したシェルの環境を引き継ぐため、重要なのは Chocolatey が起動した瞬間の順序であり、修正後の順序ではありません。

設定ウィンドウで PATH を編集し、同じターミナルでインストールを再実行しても何も変わらないことが多いのはそのためです—ターミナルが古い環境を保持していたからです。編集の後は必ず新しいシェルを起動し、再試行する前にその新しいシェルで where.exe gpg を使って確認してください。マシンレベルのエントリがユーザーレベルの変更を上回ることがあるのも同じ理由で、一部のインストーラーはマシンの PATH の先頭に追加し、マシンのエントリはユーザーのエントリより先に評価されます。両方のレベルに GnuPG のパスがある場合は、実際にどちらを維持しているのかを決めてください。

修正その一：エントリの順序を入れ替える

正確な修正は、意図した GnuPG ディレクトリを勝たせることです。ユーザーの環境変数を開き、Path を編集して、GnuPG の pub ディレクトリを Git のエントリより上へ移動します。その後、新しい PowerShell ウィンドウを開いてください—実行中のものはまだ古い一覧を保持しています。

別の方法は、インストール用の一時的なクリーン環境で、Git のエントリを外し、新しいシェルを開き、choco install openvpn を実行してから元に戻します。

どちらの方法も同じ理由で機能し、二番目は実際にエントリを戻した場合にのみ安全です。Git の usr/bin を PATH から削除すると署名済みコミットが永久に壊れ、動作する gpg を期待する次のツールは OpenVPN とは無関係な独自のメッセージで失敗します。一時的な方法を取る場合は、元の Path の値をチケットに残してください—復元が再構築ではなく貼り付けで済みます。エントリを並べ替えることが持続的な修正であり、削除は期限付きの回避策です。

確認してから元に戻す

Chocolatey が使用するのと同じユーザー コンテキストで、前後を確認してください。where.exe gpg はすべての一致を解決順に一覧表示するので、最初の行が実際に実行されるものです—Get-Command gpg -All は PowerShell で同じ答えをより詳細に示します。その後、gpg --version でどのビルドが応答したかを確認します。

where.exe が依然として Git のコピーを最初に一覧表示するなら、並べ替えはそのセッションに届いておらず、何度再インストールしても役に立ちません。マシンとユーザーの両方の PATH を [Environment]::GetEnvironmentVariable('Path','Machine') で、そして 'User' で同じ呼び出しを確認してください—有効な一覧は両方から組み立てられるからです。インストールに成功した後は、openvpn --version で再確認し、サービスまたは GUI を一度起動してください—パッケージがきれいにインストールされても、起動しないサービスが残ることがあるからです。

正しく並べ替えた PATH でも失敗する場合、残る変数はパッケージのバージョンです。固定された Chocolatey パッケージは、お使いのマシンにない特定の GnuPG ビルドやインストール パスを期待している可能性があります。

パッケージ自身のログを読む前に、他の何かを変更しないでください。C:\ProgramData\chocolatey\logs\chocolatey.log は失敗したコマンド ラインと、それが実行されたディレクトリを記録しており、失敗した呼び出しが署名チェック、抽出、インストール後のスクリプトのどれだったかを教えてくれます。この区別が、そもそもまだ gpg をデバッグしているのかを決めます。

繰り返しを防ぐ習慣は、PATH をディレクトリの袋ではなく、文書化された順序を持つ共有状態として扱うことです。一般的なバイナリ名を含むツールをインストールしたら、次に開くシェルでそれが何を覆い隠しているかを確認してください。そして落ち着いた順序を書き留めてください—次のインストーラーがそこに追加し、次の人は何も変わっていないマシンで署名チェックが失敗する理由を不思議に思うからです。インストール前に where.exe を一度実行すれば、ループ全体を節約できます。