gmime-2.6 had a bug [1] which made it impossible to tell why a signature
verification failed when the signer key was unavailable (empty "sigstatus" field
in the JSON output). Since 00b5623d the corresponding test is marked as broken
when using gmime-2.6 (2.4 is fine).
This bug has been fixed in gmime 2.6.5, which is now the minimal gmime-2.6
version required for building notmuch (gmime-2.4 is still available). As a
consequence the version check in test/crypto can be removed.
[Added by db]
Although less unambigously a bug, Gmime 2.6 prior to 2.6.7 also was
more strict about parsing, and rejected messages with initial "From "
headers. This restriction is relaxed in [2]. For reasons explained in [3],
we want to keep this more relaxed parsing for now.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=668085
[2] http://git.gnome.org/browse/gmime/commit/?id=d311f576baf750476e06e9a1367a2dc1793ea7eb
[3] id:"1331385931-1610-1-git-send-email-david@tethera.net"
This makes the text formatter take advantage of the new code
structure. The previously duplicated header logic is now unified,
several things that we used to compute repeatedly across different
callbacks are now computed once, and the code is simpler overall and
32% shorter.
Unifying the header logic causes this to format some dates slightly
differently, so the two affected test cases are updated.
There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.
This is mostly based on id:"8762i8hrb9.fsf@bookbinder.fernseed.info".
This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the
crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is
currently broken (signature verification with signer key unavailable), most
likely because of a bug in gmime which will hopefully be fixed in a future
version.
Change add_email_corpus, emacs_deliver_message and tests to use
$TEST_DIRECTORY instead of '..'.
This improves the behavior of the usage of --root=<dir>, as the
assumption of what '..' means will usually be incorrect.
Document -root option in README and update valgrind to work with
-root.
Various typo fixes in comments within the source code.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just
source-code comments, (and fixed fix of "descriptios" to "descriptors"
rather than "descriptions").
The primary goal here is to keep the decrypted output as similarly
structured as undecrypted output as possible. Now, when decrypting
parts, only the original encrypted part is replaced by the it's
decrypted content. If this part isn't itself a multipart, then all
part numbering should remain consistent during decryption.
The only draw back here is that the useless application/pgp-encrypted
sub-part of the multipart/encrypted part is also emitted. But this
part can be easily ignored by clients.
Some folks have complained about the part renumbering that occurs when
the entire multipart/signed part is replaced with the part contents
after verification. This is primarily because it incurs an additional
computational cost to retrieve individual parts, since verification
has to be performed again to ensure that part numbering is consistent.
This patch simply leaves the full multipart/signed part as is.
The emacs crypto test is also updated to reflect this change.
This patch adds the tag "signed" to messages with any multipart/signed
parts, and the tag "encrypted" to messages with any
multipart/encrypted parts. This only occurs when messages are indexed
during notmuch new, so a database rebuild is required to have old
messages tagged.
This adds a new "crypto" test script to the test suite to test
PGP/MIME signature verification and message decryption. Included here
is a test GNUPGHOME with a test secret key (passwordless), and test
for:
* signing/verification
* signing/verification with full owner trust
* verification with signer key unavailable
* encryption/decryption
* decryption failure with missing key
* encryption/decryption + signing/verfifying
* reply to encrypted message
* verification of signature from revoked key
These tests are not expected to pass now, but will as crypto
functionality is included.
