Re: [gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG

[Daniel Kahn Gillmor <dkg fifthhorseman net>]

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.

thanks!

> >   * 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 
> GMime.

your message doesn't appear to have been let through to the gnupg-devel@
mailing list yet [0], so perhaps it's in moderation.

        --dkg

[0] https://lists.gnupg.org/pipermail/gnupg-devel/2018-February/

Attachment: signature.asc
Description: PGP signature