最近、私の合格パスワード マネージャーがマスター パスワードの gpg-agent パスワード プロンプトを表示するのに 45 秒以上かかるようになりました。これは、Web サイトにログインしようとしているときに、パスワード プロンプトを 1 分間見つめていなければならないときに非常に煩わしいものです。
いくつかテストをしてみたところ、gpg2 エージェントに問題があるようだということがわかりました。エージェントを設定せずに gpg1 を実行すると、非常に高速です (パスワードを入力する時間も含まれます)。
$ time gpg -vvv -d BitBucket.gpg
real 0m2.940s
user 0m0.024s
sys 0m0.004s
しかし、同じファイルに対して gpg2 を実行すると (gpg2 を使用するにはエージェントが必要)、非常に遅くなります。
$ time gpg2 -vvv -d BitBucket.gpg
real 0m53.421s
user 0m0.000s
sys 0m0.004s
しかし、エージェントがパスワードをキャッシュしたので、再び高速になりました。
$ time gpg2 -vvv -d BitBucket.gpg
real 0m0.126s
user 0m0.004s
sys 0m0.000s
遅いのは復号化ではありません。パスワード プロンプトがようやく表示されると、ほぼ通常の時間で復号化されます。エージェントがパスワード プロンプトを読み込んで表示するまでに非常に時間がかかるだけです。
詳細なログからは何も有用な情報は得られません。出力は次のようになります (無関係な情報や機密情報は次のように置き換えられます) <angle-bracketed text>。
$ gpg2 -vvv -d BitBucket.gpg
gpg: using character set 'utf-8'
<key parameters>
:pubkey enc packet: version 3, algo 1, keyid <X>
data: [2048 bits]
gpg: public key is <Y>
gpg: using subkey <Y> instead of primary key <Z>
[...here it locks up for 45-ish seconds and then pops up the agent prompt]
gpg: public key encrypted data: good DEK
<key parameters>
:encrypted data packet:
length: 200
mdc_method: 2
gpg: using subkey <Y> instead of primary key <Z>
gpg: encrypted with 2048-bit RSA key, ID <Y>, created 2012-03-07
<ME>
gpg: AES256 encrypted data
<key parameters>
:literal data packet:
mode b (62), created 1525637737, name="",
raw data: 151 bytes
gpg: original file name=''
<the content of the password file>
gpg: decryption okay
gpg-agent何がそんなに時間がかかっているのか説明を得られることを期待して、マニュアル ページに説明されているオプションを使用して強制終了し、手動でリロードしてみました--log-fileが、いくつかの復号化操作を行った後に印刷されたのは次の行だけでした。
2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started
それは明らかにあまり役に立ちません!
pinentry-programでを変更してみました~/.gnupg/gpg-agent.confが、異なる GUI でも同じように動作しました。
私は見つけたこのスレッドただし、これは暗号化に関するもののようです (ランダム性が欠如しているためにブロックされる可能性はありますが、gpg-agent を起動するために真のランダム性が必要になる可能性は低いようです)。
私も見つけた糸--check-trustdb遅いし、コマンドごとに実行されることもあるという噂がありましたが、--check-trustdb自分で実行してみたところ、目立った遅延もなく終了しました。
$ time gpg2 -vvv --check-trustdb
real 0m0.009s
user 0m0.008s
sys 0m0.000s
これを究明するために次に試すべきことは何ですか?
答え1
この問題は実際には に関連していますが、間接的にしか関連していません。キーリング デーモンを照会しようとしない実装pinentryでは発生しません。pinentry-*
使用されているデーモンがgnome-keyring-daemonハングアップの原因である可能性が高い（ちなみに、キーリングの実装は他にもいくつかある）。GPG バグレポート:
遅延は、pinentry が GNOME キーリングを照会することによって発生します。gpg
no-allow-external-cache-agent.conf に追加するか、GNOME インストールを修正するか、または GNOME の担当者に問題を報告してください。
その他の解決策としては、次のようなものが考えられます。
killall gnome-keyring-daemon(次回の使用時に自動的に起動され、ハングアップしなくなる可能性があります。再起動の必要はありません)gnome-keyring使用しない場合はパッケージをアンインストールする
答え2
私の Debian システムでは、GPG がパスフレーズ プロンプトを表示するまでの長い遅延はプログラムによって発生していましたpinentry。これはpinentry-gnome3デフォルトで に設定されていましたが、 に変更するとpinentry-curses問題は解決したようです。
質問を見ると、異なる GUI がpinentry-program同じように動作したと書かれています。また、再起動後に問題が解消されたとのことなので、おそらく別の問題に直面していたと思われます。私は長年にわたり、いくつかのシステムでこの長い遅延に遭遇しており、再起動しても改善されないケースもありました。そのため、他の方の参考になるかもしれないので、この回答を記録しておきます。
これを修正するには、次のコマンドを実行し、選択しましたpinentry-curses:
sudo update-alternatives --config pinentry
Debian 以外のシステムの場合は、どのシンボリックリンクが使用されているかを確認できます/usr/bin/pinentry。
ls -l /usr/bin/pinentry
更新すると次のようになります。
sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry
/usr/bin/pinentry特にシンボリックリンクでない場合は、注意してください。ディストリビューションによっては、別の方法でこれを行うことができる場合があります。
pinentry-curses（または）を使用するように更新するとpinentry-tty、長い遅延はなくなります。
答え3
困惑した私は、Windows ユーザーとして PC を再起動しました (ここでは Linux を実行していますが)。すると驚いたことに、問題は消えました。別の実行中のプロセスとの何らかの競合問題が発生したに違いないと思います。
この問題が再び発生し、原因が特定できたら、戻って更新します。gpg lsof-agent にリストされているエントリには、問題の可能性は示されていないようです。また、実行中のエージェントや GPG プロセスが他にないことを再度確認しました。