notmuch/util, branch 0.25.3thread-based email index, search, and tagginghttps://git.notmuchmail.org/git/notmuch/atom?h=0.25.32017-12-09T00:35:18Zcrypto: 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.
util: make g_mime_utils_header_decode_date_unix match prototype2017-07-17T11:47:18ZDavid Bremnerdavid@tethera.net2017-07-17T11:47:18Zurn: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/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
cli: hide rename of GMimeCertificateTrust2017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-05-14T17:51:38Zurn:sha1:fd6e4a99535cb5142381803bc4ea4f4f79d8d459
Both the enum and the values are renamed in GMime 3.0.
cli: generalize use of GMIME_SIGNATURE_{ERROR,STATUS} to gmime-32017-07-15T00:23:52ZDavid Bremnerdavid@tethera.net2017-05-14T17:49:31Zurn:sha1:c7b9bdb81e49321170dc6f0a522301f28e791521
The ERROR enum is merged into to the STATUS enum, and the set of flags
is different.