notmuch/util/gmime-extra.c, branch feature/git-remote

cli/show: produce "email" element in sigstatus

2021-06-26T16:07:47Z

When the certificate that signs a message is known to be valid, GMime is capable of reporting on the e-mail address embedded in the certificate. We pass this information along to the caller of "notmuch show", as often only the e-mail address of the certificate has actually been checked/verified. Furthermore, signature verification should probably at some point compare the e-mail address of the caller against the sender address of the message itself. Having to parse what gmime thinks is a "userid" to extract an e-mail address seems clunky and unnecessary if gmime already thinks it knows what the e-mail address is. See id:878s41ax6t.fsf@fifthhorseman.net for more motivation and discussion. Signed-off-by: Daniel Kahn Gillmor

util: run uncrustify

2021-03-13T12:45:34Z

This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h in the util directory

Merge branch 'release'

2019-10-13T12:24:48Z

util: whitespace cleanup for 4c5b17b1

2019-10-13T12:18:24Z

Oops. This should make the merge back to master smoother.

util: unreference objects referenced by the returned stream obj

2019-10-12T11:45:55Z

We want freeing the returned stream to also free these underlying objects. Compare tests/test-filters.c in the gmime 3.2.x source, which uses this same idiom. Thanks to James Troup for the report and the fix.

util: run uncrustify

2019-06-14T10:41:27Z

This is the result of running $ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h in the util directory

util/gmime-extra: add g_mime_stream_gzfile_{new, open}

2019-05-03T10:48:38Z

These are usable as standard GMime streams, and transparently decompress gzipped files.

gmime-cleanup: remove GMime 2.6 variant codeblocks

2019-05-03T09:50:40Z

signed-off-by: Daniel Kahn Gillmor

crypto: signature verification reports valid User IDs

2017-12-09T00:35:18Z

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

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.