Bug 3960 - Sends unencrypted emails when encryption fails
Summary: Sends unencrypted emails when encryption fails
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins/Privacy/PGP (show other bugs)
Version: 3.13.2
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-02-09 09:34 UTC by GDR!
Modified: 2018-05-04 11:01 UTC (History)
0 users

See Also:


Attachments

Description GDR! 2018-02-09 09:34:39 UTC
When sending to one recipient, I'm getting the most unusual behavior: There's some PGP error but Claws decides to send the email in plaintext anyway. 

The error is probably in my setup and I'm not really asking for help with this, but it's a security problem that plain text email is being sent when it's not expected. I would expect 

0. Privacy system = PGP Inline, Encrypt, not Sign
1. Getting an alert "Please note that attachments are not encrypted by the PGP/Inline system, nor are email headers, like Subject."
2. Getting "This encryption key is not fully trusted.
If you choose to encrypt the message with this key, you don't
know for sure that it will go to the person you mean it to."
3. Getting an alert with a red X icon, title "Error", heading "Error" and text "Couldn't encrypt the email: Unknown error", with only Close button.


Claws Mail version 3.13.2 from Ubuntu 16.04 repos. (BUT AS FAR AS I SEE THE CODE IN HEAD IS NO DIFFERENT - SEE BELOW)

PGP/Inline plugin Version: 3.13.2

➜  ~ gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
...
➜  ~ gpg --version
gpg (GnuPG) 1.4.20
...

Could it be that this branch in code should return a negative number to prevent the message from sending?

http://git.claws-mail.org/?p=claws.git;a=blob;f=src/compose.c;h=ae5cd90e89b68b0056553d441d851b0ced5b5d78;hb=HEAD#l5903
Comment 1 Ricardo Mones 2018-02-09 11:11:47 UTC
(In reply to comment #0)
> When sending to one recipient, I'm getting the most unusual behavior:
> There's some PGP error but Claws decides to send the email in plaintext
> anyway. 
> 
> The error is probably in my setup and I'm not really asking for help with
> this, but it's a security problem that plain text email is being sent when
> it's not expected.

Why is not expected that the mail is sent plaintext when the dialog is clearly telling you it could not encrypt the message? Is there any other option between encrypted and cleartext? :)

Anyway I understand you may want to have a way to cancel sending in such situation.

Although I think that asking the user if cancel sending is desired or it's ok to continue sending cleartext it's better than direct cancelling which you proposed.
Comment 2 GDR! 2018-02-09 15:19:36 UTC
Well, I selected Options->Encrypt so maybe I'm sending something confidential that I don't want to send in plain text. I'd rather not send it than send it in plain text.

If you don't believe a random internet stranger that it's a security issue - when Enigmail for Thunderbird sent unencrypted email even though encryption was enabled, it made the news and got a CVE number.
Comment 3 Paul 2018-02-09 15:23:56 UTC
You are totally believed, and I've verified the problem locally. I have a quick fix patch, which is, like you say, returning -5. Either this patch or a better, more complete fix will be in the next release. Thanks for the report.
Comment 4 GDR! 2018-02-09 16:21:56 UTC
Thank you for taking this seriously Paul.
Comment 5 users 2018-04-13 20:04:05 UTC
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
http://git.claws-mail.org/

++ ChangeLog	2018-04-13 20:04:04.902675167 +0200
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=f411d0f967abdd163686e399e340f00bdc7f4e12
Merge: 6ae6cc9 e9f610a
Author: Colin Leroy <colin@colino.net>
Date:   Fri Apr 13 20:04:03 2018 +0200

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=e9f610a4f8d1c1ffdcadc14d9cb5373987ac28e4
Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Tue Apr 10 19:46:01 2018 +0200

    Rework and simplify how compose_queue() return values are handled
    
    Also closes bug #3960 - Sends unencrypted emails when encryption fails
    because we now return from compose_queue() with an error when
    that happens, instead of ignoring it.

Note You need to log in before you can comment on or make changes to this bug.