Bug 322708 - kmail should allow encrypting mails with keys of unknown/zero trust
Summary: kmail should allow encrypting mails with keys of unknown/zero trust
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 4.13 Pre
Platform: Other Linux
: NOR major with 1 vote (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-22 22:15 UTC by christof.schulze
Modified: 2017-01-07 23:42 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description christof.schulze 2013-07-22 22:15:17 UTC
however it doesn't. This is wrong because encryption is meant to provide confidentiality and the act of signing keys and creating a web of trust is meant to provide authenticity. Both are great when they are joined but this is actually not necessary.

Reproducible: Always

Steps to Reproduce:
1. create new mail that should be encrypted
2. select a key that is not trusted / signed by the own secring
3. watch kmail fail when sending the mail.
Comment 1 Martin Steigerwald 2013-09-16 14:43:57 UTC
Bug 324963 - general error on sending GPG encrypted mail after telling KMail to use untrusted key 

may be a duplicate of this one, but since this bug report doesn´t contain useful information I chose to file that new bug.
Comment 2 Hauke Laging 2014-01-04 08:52:23 UTC
(In reply to comment #0)
> however it doesn't. This is wrong because encryption is meant to provide
> confidentiality and the act of signing keys and creating a web of trust is
> meant to provide authenticity.

I can confirm the problem but your explanation doesn't make sense. You seem to not have understood how crypto works. See:

http://www.openpgp-schulungen.de/kurzinfo/irrtuemer/#import-ausreichend

You need verify the certificate in order to be sure that you encrypt to the right key. Encrypting to the MitM key is not part of the concept "confidentiality". Signing keys makes them valid. You need valid keys both for serious encryption and for serious signature checking.

Nonetheless this must be fixed because the user must be free to decide to use the key anyway and it is really evil to force the user to certify the key first (or even worse: set it to ultimate trust).
Comment 3 kolAflash 2014-01-22 23:49:56 UTC
I understand the bug in that way, that I got a private key which I'm not fully trusting. Maybe because someone else stole a copy of that private key. Or it's a private key I share with some people because we all get forwarded mails from an alias address. Nevertheless KMail shouldn't deny to use the key but give a clear warning.

Did some testing. (By the way: patch for bug #328311 doesn't fixes this bug)

KDE 4.11.4 (openSUSE 13.1)


====
When changing a OpenPGP key for a KMail identity
Settings => Configure KMail => Identities => Modify => Cryptography => Change
I can manually select a key for which I set the trust-level to anything less then "Ultimately" (using Kgpg) for signing but I CAN'T select it for encryption.

Same problem when changing the "Your keys" in the last step before sending an encrypted E-Mail (dialog "Encryption Key Approval").
====


====
If I set a full-trusted key as default for a KMail identity (Settings => Configure KMail) and afterwards lower the trust-level KMail gives me this message when trying to send a mail with that identity:

"You have requested to encrypt this message, and to encrypt a copy to yourself, but no valid trusted encryption keys have been configured for this identity."
Only choices:
"Send unencrypted" "Cancel"
====


====
Can't manually select a key in the "Encryption Key Selection" dialog which run over it's date of validity. (created a key for testing by running a vm in Qemu and set the time a few years back)

This is important! If someone forgot to create a new key or to send me a new key I should be able so send him an encrypted email asking for that!
====
Comment 4 Hauke Laging 2014-01-23 00:43:01 UTC
(In reply to comment #3)
> I understand the bug in that way, that I got a private key which I'm not
> fully trusting.

Private keys are neither valid nor trusted. Certificates (public keys) are (in)valid and (un)trusted.


> Nevertheless KMail shouldn't deny to use the key but give a clear warning.

Indeed.

> I can manually select a key for which I set the trust-level to anything less
> then "Ultimately" (using Kgpg) for signing but I CAN'T select it for
> encryption.

GnuPG doesn't care about the trust level but about the validity level. The trust level doesn't change the validity level (exception: ultimate). You should never use ultimate trust in order to make a key valid.

> If I set a full-trusted key as default for a KMail identity

You mean ultimately trusted?

> This is important! If someone forgot to create a new key or to send me a new
> key I should be able so send him an encrypted email asking for that!

And it must be possible to encrypt to an invalid key because otherwise the user is forced to pretend a key validation (unless he knows certain tricks).
Comment 5 Denis Kurz 2016-09-24 18:16:08 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 6 kolAflash 2016-09-25 21:23:21 UTC
For PGP/MIME I can't reproduce this anymore. (can anyone?)

But for PGP/Inline this still seems to be valid, as explained here:

https://bugs.kde.org/show_bug.cgi?id=332167
Comment 7 Denis Kurz 2017-01-07 23:42:32 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.