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

[Jeffrey Stedfast <fejj gnome org>]

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 gnome org on 
> behalf of dkg 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
>