multiple "send" will send attachments unencrypted
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
#516 multiple "send" will send attachments unencrypted
When sending email with large attachments(>15MB)/many attachments(>20), before sending complete, click "send" again, then recipient is likely to receive attachments in plain form. Tested with PGP/MIME but suspect that inline mode is the same. Recreated with Thunderbird from 16.0 to 31.6 and enigmail 1.5.2 to 1.8.2. Wonder if it is possible to block "send" while enigmail is processing?
Do you mean, you can click on "send" again while the transmit is still running? This is not possible on Mac OS X. The "send" button is grey and inactive until the transmit process is completed, then the compose window is closed. If the send button could be clicked multiple times, then this would be a bug in Thunderbird itself. However, as this is a security issue, Enigmail should implement a workaround that the second attempt does not result in a mail sent unencrypted.
I don't have a windows machine available for testing, at least not today.
Could this have changed in Thunderbird 38? In my eyes this should be fixed by Thunderbird - TB knows when the send process is completed.
No, it works correctly with TB38 and TB31. Can't tell for older versions, and I won't downgrade further.
Might still be a windows issue. I'll test there tomorrow.
Click on "send" again after prompt of password but before the "sending mail" dialog prompts out. If the "sending mail" dialog is out then "send" is properly greyed. To test, include lots of large attachments (or use an old slow machine), then enigmail will take a long time to process and the screen will stay at the compose windows for quite long time, during which time the "send" button could be pressed multiple times.
Find a hack to solve the problem. In enigmailMsgComposeOverlay.js, find encryptMsg() set gWindowLock after gWindowLock check, and in sendMessageListener(), clear gWindowLock after calling encryptMsg(). But frankly I don't know whether setting gWindowLock this way will have side effect.
You forget that this only enables (and possibly disables) the window lock for the time of the preparation of sendig a mail. But in case of PGP/MIME messages, the sending process as such is the time consuming part. That's done in after encryptMsg() has completed, and is out of the control of Enigmail. If the send function fails, we're not notified properly and the send buttons potentially remain locked forever.
Tested on windows (Win7 Enterprise, TB 38.2.0, Enigmail version 1.9a1pre (20150415-0013 - quite old, I know), gpg (GnuPG) 2.0.27 (Gpg4win 2.2.4).
I could indeed - after several attempts and a heavily loaded machine - click the "Send" button several times (before pinentry popped up asking for the passphrase and before the first "sending message" window appeared) and manage to send 7 mails of 20MB size from one compose window. TB came up with "unresponsive script" and I clicked "continue" there. Quite some time before and after this dialog, TB was very slow in reacting on mouse clicks and took a lot of resources (e.g. 1GB RAM, several gpg2.exe processes were active in parallel, CPU was on 100% for some time).
After some minutes, all 7 mails were sent out. All 7 mails arrived one by one and all were correctly encrypted and signed, none of them were sent in cleartext.
@Sing: Did you have the "unresponsive script" dialog? Did you click on "Cancel" there?
@Patrick: Debug log is available if needed.
Quite notable: Even now, about one hour after finishing this torture, the seven "sending message" windows are still hanging around on the screen, displaying a full progress bar and say "Filter complete" - but all 7 mails are already in the Sent folder, and TB is fully usable besides that.
Here is a log file. Thunderbird 31.6 with enigmail 1.8.2 under Windows 7, sending email to myself and clicked "send" twice. One of the message shown "attachment to this mail is not signed or encrypted". I do not use inline so I don't know if that would be different.
The clicking should be after password entry but before the sending dialog coming out. It would be easier to reproduce if the password is already cached.
No "unresponsive script" popped up; I also have the "sending message" hanging there forever but seems no harm is caused by it.
I don't need log files - it's perfectly clear to me what happens and why. I'm just afraid of the consequences if it's not done 100% correctly.
I implemented the disabling of the various send buttons and key commands for the time that Enigmail prepares the message (i.e. until Enigmail hands back the control to Thunderbird). It is still possible to get the "send" buttons re-activated automagially by Thunderbird, but it should not happen in most cases anymore.
Whatever happens to the buttons after the control is back at Thunderbird is out of the hands of Enigmail.