Menu

#610 Inline pgp with different type attachments, fail to save as properly

invalid
nobody
None
1.9.2
Major
45
2.1.11
All
---
nobody
2016-05-21
2016-05-16
No

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!!

Discussion

  • Barry de Graaff

    Barry de Graaff - 2016-05-16

    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.

     
  • Barry de Graaff

    Barry de Graaff - 2016-05-16
    • Severity: Minor --> Major
      cause not zimbra related
     

    Last edit: Barry de Graaff 2016-05-16
  • Patrick Brunschwig

    can you please send me a sample message that fails? Please send it to patrick AT enigmail DOT net, using key ID 0xDD5F693B

     
  • Barry de Graaff

    Barry de Graaff - 2016-05-17

    test email has been sent

     
  • Barry de Graaff

    Barry de Graaff - 2016-05-19

    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

     
  • Patrick Brunschwig

    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.

     2152:9   error  'rawFileName' used outside of binding context  block-scoped-var
    2164:11  error  'rawFileName' is already defined               no-redeclare
    
     
  • Barry de Graaff

    Barry de Graaff - 2016-05-20

    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 var keyword. This would mean the existing variable for rawFileName would be filled with the attachment name.

    Barry

     
  • Patrick Brunschwig

    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.

     
  • Patrick Brunschwig

    Using "decrypt and save as" works fine for me with your example message for every attempt.

     
  • Barry de Graaff

    Barry de Graaff - 2016-05-21

    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

     
  • Barry de Graaff

    Barry de Graaff - 2016-05-21
    • status: open --> invalid
     

Log in to post a comment.

MongoDB Logo MongoDB