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

[Jeffrey Stedfast]

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:

https://github.com/jstedfast/gmime/commit/57d16f7ca9ff76e2c46c518db43b6822a2ea075a

There is now a GMIME_VERIFY_DISABLE_ONLINE_CERTIFICATE_CHECKS flag that 
sets gpgsm into offline mode.

Question: Should this behavior be the default? I.e. should I invert the 
logic for DISABLE_ONLINE_CERTIFICATE_CHECKS into 
*ENABLE*_ONLINE_CERTIFICATE_CHECKS?

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?

Jeff

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
>      
>