| Age | Commit message (Collapse) | Author |
|---|
|
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 <dkg@fifthhorseman.net>
|
|
This is the result of running
$ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h
in the util directory
|
|
|
|
Oops. This should make the merge back to master smoother.
|
|
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.
|
|
This is the result of running
$ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h
in the util directory
|
|
These are usable as standard GMime streams, and transparently
decompress gzipped files.
|
|
signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
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.
|
|
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.
|
|
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.
|
|
This changes return type in gmime 3.0
|
|
The ERROR enum is merged into to the STATUS enum, and the set of flags
is different.
|
|
This function, and associated enum, have been renamed and generalized
in gmime-3.0.
|
|
This function changes semantics in gmime-3.0 so make a new function
that provides the same functionality in both
|
|
This function changes signature in gmime 3.0, so we provide two new
functions, one for each signature.
|
|
This function goes away in gmime-3.0. Also, the memory management is
apparently error prone, witness the memory leak in notmuch-reply.
|
|
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.
|
