notmuch/util/gmime-extra.c, branch 0.26.2 thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.26.2 2017-12-09T00:35:18Z crypto: signature verification reports valid User IDs 2017-12-09T00:35:18Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2017-12-08T20:09:46Z urn:sha1:cb855d8a9d24084d0965790782c1ce04b82aa9ca When i'm trying to understand a message signature, i care that i know who it came from (the "validity" of the identity associated with the key), *not* whether i'm willing to accept the keyholder's other identity assertions (the "trust" associated with the certificate). We've been reporting User ID information based on the "trust" associated with the certificate, because GMime didn't clearly expose the validity of the User IDs. This change relies on fixes made in GMime 3.0.3 and later which include https://github.com/jstedfast/gmime/pull/18. util: make g_mime_utils_header_decode_date_unix match prototype 2017-07-17T11:47:18Z David Bremner david@tethera.net 2017-07-17T11:47:18Z urn:sha1:d2c3a0a3a849fdc8ce2f908b2c0d6e7197f07ae1 The problem shows up on 32 bit architectures where sizeof(time_t) != sizeof(gint64). Upcasting the 32 bit time_t to a 64 bit integer should hopefully be safe. cli: make keyid from fingerprint in gmime 3.0 2017-07-15T00:23:52Z David Bremner david@tethera.net 2017-06-02T23:57:01Z urn:sha1:2b3224a6c4be6b6c038a9956448187e0a402687b The "key_id" field seems to used for userid in gmime-3.0, while the keyid is dropped in the fingerprint field if the full fingerprint is not available. lib: wrap use of g_mime_utils_header_decode_date 2017-07-15T00:23:52Z David Bremner david@tethera.net 2017-05-17T01:59:54Z urn:sha1:c040464a7c8f339d15f691113b8f5fd901229bcb This changes return type in gmime 3.0 cli: generalize use of GMIME_SIGNATURE_{ERROR,STATUS} to gmime-3 2017-07-15T00:23:52Z David Bremner david@tethera.net 2017-05-14T17:49:31Z urn:sha1:c7b9bdb81e49321170dc6f0a522301f28e791521 The ERROR enum is merged into to the STATUS enum, and the set of flags is different. cli: replace use of g_mime_message_get_recipients 2017-07-14T20:58:09Z David Bremner david@tethera.net 2017-05-06T11:41:14Z urn:sha1:32819f74d3ac2eee25cf234d988688cc82ecbc0a This function, and associated enum, have been renamed and generalized in gmime-3.0. lib/cli: replace use of g_mime_message_get_sender 2017-07-14T20:58:09Z David Bremner david@tethera.net 2017-05-06T02:26:57Z urn:sha1:cbb2d5608ef6dd54d6e9e19b2bb570d3fe54b28b This function changes semantics in gmime-3.0 so make a new function that provides the same functionality in both cli: replace use of g_mime_message_get_reply_to 2017-07-14T20:58:09Z David Bremner david@tethera.net 2017-05-04T18:59:37Z urn:sha1:d7fea369160c548524fd8958ff88d6faacfabe3a This function changes signature in gmime 3.0, so we provide two new functions, one for each signature. cli: replace use of g_mime_message_get_date_as_string 2017-07-14T20:58:09Z David Bremner david@tethera.net 2017-05-04T12:48:44Z urn:sha1:67dbd24ece883e9cb0258fce289e40ca276b729d This function goes away in gmime-3.0. Also, the memory management is apparently error prone, witness the memory leak in notmuch-reply. util: convenience function to create gmime stream for stdout 2017-05-30T12:01:46Z David Bremner david@tethera.net 2017-05-27T16:51:11Z urn:sha1:1e7dbf7abcf58407a5171e9030056f2ff9bec15a It turns out that our use of GMimeStreamPipe has only succeeded because gmime has been ignoring some seek failures; this will no longer be the case in gmime 3.0, so we use a GMimeStreamPipe, which does not assume seekability, wrapped in a buffering stream.