[gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG
fejj at gnome.org
Fri Feb 2 19:13:32 CET 2018
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
More information about the Gnupg-devel