notmuch/util/gmime-extra.h, branch 0.26thread-based email index, search, and tagginghttps://git.notmuchmail.org/git/notmuch/atom?h=0.262017-12-09T02:19:06ZMerge branch 'release'2017-12-09T02:19:06ZDavid Bremnerdavid@tethera.net2017-12-09T02:19:06Zurn:sha1:040c3236afcf95bead0324a48c2e0b9cd7934993
Conflicts:
NEWS
Add in NEWS from point release
crypto: signature verification reports valid User IDs2017-12-09T00:35:18ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-12-08T20:09:46Zurn: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.
gmime-extra: drop compat layer for g_mime_multipart_encrypted_decrypt2017-10-14T13:57:06ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-10-10T05:49:10Zurn:sha1:bcd6229d26c26e694b185fb8bf762bad606916c8
In practice, we're going to see this function invoked differently
depending on which gmime we build against. The compatibility layer
forces our code into the lowest-common-denominator -- unable to make
use of new features even when built against a newer version.
Dropping the compatibility layer paves the way for clearer use of
features from GMime 3.0 in future commits.
gmime-extra: remove duplicate GMimeAddressType typedef2017-10-13T01:12:32ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-10-10T05:49:06Zurn:sha1:30e33dfdd14bc65189d8561ce0022b9ffafad1c4
"typedef GMimeAddressType GMimeRecipientType" is already present
further down in the compatibility wrapper (with other typedefs). We
don't need it twice.
cli/crypto: eliminated compiler warnings about unused arguments2017-07-16T00:42:49ZDavid Bremnerdavid@tethera.net2017-07-15T23:01:44Zurn:sha1:606e320e472b486359cf7a44c488b29e717a3ac8
These are due to (excessively?) fancy macro definitions in gmime-extra.h
clean up use of constants in g_mime_multipart_ wrappers2017-07-15T00:23:52ZDaniel Kahn Gillmordkg@fifthhorseman.net2017-07-14T13:12:01Zurn:sha1:f76a245009b8db6065d83a0e86df697003f41b77
When compiling as C code (instead of C++) against gmime 3.0, gcc gives
errors like the following:
error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive]
so use explicit *_NONE values instead.
cli: wrap getting uid2017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-06-03T00:19:04Zurn:sha1:cd853915ec0ad3e3ee6ec90a7d856e95d001abe9
Apparently it moved from "name" to "key_id" in gmime-3.0
cli: make keyid from fingerprint in gmime 3.02017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-06-02T23:57:01Zurn: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: paper over allocation difference2017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-05-20T12:05:22Zurn:sha1:4ce7591610444a1c5ef6f56b57af8e180437fa62
In gmime 3.0 this function is "transfer none", so no deallocation is
needed (or permitted)
lib: wrap use of g_mime_utils_header_decode_date2017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-05-17T01:59:54Zurn:sha1:c040464a7c8f339d15f691113b8f5fd901229bcb
This changes return type in gmime 3.0