Sicherheitsmail III: GnuPG Made Complicated

Meine Neigung, technisch elegante Workflows zu implementieren, führt mich nicht selten auf Abwege. GPGME zum Beispiel is designed to make access to public key crypto engines like GnuPG or GpgSM easier for applications. Das klingt auf den ersten Blick sehr gut, wenn man die Einschränkung for applications nicht allzu ernst nimmt (was man aber tun sollte). Jedenfalls erhoffe ich mir eine aufgeräumtere .muttrc und die Nutzung von GnuPG für OpenPGP und S/MIME.

Vor die Kompilation einer Library haben die Entwickler allerdings den Patch und die Installation der Voraussetzungen (in diesem Fall pth und dirmngr) gesetzt, und GnuPG 2.0.20 enthält außerdem noch einen Mac-spezifischen Tippfehler. Nach erfolgreicher Installation müssen .bash_profile

export GPG_TTY=`tty` eval `gpg-agent --daemon`

und .muttrc

set crypt_use_gpgme = yes

ergänzt werden, weil mutt dank GPGME nicht mehr direkt mit gpg bzw. gpgsm kommuniziert, sondern über den gpg-agent. Die Verwaltung der qualifizierten bzw. vertrauenswürdigen Zertifikate (in qualified.txt und trustlist.txt) gestaltet sich etwas schwierig, aber vor allem erscheint pinentry nicht beim Import von Zertifikaten (obwohl gpg/gpgsm in anderen Zusammenhängen erfolgreich mit pinentry interagieren). Immerhin: Die Extraktion von X.509-Zertifikaten aus E-Mails klappt mit GPGME besser als mit openssl x509 -in %f -noout -email und bei der PGP-Schlüsselverwaltung verhält sich pinentry vorbildlich.

Das ist natürlich nur ein schwacher Trost. Wegen eines verflixten Bugs bleibe ich auf OpenSSL angewiesen und meine .muttrc ist nach wie vor nicht präsentabel. Um es im Jargon vieler Twitterer auszudrücken: Orr.