Hi Daniel & GnuPG devs,

On 2/2/2018 12:48 PM, Daniel Kahn Gillmor wrote:
Hi GMime and GnuPG developers--

sorry for the cross-posting!  coordinating this kind of thing
cross-project is tough.

I recently learned that default handling of signed S/MIME mail with
GnuPG causes an inherent metadata leak about the user's activity:


As a MUA developer, I'd like my MUA to simply handle as much crypto as
it can on the user's behalf automatically, correctly and silently,
without needing any special configuration or asking the user to make any
tough tradeoffs that they might object to.

What kinds of tradeoffs are objectionable?  Performance tradeoffs are
probably OK, since they're user-visible, and can be mitigated by
disabling crypto.  But metadata leakage by default seems really
problematic, because (a) it is invisible to the user, and (b) once done,
it cannot be undone.

So my question for GMime and GnuPG developers is how a MUA that uses
GMime should approach this.  Given that GMime relies on GnuPG, and GnuPG
basically says "if you process S/MIME mail, you'll leak metadata", what
is the best way to instruct GMime to say "handle as much cryptographic
mail as you can without leaking metadata"?

GMime 3 has greatly simplified its crypto handling interface, and it has
moved fully to GPGME on the backend, which i appreciate.  However, i
think the interface is now so clean that i don't know how to either:

  * tell GMime to disable crl checks

I'd be willing to add an API to disable CRL checks if there's a way I can pass that along to gpgme.


  * tell GMime not to verify S/MIME signatures at all

Willing to add an API for this as well (although I guess it's not necessary if an API to disable CRL checks is added?)

Either of these methods would address the default metadata leakage
concern, but the first choice provides more functionality to the user.

i note that GPGME offers gpgme_set_offline(), which tells it to avoid
talking to the network entirely.  Maybe that can be exposed by GMime


i don't think invoking gpgme_set_offline(true) would break other uses of
GPGME inside GMime or any other sensible MUA, but if there's a fear that
it does, i'd like to hear about it.

Well, I suppose that, like S/MIME signature verification, it would also disable PGP key-server lookups?

It might be best if there was a way to disable CRL checks on a per gpgme_ctx_t basis as opposed to globally, but I can have GMime use the global option until such an option exists (note: might be racey if you try and verify signatures on multiple threads).

I'll wait for the GnuPG/GPGME devs to comment before making changes to GMime.


gmime-devel-list mailing list

Reply via email to