Hello Devs.
While testing Zimbra OpenPGP Zimlet <> Enigmail compatibilty, and found what seems to be an issue in Enigmail.
When sending inline-pgp messages with attachments, attachment save-as and double click only work when the attachments are of the same content.
For example an encrypted message with 2 of pdf.pgp attachments work normal,
https://gist.github.com/barrydegraaff/a0d242e080e0847fd937f36a7c99fbaf
an encrypted message with 2 of jpg.pgp attachments work normal.
https://gist.github.com/barrydegraaff/7e4a30cd9dc3cf50f165fc404a8b3126
An encrypted message with 1 of pdf.pgp and 1 of jpg.pgp attachments, the pdf decrypts fine, the jpg is saved as msg.txt as is opened in my text editor, and not my jpg viewer.
https://gist.github.com/barrydegraaff/b00b29a06652a2c08d16f33a08c0fccb
All attachments have a wrong content-type: application/pgp-encrypted; name=10.jpg.pgp (from Zimbra) This may lead to this bug, not sure though.
When clicking Decrypt and save-as and manually type a filename.jpg instead of the suggested msg.txt the attachment is saved correctly.
Additionally it seems double clicking on an inline attachments generated 2 actions on my system, one: open the encrypted attachment with the default application (useless) and one open decrypted attachment with default application (this is what we want) but the latter is broken (if there are different attachment types)
I will try and debug and patch later this week, if anybody else wants to look into it, great!!
changing the content type to
application/octet-stream;
as suggested in https://sourceforge.net/p/enigmail/bugs/600/ does not matter, the problem is still there.
cause not zimbra related
Last edit: Barry de Graaff 2016-05-16
can you please send me a sample message that fails? Please send it to patrick AT enigmail DOT net, using key ID 0xDD5F693B
test email has been sent
Hello Patrick,
I have created a patch for bug 610, don't know if you confirmed it yet.
It seems that for some reason the rawFileName variable is define in the wrong scope. Although looking at the previous code it
seemed correct- dumping variables showed it did not work. The result is that in the old version msg.txt was used as filename
rather than the correct file name.
Please verify and check my patch (also attached to ticket).
https://gist.github.com/barrydegraaff/c5cde93b747056590a48f3375387c75c
Thanks, regards Barry
I cannot see any difference in behavior with or without your patch. Furthermore, your patch leads to compilation errors with eslint, as you re-define a block-scoped variable.
Hello Patrick,
Are you able to confirm the bug with the testmail I sent?
Using the debug logs that are already in the code, no difference can be seen between a working and a failed save as action. However if you put a console.log(rawFileName); instead of my 2 pacth lines, I can observer that rawFileName is not filled with the actual file name.
With the patch it works 100% of the time.
I do not understand what the cause of the problems is, but if you can confirm it exsists, then the compilation error can be avoided by removing the
varkeyword. This would mean the existing variable for rawFileName would be filled with the attachment name.Barry
Even if it fixes your issue, the problem with your patch is that it does not comply to JavaScript syntax checking. I cannot accept your patch because the code won't compile if I enable the tests.
Using "decrypt and save as" works fine for me with your example message for every attempt.
On Windows with a different key, it works for me too,
I removed the extension from Fedora repo (to be sure) and then used a different key for decryption and it works as well. So seems it is not a mayor issue after all. Thanks