[gmime-devel] avoiding metadata leaks when handling S/MIME-signed mail in GMime and other tools that use GnuPG
Jeffrey Stedfast
jestedfa at microsoft.com
Sat Feb 3 19:48:26 CET 2018
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