This reverts commit 6e9b9ad2d0.
Unfortunately the reverted commit breaks the Signature field for
encrypted and, at the same time, signed messages.
TODO: details button in the Signatures field does not work for such
cases because the signature is encrypted.
Conflicts:
lib/mu-msg-part.c
Add a decryption field of the form
Decryption: 2 part(s) decrypted 1 part(s) failed
Meaning that 2 encrypted mime parts where successfully decrypted and 1
part failed. Note that the number 2 refers to the number of
successfully decrypted mime parts and not the number of successfully
decrypted encryptes multiparts, i.e., if an encrypted multipart
contains 4 parts and decryption is successful the field will be
Decryption: 4 part(s) decrypted
TODO: Add details button listing the names and indexes of the
decrypted (or not) mime-parts
Pull request #483 does not handle encrypted multiparts properly. It
used to just verify the signature and not process the parts of the
multipart. This commit resolves this issue.
Additionally it did not index attachments properly and in the case of a
multipart directly containing more than one multiparts resulted on non
unique indexing of attachments/parts. This commit resolves this issue
as well.
This patch fixes the attachment extraction (open, save, temp) when using
`mu4e`. `mu4e` used to not notify the mu-server about the
mu4e-decryption-policy. As a result mu-server did not decrypt the
attachments for extract, open, or temp.
After a multipart/encrypted part gets decrypted the result is usually a
`multipart/mixed` part (see enigmail).
Before this commit mime multiparts where handled only by
`g_mime_message_foreach`. As a result the decrypted mime multiparts
where not processed.
This patch handles mime multiparts explicitly by removing the
`g_mime_message_foreach` invocations. This might come at the cost of
reduced maintainability, in the case of radical gmime changes. However,
gmime is pretty stable and that scenario is highly unlikely.
TODO: After decryption make any attachments available
