Improve the function ``cleanup_filename()`` of ``lib/mu-msg-part.c`` to
use Unicode characters when replacing the control characters, slashes
and colons with ``-``.
Originally, this function just use plain C characters (i.e., assuming
ASCII string) when checking each character is or not a control character,
slash or colon. However, when the attachment filename contains non-ASCII
(e.g., Chinese characters), all the non-ASCII characters are replaced
with ``-``.
For example:
* Before:
```
> mu view test_chinese_attachment_filename.eml
From: Tester <tester@example.com>
To: Example <example@example.com>
Subject: Test email with attachment of Chinese filename
Date: Mon 23 May 2016 05:22:09 PM CST
Attachments: 'attachment-test.txt', '------------.txt', '-------test.txt'
Hello,
This is a simple test email with three attachments:
1. `attachment:test.txt`: filename is all English;
2. `测试附件.txt`: filename is all Chinese (exclude the extension);
3. `附件-test.txt`: filename mixes Chinese and English.
```
* After:
```
> ./build/mu/mu/mu view test_chinese_attachment_filename.eml
From: Tester <tester@example.com>
To: Example <example@example.com>
Subject: Test email with attachment of Chinese filename
Date: Mon 23 May 2016 05:22:09 PM CST
Attachments: 'attachment-test.txt', '测试附件.txt', '附件-test.txt'
Hello,
This is a simple test email with three attachments:
1. `attachment:test.txt`: filename is all English;
2. `测试附件.txt`: filename is all Chinese (exclude the extension);
3. `附件-test.txt`: filename mixes Chinese and English.
```
Since `parent` is not really used as a parent, I use it as the last
visited encrypted part while going down the parts-tree.
At the decryption of a part (`mu_msg_crypto_decrypt_part`) I check,
through the GMimeDecryptResult, for signatures (`check_decrypt_result`)
and add them to the part (`tag_with_sig_status`). Any nested parts hold
that encrypted part as their parent. Finally at `handle_part`, for each
part I check if it a descendent of an encrypted part. If so, I proceed
checking for signatures and adding them to the `msgpart`.
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
Dirk-Jan C. Binnema
Alex Murray
Yuri D'Elia
Aaron LI
Jun Hao
attila
Foivos S. Zakkak