GPGME, gpgsm und mutt

[Jan Eden]

On Wed, Jul 10, 2013 at 04:28:55PM +0200, Werner Koch wrote:
> On Wed, 22 May 2013 22:32, net at janeden.net said:
> 
> > verschlüsselte Nachricht zwischen meinen beiden Mail-Accounts versende,
> > akzeptiert gpg nur die Passphrase des *Absenders* zum Entschlüsseln der
> > Nachricht (encrypt_to in gpg.conf ist auf die ID des Absenderschlüssels
> 
> Ich verstehe nicht genau was Du hier meinst.

Die Frage hat sich erledigt: GnuPG greift natürlich auf den ersten
einschlägigen Schlüssel zurück, und das war in diesem Fall der des
Absenders.

> > der Import (mit der o.g. Fehlermeldung). Interessanterweise startet
> > pinentry-curses anstandslos, wenn ich ein OpenPGP-Schlüsselpaar
> > generiere oder in mutt meine Passphrase beim Signieren eingeben muss
> 
> Kannst Du das Ganze bitte einmal in einem xterm testen, so das eine GUI
> Version des Pinentries benutzt wird?

Leider nicht, ich nutze OS X, mein Terminal simuliert ein xterm, aber
ich habe kein echtes xterm zur Verfügung.

Das Problem bleibt jedenfalls bestehen:

localhost:~ gpgsm --import ~/mycert.p12 
gpgsm: enabled debug flags: hashing
gpgsm: no running gpg-agent - starting one
gpg-agent[1677]: enabled debug flags: command mpi crypto memory cache memstat hashing assuan
gpgsm: gpg-agent[1680]: enabled debug flags: command mpi crypto memory cache memstat hashing assuan
gpgsm: gpg-protect-tool: error while asking for the passphrase: Invalid IPC response
gpgsm: error running `/usr/local/libexec/gpg-protect-tool': exit status 2
gpgsm: total number processed: 0
secmem usage: 0/16384 bytes in 0 blocks

gpg-agent.log enthält:

2013-07-12 14:27:39 gpg-agent[1680] starting a new PIN Entry
gpg-agent[1680]: chan_8 <- OK Your orders please
2013-07-12 14:27:39 gpg-agent[1680] DBG: connection to PIN entry established
gpg-agent[1680]: chan_8 -> OPTION grab
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> OPTION ttytype=xterm-256color
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> OPTION lc-ctype=UTF-8
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> OPTION default-ok=_OK
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> OPTION default-cancel=_Cancel
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> OPTION default-prompt=PIN:
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> GETINFO pid
gpg-agent[1680]: chan_8 <- D 1681
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_6 -> INQUIRE PINENTRY_LAUNCHED 1681
gpg-agent[1680]: chan_6 <- END
gpg-agent[1680]: chan_8 -> SETDESC Please enter the passphrase to unprotect the PKCS#12 object.
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> SETPROMPT Passphrase:
gpg-agent[1680]: chan_8 <- OK
gpg-agent[1680]: chan_8 -> [[Confidential data not shown]]

pinentry sollte also erscheinen (und der Prozess befindet sich laut
Terminal auch zeitweise im Vordergrund), aber es wird nicht sichtbar.

> > (Frage am Rande: In .muttrc kann ich ein Timeout für Passphrasen
> > angeben – ist das auch mit GPGME möglich?).
> 
> Neuere Pinentries haben zwar ein timeout feature, das wird aber momentan
> noch nicht benutzt.

Die Option in muttrc ist etwas irreführend benannt: Es geht um den
Zeitraum, in dem eine Passphrase gecachet wird (z.B. 5 Minuten), um sie
für folgende Signaturvorgänge nicht erneut eingeben zu müssen.

> > signiert wurden, nicht verifizert werden, solange GPGME genutzt wird.
> > OpenSSL verifiziert die Signaturen.
> 
> Ich vermute eine Regression in Mutt.  Den Code in Mutt aber ich vor
> Urzeiten geschrieben.  Das müsste man sich mal genau ansehen - ich habe
> dafür aber keine Zeit.  In gpgsm.conf "debug 512" eintragen.  Dann werden
> Debugdateien erzeugt, mit den Daten die signiert werden - das wird
> schnell den Fehler aufzeigen.

Das Problem hat sich auf wundersame Weise erledigt: Die Signaturen
werden jetzt verifiziert (obwohl ich nichts gemacht habe™).

Es bleibt also nur das Verhalten von pinentry in bestimmten Kontexten.
Falls es aktuell keine offensichtliche Lösung gibt, nutze ich für S/MIME
einfach weiterhin OpenSSL.

Vielen Dank und herzliche Grüße
Jan