最近，我的經過密碼管理器開始花費 45 秒以上的時間來調出主密碼的 gpg-agent 密碼提示，當我嘗試登入網站並且必須坐在那裡盯著密碼提示一分鐘時，這非常煩人。
我開始做一些測試，發現 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 金鑰環引起的。新增
no-allow-external-cache至您的 gpg-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 用戶的事情並重新啟動了我的電腦（即使我在這裡運行 Linux），令人驚訝的是問題消失了。我猜想一定與另一個正在運行的進程有某種爭用問題。
如果這種情況再次發生，我會回來更新，並且我能夠確定具體的罪魁禍首是什麼。 gpg-agent列出的條目lsof似乎沒有表明任何可能的問題，我仔細檢查以確保沒有任何其他正在運行的代理或 GPG 進程。