[gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Feb 2 20:24:32 CET 2018
On Fri 2018-02-02 13:13:32 -0500, Jeffrey Stedfast wrote:
>> * 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?)
i would rather not disable signature verification if we can do it
without metadata leakage.
> Well, I suppose that, like S/MIME signature verification, it would also
> disable PGP key-server lookups?
ah, right, i should be clearer about the use cases. I'm thinking right
now about the use of GMime for *reading* mail. (Maybe we can talk about
composing mail separately?)
Is there any point during mail reading that you expect GMime to trigger
a PGP keyserver lookup?
> 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).
gpgme_set_offline is actually per-gpgme_ctx_t:
-- Function: void gpgme_set_offline (gpgme_ctx_t CTX, int YES)
Sorry that i omitted that from the shorthand in my earlier message.
But how would i use that with GMime? As of GMime 3 i'm in the practice
of not not having to handle the GMimeCryptoCtx directly, because Gmime
does the Right Thing anyway :) -- i'd like to keep that nice behavior!
GMime should consider it as a new value for GMimeVerifyFlags? But i
notice that g_mime_multipart_encrypted_decrypt () only takes a
GMimeDecryptFlags, and it probably affects this too. I'll send a
separate message to gmime-devel about this.
> I'll wait for the GnuPG/GPGME devs to comment before making changes to
your message doesn't appear to have been let through to the gnupg-devel@
mailing list yet , so perhaps it's in moderation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Gnupg-devel