Vor kurzem, meinpassierenDer Passwort-Manager benötigt inzwischen über 45 Sekunden, um die Passwortabfrage des GPG-Agenten für mein Master-Passwort anzuzeigen. Das ist extrem ärgerlich, wenn ich versuche, mich bei einer Website anzumelden und eine Minute lang auf die Passwortabfrage starren muss.
Ich habe mit einigen Tests begonnen und festgestellt, dass mit dem gpg2-Agenten etwas nicht stimmt. Wenn ich gpg1 ausführe, ohne dass ein Agent konfiguriert ist, ist es sehr schnell (einschließlich der Zeit, die ich zum Eingeben meines Passworts brauche):
$ time gpg -vvv -d BitBucket.gpg
real 0m2.940s
user 0m0.024s
sys 0m0.004s
Aber wenn ich gpg2 für dieselbe Datei ausführe (zur Verwendung von gpg2 ist ein Agent erforderlich), ist es wahnsinnig langsam:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m53.421s
user 0m0.000s
sys 0m0.004s
Doch nun, da der Agent mein Passwort zwischengespeichert hat, ist es wieder schnell:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m0.126s
user 0m0.004s
sys 0m0.000s
Es ist nicht die Entschlüsselung, die langsam ist – wenn die Passwortabfrage endlich erscheint, erfolgt die Entschlüsselung in einer mehr oder weniger normalen Zeit. Es ist nur so, dass der Agent ewig braucht, um die Passwortabfrage zu laden und anzuzeigen.
Die ausführlichen Protokolle liefern nichts Nützliches. Die Ausgabe sieht folgendermaßen aus (irrelevante und/oder vertrauliche Informationen werden ersetzt durch <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
Ich habe versucht, den Computer gpg-agentmit der --log-filein der Manpage beschriebenen Option zu beenden und manuell neu zu laden, in der Hoffnung, eine Erklärung dafür zu erhalten, warum es so lange dauerte, aber nachdem ich mehrere Entschlüsselungsvorgänge durchgeführt hatte, war die einzige Zeile, die jemals gedruckt wurde:
2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started
Was offensichtlich nicht sehr hilfreich ist!
Ich habe versucht, das pinentry-programin meinem zu ändern ~/.gnupg/gpg-agent.conf, aber verschiedene GUIs verhielten sich ähnlich.
ich fanddieser Thread, aber dabei scheint es um die Verschlüsselung zu gehen (die aufgrund fehlender Zufälligkeit plausibel blockieren würde, aber echte Zufälligkeit scheint keine Voraussetzung für das Starten des GPG-Agenten zu sein).
Ich fand auch eineFadendarüber, --check-trustdbdass es langsam ist und manchmal bei jedem Befehl ausgeführt wird, aber ich habe --check-trustdbes selbst ausgeführt und es wurde ohne wahrnehmbare Verzögerung abgeschlossen:
$ time gpg2 -vvv --check-trustdb
real 0m0.009s
user 0m0.008s
sys 0m0.000s
Irgendwelche Ideen, was ich als nächstes versuchen könnte, um der Sache auf den Grund zu gehen?
Antwort1
Das Problem hängt tatsächlich mit zusammen pinentry, aber nur indirekt. Es tritt nicht bei pinentry-*Implementierungen auf, die nicht versuchen, einen Keyring-Daemon abzufragen.
Der verwendete Daemon ist wahrscheinlich gnome-keyring-daemonder Grund für das Hängenbleiben (es gibt übrigens noch ein paar andere Implementierungen von Keyrings). Von einemGPG-Fehlerbericht:
Die Verzögerung wird dadurch verursacht, dass der Pinentry den GNOME-Schlüsselbund abfragt. Fügen Sie dies
no-allow-external-cachezu Ihrer gpg-agent.conf hinzu, reparieren Sie Ihre GNOME-Installation oder melden Sie das Problem den GNOME-Leuten.
Einige andere mögliche Lösungen:
killall gnome-keyring-daemon(wird beim nächsten Einsatz automatisch gestartet und bleibt möglicherweise nicht mehr hängen, kein Neustart erforderlich)- Deinstallation
gnome-keyringdes Pakets, wenn Sie es nicht verwenden
Antwort2
Auf meinem Debian-System wurde die lange Verzögerung, bevor GPG eine Passphrase-Eingabeaufforderung anzeigt, durch das Programm verursacht pinentry. Es war pinentry-gnome3standardmäßig auf eingestellt, und die Änderung auf pinentry-cursesscheint das Problem behoben zu haben.
Mir fällt in Ihrer Frage auf, dass Sie sagen, dass sich verschiedene GUIs pinentry-programähnlich verhalten. Außerdem verschwand das Problem nach einem Neustart, sodass Sie wahrscheinlich ein anderes Problem hatten. Ich habe diese lange Verzögerung im Laufe der Jahre auf einigen Systemen festgestellt, und in einigen Fällen hat ein Neustart nicht geholfen. Daher werde ich diese Antwort aufzeichnen, falls jemand anderes sie nützlich findet.
Um das Problem zu beheben, habe ich diesen Befehl ausgeführt und Folgendes ausgewählt pinentry-curses:
sudo update-alternatives --config pinentry
Bei Nicht-Debian-Systemen können Sie prüfen, mit welchem System ein symbolischer Link besteht /usr/bin/pinentry:
ls -l /usr/bin/pinentry
Die Aktualisierung könnte etwa so aussehen:
sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry
Gehen Sie vorsichtig vor, insbesondere wenn /usr/bin/pinentryes sich nicht um einen symbolischen Link handelt. Ihre Distribution bietet hierfür möglicherweise eine andere Möglichkeit.
Nach dem Aktualisieren auf „verwenden“ pinentry-curses(oder pinentry-tty) verschwindet die lange Verzögerung.
Antwort3
Ich war ratlos und habe den Windows-Benutzermodus verwendet und meinen PC neu gestartet (obwohl ich hier Linux verwende), und überraschenderweise war das Problem verschwunden. Ich vermute, es muss eine Art Konflikt mit einem anderen laufenden Prozess gegeben haben.
Ich werde zurückkommen und ein Update durchführen, wenn dies erneut passiert und ich den konkreten Übeltäter identifizieren kann. Die lsoffür den GPG-Agenten aufgelisteten Einträge scheinen keine wahrscheinlichen Probleme zu vermuten, und ich habe doppelt geprüft, ob keine anderen Agenten oder GPG-Prozesse ausgeführt wurden.