Re: decrypt and trusting certs

[re-sending w/ smaller screen shots]

Dear Michael:

Am 04.10.12 08:47 schrieb(en) Michael Diener:
I did have to adjust the build options as the Debian package does not natively support S/MIME. The weird part is that I am able to decrypt a few messages. I can't really determine what works and what not. I don't think that it's a problem with the package on a build level as everything else works (encrypting messages works too).

Are you sure this is necessary?  Please check first with

	sudo apt-get install gpgsm gnupg2 dirmngr gnupg-agent

if you have the proper versions of the basic tools (and all dependencies) installed.

If all tools are there, can you please try to run Balsa from a terminal, and put gpgme (which is the "glue layer" between balsa and gpgsm, which in turn handles CMS/smime) into debugging mode:

	GPGME_DEBUG=5:gpgme-balsa.log balsa

Then look into gpgme-balsa.log, if it gives you more insight.  If you want to debug the gpgsm operation itself, put a line reading

	log-file /home/my_home_dir/mygpgsm.log

into the file ~/.gnupg/gpgsm.conf, which will dump more information to this file.

Balsa will also print upon startup which crypto apps the gpgme library uses, like

** Message: init gpgme version 1.2.0
** Message: protocol OpenPGP: engine /usr/bin/gpg2 (home (null), version 2.0.17)
** Message: protocol CMS: engine /usr/bin/gpgsm (home (null), version 2.0.17)
** Message: protocol (null): engine /usr/bin/gpgconf (home (null), version 2.0.17)
** Message: protocol Assuan: engine /tmp/gpg-FalH4K/S.gpg-agent (home !GPG_AGENT, version 1.0)
** Message: gpg-agent found: /tmp/gpg-FalH4K/S.gpg-agent:2156:1
** Message: OpenPGP protocol supported
** Message: CMS (aka S/MIME) protocol supported

The other thing I noticed is, that there are a lot of certificates which are valid, but I apparently don't trust them (VeriSign, etc.). It would be nice if there would be an easy way to trust all the authorities in /usr/share/ca-certificates (or something along that line).

This is done by gpgsm/dirmngr which in turn tells pinentry to verify the certificate, if you have 'allow-mark-trusted' in your gpg-agent.conf file.  When I first saw your message, the two attached pinentry dialogues pop up.  If you accept them, signatures signed through this (root) cert are *always* trusted (green).

Note that you should have the options


in your ~/.gnupg/gpgsm.conf, so certificates are checked against the CRL's (this is however annoying if you work offline, i.e. without a chance to check the crl's).

AFAIK Balsa is using the user's GPG infrastructure (yours!) which is normally managed by some separate program, e.g. Seahorse in GNOME DE (can see as "Passwords and Keys" in app menu). So just do what you want in e.g. Seahorse and Balsa should normally "see" that.

Do not use the Seahorse agent.  That application is crap.  It has issues dealing with s/mime certs.  Just use gpg-agent and pinentry (in the flavour you like, typically pinentry-gtk2).  Be sure to have a proper ~/.gnupg/gpg-agent.conf file, like

debug-level none
default-cache-ttl 10800
pinentry-program /usr/bin/pinentry-gtk-2
lc-ctype de_DE.UTF-8		# use the proper locale for your environment
lc-messages de_DE.UTF-8		# ditto

I couldn't find out how Balsa is using my GPG infrastructure.

Have a look at the 'Ägypten' project page <>, and replace the yellow box reading 'mutt' by 'balsa'.  This gives the full picture for S/MIME.

For PGP/GnuPG, just replace GpgSM by gpg2.  Gpg2 basically has the same (blue) communication connections, with the exception of Dirmngr.  As it builds on the "web of trust", is has a different trust model which builds completely on the local key store and key servers on the web.

Hope this helps,

PNG image

PNG image

Attachment: pgpEtIMJteSfR.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]