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

Jeffrey Stedfast fejj at gnome.org
Sat May 19 20:42:54 CEST 2018

I kinda dropped the ball on this a while back but due to the recent 
Efail news, I resurrected my patch and have now committed it:


sets gpgsm into offline mode.

Question: Should this behavior be the default? I.e. should I invert the 

I'm wondering if perhaps that might be more prudent.

Unfortunately, I think that means it opens the client up to other 
potential risks such as letting revoked certificates go undiscovered.

Comments? Suggestions?


On 2/3/2018 1:48 PM, Jeffrey Stedfast wrote:
> I've added code locally to set offline mode but reading the docs:
> https://www.gnupg.org/documentation/manuals/gpgme/Offline-Mode.html
> it suggests that setting offline mode only works for CMS and not OpenPGP? Can anyone from the GPGME team verify this? If so, I'll drop the flags that would indicate that this works in OpenPGP mode.
> Jeff
> On 2/2/18, 2:24 PM, "gmime-devel-list on behalf of Daniel Kahn Gillmor" <gmime-devel-list-bounces at gnome.org on behalf of dkg at fifthhorseman.net> wrote:
>      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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2018-February%2F&data=02%7C01%7Cjestedfa%40microsoft.com%7Ca93726fccf3341b635ba08d56a72a2c3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636531962953290821&sdata=31FiENC95WdhP0le8lNFj%2BMG92pmesnANJic2TFnzLA%3D&reserved=0

More information about the Gnupg-devel mailing list