Bug 44699

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 04 July 2002 13:53 julien@izforge.com wrote:
> Package: kmail
> Version: 1.4.1 (using KDE 3.0.1 )
> Severity: normal

This is no bug! Therefore I downgraded your report to a wishlist item.

> When using gpg from a shell it will warn you that the key can belong
> to someone else if you encrypt when the receiver key hasn't been
> signed. With KMail it's just impossible. The key has to be signed.

That's intended behavior.

> KMail should provide a warning message but still allow the
> encryption if the user wants it when he didn't sign the receiver's
> key.

I still don't like this. But as many people already asked for this I 
will eventually implement it if time permits.

Regards
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JLsnGnR+RTDgudgRAiCJAJ4kY6kXV95Gj/9jxBt95SzwEO18ZgCfcaRR
pGi5RhLT5uwaEjuojbyFeRk=
=L7Nl
-----END PGP SIGNATURE-----

> This is no bug! Therefore I downgraded your report to a wishlist item.

Ok.

> > signed. With KMail it's just impossible. The key has to be signed.
>
> That's intended behavior.

You should only sign a key when knowing the people in a physical way. The=
=20
current behaviour is not so good.

> I still don't like this. But as many people already asked for this I
> will eventually implement it if time permits.

It should be implemented :-)

> Regards
> Ingo

Thanks a lot for your work.

--=20
Julien Ponge
julien@izforge.com
http://www.izforge.com/
GnuPG ID : CD9DE030

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 July 2002 16:19 Julien Ponge wrote:
<snip>
> You should only sign a key when knowing the people in a physical way.
> The current behaviour is not so good.
<snip>

gpg --lsign
and setting trust values for people who's keys you have signed may help.

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JfZE3oWD+L2/6DgRAiimAJwJDoy3U0SLw43atmFGIAQDDAEQqwCeIZaj
sgR3DG9i+o1qim/wO73isyg=
=A+NU
-----END PGP SIGNATURE-----

 > That's intended behavior.  > gpg --lsign  > and setting trust values for people who's keys you have signed may help.   A problem I see is that people don't know about local signing.  I've just seen someone else on a mailing list telling others to sign keys willy-nilly so kmail can use them.  I can understand why kmail behaves like this, but it could lead to a weakening of the web of trust (as seen here) by people who don't understand key signing properly.  If there won't be an option to allow encrypting to untrusted keys, can there at least be a short help message or something explaining local signing, possibly with a link to a larger document explaining a web of trust?  Thanks - Ben. 

"If there won't be an option to allow encrypting to untrusted keys, can there at least be a short help message or something explaining local signing, possibly with a link to a larger document explaining a web of trust? Thanks - Ben. ?

The help message would be a fine addition, but the local signing & education of keys would be better addressed in Kgpg.  It is after all the most likely place people would look to sign imported keys & such within KDE.

The lack of being able to encrypt to a non-trusted party means I have to sign people's keys while I never seen them in my life; which kind of defeats the purpose of the whole excerise.

I suggest to use the setting from kgpg (allow encryption with untrusted keys).

If you don't trust minimally, you shouldn't be sending encrypted mail. Locally signing with "I haven't verified" status should be enough.

> If you don't trust minimally, you shouldn't be sending encrypted mail.

My first response would be that I'd like to decide for myself when I sent encrypted email.
But the big picture is that we seem to use encrypted email for very different purposes and needs.  I just want to encrypt it so the postmaster can't read it. You seem to want encryption based on real-flesh-persons you are talking to. Something I couldn't care less about.

Most of the people I email with don't use encrypted email because they don't care who reads their email.  But if you ask further they would like to 'lick the envolope' so the postman can't read it.

I hope you will appreciate that your intended usage of the technology is not the only one and that adding the wanted option to sent to unsigned keys is the only thing standing in the way for simple-moms to start using this for very different reasons you want it.

I also hate that enforced local signing. Its quite an unnecc. nuisance - if I get a key from someone/the net, I really don't trust it, and I would like to leave it in that state and just send some encrypted mail - note that at this point I usually do not care for man-in-the-middle attacks, since I couldn't prevent/detect them anyway.

Apart from that, I never seem to remember how to local sign keys, or get it to work properly. Sometimes kmail refuses to reread the keys, sometimes the trusdb it not update etc. It simple complicates sending encrypted mail (especially for newbies) very unneccessary.

This is also Bug#296601 in the Debian BTS (http://bugs.debian.org/296601). We (the Debian KDE maintainers) really feel that the user should be able to force the use of an untrusted key, if he wishes so. Although there is --lsign, this can be a "dangerous misfeature" too; as one developer put it, "it is worse to sign locally and then forget forever about the whole affair and later think the key has been really signed by someone in your trust path, than to have a warning pop up every time you try to use an unverified key".

Thanks for considering.

Does anyone at least have a patch for this?  Just to forcefully enable the OK button?  :)

Are there any progress on this ?
I would like to not have to raise trustlevel to ultimately, encrypt and send, and then remember to lower trustlevel to correct level again.

THis bug is weakening the web of trust. And yes. it is a bug, not a feature.

Why would you send an encrypted mail to someone if you don't even have a remote idea if the key belongs to that person?

If you have such an idea, you can sign with a low level of trust, using a non-exportable key.

Transport security? Of course we may be vulnerable to a man-in-the-middle attack. But it is a protection againt random network sniffing on both the sender's and the receiver's sides.

Additionally, local signing is time consuming and therefore results in people using cryptography less, which is bad.

Third: Read the rationale from the Debian maintainers again. You lsign a key because you want to send an encrypted message. You are not really sure, if this key belongs to that person. Some time later, you receive a signed message from that person. Kmail will display it with green background and tell you, that the key is trusted. Are you sure that you will remember that you didn't really trust that person?

It is a bug. It weakens the web of trust. And it steals my time.

On Tuesday 17 January 2006 22:05, Thiago Macieira wrote:
> Why would you send an encrypted mail to someone if you don't even have
> a remote idea if the key belongs to that person?


I'm not communicating to a remote party based on the flesh-and-blood 
image, I'm communicating to him/her based on his/her gpg-key and 
connected email address.

Saying I have to figure out the flesh-blood person connected to it in 
order to figure out if I should trust his/her online identity is thus 
ludicrous, its one step too far and is based on false assumptions (namely 
that I start with a person and connect his online identity to that).

This trust model that the KMail people based this on thus forgets to take 
into account the anonymous idea of the disconnected internet and how its 
more often then enough to talk to an pgp-ID and have no idea who is 
behind it.

Not to mention that it's my choice, not some KDE developer's choice, as to who and what I encrypt email to.

Really it's none of your business what I do.  You should enable the software to work to my requirements, not impose your own ideas of what should and shouldn't be done.  Afterall, if gnupg wasn't supposed to do it, it wouldn't. 

I could be wrong, but I think it's gpgme that restricts this. Someone who knows the code better will have to speak up, though.

Well, I don't know exactly but other email client that use gnupg can do this. 
Some my friends doesn't use KMail and they can send me an encrypted email 
also if they didn't sign my key, but if you ask me which is the email client 
I don't know exactly.

Are these friends of yours sending OpenPGP/MIME mails or standard OpenPGP/inline?

IIRC a person (nick "toma") told me in IRC that the check is done in kmail/keyresolver.cpp:122

if ( !it->isRevoked() && it->validity() >= GpgME::UserID::Marginal )
      return true;

He patched his kmail removing the "it->validity() >= GpgME::UserID::Marginal" condition and it worked.

Best regards

My friend uses Sylpheed Claws with the integrated plugin. It manages MIME with 
the gpg inline and my friend uses both OpenPGP/MIME and standard 
OpenPGP/inline but he prefears OpenPGP/MIME. In my KMail configuration I use 
the gpg-agent as suggested here: 
http://kmail.kde.org/kmail-pgpmime-howto.html

Hey, Thiago: This is KDE, not Apple or Microsoft.  It's not KDE or Linux's job to shove developer ideas of proper behavior down the throats of unwilling users no matter how much it hurts.  KDE is the best desktop becuase it allows the user to decide what they want to do, not what the software developer wants them to do.  So please stop playing Big Brother.

I'm going to re-enforce Debian's report: the current behavior is simply encouraging people (including me) to sign keys which they have not been able to check.  Thus it's *compromising* the Web of Trust, not supporting it.  

If you can't verify the identity, why are you using the key at all?

And you know you can sign locally only.

I don't think your argument holds.

Thiago,

Again, that's irrelevant.  What you're doing is trying to enforce *your* notion of "proper behavior" on users despite numerous feature requests and votes.  I repeat: who do you think you are, Steve Jobs?   The day that KDE becomes a straightjacket the day the whole darned project dies.  And you seem to be intent on bringing that day closer.

The reason to use untrusted keys is this *very* simple exchange which those of us who have real business do to on the internet other than hacking do all the time:

Me: I can send you the figures, but they need to be protected from interception.
Him: my gpg key is GH565FM
Me: Ok, sent

It should be that easy.  But it's not, simply because *you* are standing in the way of a fix that another KDE developer is ready to make.  The result is *less* people using GPG, and *less* people using Kmail, because Thunderbird does not have this stupid restriction.

Here's the issues with "local signing":

a) I shouldn't be signing keys, even locally, that I haven't verified.
b) The kgpg interface is cumbersome, unintuitive and buggy so it takes hands-on-help from a geek to do local signing with the GUI.
c) Given the interface, I can easily accidentally sign it globally, compromising the web of trust
d) once I've signed the key locally, I'll forget that it's local only and never get around to signing it globally once I've verified it, resulting in failing to build up the web of trust.

Overall this "feature" both makes Kmail harder to use and harms the GPG Web of Trust.  Please stop standing in the way of users and progress.

On Thursday 01 February 2007 20:51, Thiago Macieira wrote:
> If you can't verify the identity, why are you using the key at all?


Because with encryption you don't need to know the person that is attached to 
the email. Just that there is an email you are sending an encrypted email to.
In other words; web-of-trust is optional when using encryption.
Oh, before you disagree to that point, its not a statement of fact, its my 
opinion. And you may disagree, but that doesn't make it false or incorrect.

> And you know you can sign locally only.


I recently had this issue;
I have a conversation with 3 people. All of them have gpg and all emails are 
encrypted.
Now I include someone else in the conversation. That 4th person can't encrypt 
emails if he falls outside the web of trust. So he can't reply encrypted 
without signing 3 keys locally.
Effect; the conversation either has to drop him out of the cc list or stop 
being encrypted.

> I don't think your argument holds.


I think it makes a lot of sense.  You are basically arguing that the solution 
is not needed due to there being a workaround. From my point of view you are 
just trying to say that the voters for this bug have to just start using GPG 
*correctly* and it will just work.
The post from josh countering that may have been worded a bit too blunt, but I 
surely see his point.

Let me make this clear:

1) KDE has to make compromises. Some choices are made. We can't let everything be permitted, or it becomes hell to be used, by anyone. You might as well scrub bits if that's the intention.

This is not to say that this is a *good* decision.

2) In your little exchange example above, you may have unintentionally leaked information. How sure are you that the person you're talking to is supposed to have those figures? If you are reasonably sure, why not sign the key in the first place?

3) I am not standing in the way of nobody. This bug isn't fixed because NO developer has stepped up to do it. In fact, I was voting *for* this bug. (I am no longer because I don't want to receive more mails about it)

4) SSL websites have this exact same problem: people see the little padlock icon and think it's all right to send their credit card numbers. The padlock icon in Konqueror and all the web browsers indicates that the data exchange is encrypted, meaning that only the destination can read it.

It does not mean the destination is who you think it is!

During the past two years, I have followed George Staikos's efforts with the other browser vendors to bring some order into this chaos. Encryption is useless without authentication.

Now, you may say that talking to someone via IRC or the phone should be enough to trust his email address. And why should it not? But I would also argue that if you trust it enough to send encrypted email, you trust it enough to sign the key.

But I no longer care about this bug. I have removed my vote so I won't get any more email about it.

Please, someone fix it. But at least make KMail show a warning that a key being used is not trusted at all. And don't add the "Don't show this message again" option. Security first.

Sometimes I don't care about the identity, I want to encrypt to someone I don't trust.  Sometimes even if I don't trust the key, I still wish to have something encrypted to the recipient, even if I don't fully trust them.

I think more to the point is that KMail should not dictate how I wish to use GPG.  That's GPG's job.  If GPG suddenly implements a feature to disallow this behaviour, then that is where the choice should be made.  Until then, it is considered a feature of GPG to allow encryption to an untrusted key.  Thus, KMail should support as many features of GPG as possible, including encryption to an untrusted key.  The importance of this is freedom of choice.  KDE is a plethora of options.  You open up the Control Center, and you can customize so many different levels of features.  Yet in this one single regard, the KDE development team suddenly chooses to restrict a feature (that seems incredibly easy to change) rather than allow the freedom, which in my opinion, breaks the spirit of KDE.

Is it not the way that one even has to trust the key "unconditionally"?

Just trusting or partly trusting it in kgpg is not enough for kmail to allow the user to send an encrypted email to that person. This does not really make sense because then only two states were needed, unconditionally and not trusted.

However, even if I would disagree with the fact that kmail should allow to send emails to untrusted persons, I would expect it to respect the different stati of trust that are possible for a key.

So for sending, it might be sensible to only allow keys > partly trusted, i.e. trusted for sending, but not trusted for receiving.

For receiving I do not know the difference between trusted and unconditionally, yet kmail only displays those emails as trusted that are signed with a key one trusts unconditionally, which is a bug too, IMHO.

To sum up, I think that even if kmail developers really think that it is not justifieable to send emails to untrusted users, there is no reason to not permit this for partially trusted keys.

I agree and I think the current behaviour is quite annoying 

re #28: Please don't mix different issues. KMail follows GnuPG's result for trust checking. If you don't like GnuPG's result then you can easily change the trust model. Read the documentation of GnuPG for more information.

General reply: We do not have the time/resources to implement this low-priority wish, but if someone provides an acceptable patch we'll consider it for inclusion.

Hi!

I played a bit around with it - and (and with the tip in #20 - which is only a bit of the way)
I am now able to send to untrusted people.
The following minor patch does it the way Thiago suggests it in comment #26 that it absolutely not should be done. And I agree with that.
So I also did something more. But it is still really really not nice. Read the comments ,)

With no warnings or anything:

Index: kdepim/kmail/keyresolver.cpp
===================================================================
--- kdepim/kmail/keyresolver.cpp        (revision 629110)
+++ kdepim/kmail/keyresolver.cpp        (working copy)
@@ -119,7 +119,7 @@
     return false;
   const std::vector<GpgME::UserID> uids = key.userIDs();
   for ( std::vector<GpgME::UserID>::const_iterator it = uids.begin() ; it != uids.end() ; ++it ) {
-    if ( !it->isRevoked() && it->validity() >= GpgME::UserID::Marginal )
+    if ( !it->isRevoked() )
       return true;
 #if 0
     else
Index: kdepim/kmail/messagecomposer.cpp
===================================================================
--- kdepim/kmail/messagecomposer.cpp    (revision 629110)
+++ kdepim/kmail/messagecomposer.cpp    (working copy)
@@ -2191,7 +2191,7 @@
   plainText.duplicate( cText.data(), cText.length() ); // hrmpf...

   const GpgME::EncryptionResult res =
-    job->exec( encryptionKeys, plainText, false, encryptedBody );
+    job->exec( encryptionKeys, plainText, true, encryptedBody );
   if ( res.error().isCanceled() ) {
     kdDebug() << "encryption was canceled by user" << endl;
     return Kpgp::Canceled;
@@ -2232,7 +2232,7 @@
   plainText.duplicate( cText.data(), cText.length() ); // hrmpf...

   const std::pair<GpgME::SigningResult,GpgME::EncryptionResult> res =
-    job->exec( signingKeys, encryptionKeys, plainText, false, encryptedBody );
+    job->exec( signingKeys, encryptionKeys, plainText, true, encryptedBody );
   if ( res.first.error().isCanceled() || res.second.error().isCanceled() ) {
     kdDebug() << "encrypt/sign was canceled by user" << endl;
     return Kpgp::Canceled;


With excessive warnings very much repeated (read comments):

Index: kdepim/kmail/keyresolver.cpp
===================================================================
--- kdepim/kmail/keyresolver.cpp        (revision 629110)
+++ kdepim/kmail/keyresolver.cpp        (working copy)
@@ -119,8 +119,27 @@
     return false;
   const std::vector<GpgME::UserID> uids = key.userIDs();
   for ( std::vector<GpgME::UserID>::const_iterator it = uids.begin() ; it != uids.end() ; ++it ) {
-    if ( !it->isRevoked() && it->validity() >= GpgME::UserID::Marginal )
-      return true;
+    if ( !it->isRevoked() )
+    {
+      if ( it->validity() >= GpgME::UserID::Marginal )
+      {
+       return true;
+      }
+      else
+      {
+       if ( KMessageBox::warningYesNo (0,"This key is untrusted. Are you sure you want to encrypt to this key?", "Untrusted key") == KMessageBox::Yes)
+       {
+         //Do something about the message box - it gets shown 3 times when accepting
+         //And 5-8 times when cancelling (Stopped counting)
+         //
+         //
+         //Save something here to be used over in kdepim/kmail/messagecomposer.cpp
+         //instead of hardcoding true
+         return true;
+       }
+      }
+
+    }
 #if 0
     else
       if ( it->isRevoked() )
Index: kdepim/kmail/messagecomposer.cpp
===================================================================
--- kdepim/kmail/messagecomposer.cpp    (revision 629110)
+++ kdepim/kmail/messagecomposer.cpp    (working copy)
@@ -2191,7 +2191,7 @@
   plainText.duplicate( cText.data(), cText.length() ); // hrmpf...

   const GpgME::EncryptionResult res =
-    job->exec( encryptionKeys, plainText, false, encryptedBody );
+    job->exec( encryptionKeys, plainText, true, encryptedBody );
   if ( res.error().isCanceled() ) {
     kdDebug() << "encryption was canceled by user" << endl;
     return Kpgp::Canceled;
@@ -2232,7 +2232,7 @@
   plainText.duplicate( cText.data(), cText.length() ); // hrmpf...

   const std::pair<GpgME::SigningResult,GpgME::EncryptionResult> res =
-    job->exec( signingKeys, encryptionKeys, plainText, false, encryptedBody );
+    job->exec( signingKeys, encryptionKeys, plainText, true, encryptedBody );
   if ( res.first.error().isCanceled() || res.second.error().isCanceled() ) {
     kdDebug() << "encrypt/sign was canceled by user" << endl;
     return Kpgp::Canceled;


But I hope that this can push a more skilled kmail coder in the right direction.


The first part of the patch (in keyresolver.cpp) gives the possibility to choose the key. (as written in #20
The second part (changes to messagecomposer.cpp) sets wether or not keys should be trusted by default.

So appealing to a bit more skilled people than me (I am still on my way to write 100 lines of kde code, including this) ! Please do something ;)

/Sune

*** Bug 138098 has been marked as a duplicate of this bug. ***

I can encrypt messages to keys I don't have signed, if I set the trust level to absolute in Kgpg, it's working for me.

To Michael Skiba,

you missed the point. The point is not having to set the trust to ultimate if you don't trust the key ultimately.

That is why I ask for disabling this "feature"... All normal user will misuse other feature to able to use gpg...

I sign unchecked keys...

Other will set the trust to ultimate...

We all do it only to use gpg....

Try to make orders... User will ban the tool or trick the orders... That is the way user will use software... That is the way it works...

Created attachment 21462 [details]
Adding a passphrase callback (dialog asks for password) when gpg-agent is not running, see gpgme_set_passphrase_cb

Hehe, I know of course what the point is, but I wanted to let others now how to use this as workaround, I think it's better they set the trustlevel to ulimately for 2 mins and set it back, then do something like signing a key, which is a risk for the web-of-trust.

Comment on attachment 21462 [details]
Adding a passphrase callback (dialog asks for password) when gpg-agent is not running, see gpgme_set_passphrase_cb

Wrong bug report, sorry :S...

See bug #92619

Come on, this can't be true. kmail disallows me to send encrypted with an untrusted key - why!? Warning is okay, perhaps in bold letters and some "I am really sure" check.

This misfeature makes kontact all but useless for me. I won't go and sign any key of other Debian people I did not meet in person - I can't be sure the key matches the person. But at least it will only be readable by the person having the key, no t to every mail server in between us. 

For work I have a big list of keys which I won't sign. For one I know the person relating to the key, but I did never check any passports. So I won't sign them. So the "solution" to use kmail is to --lsign every key? Not!

While I am just using Thunderbird again in disbelief, others will happily sign every key just to be able to send an email. For me this looks like a security problem (the social engineering kind) and not like a wishlist bug.

Please fix this!

We changed this behavior for 3.5.9 (as part of the enterprise branch changes). Please confirm that it works as expected now, thanks.

Thanks a lot for the info, Till. I will have a look as soon as kdepim 3.5.9 is packaged for Debian.

With KDE 3.5.9 it still appears to not work:
when selecting an "ordinary" key in "OpenPGP Key Selection", the OK button is still grayed out and the key symbold, marked with a yellow question mark, gets marked with a red cross instead.
Only the selected keys/recipients which get a green checkmark after being selected can be chosen for encryption.
So, it appears that the behaviour has changed, but the bug hasn't been fixed.

Confirmed: I see the same as Daniel Hahler (KDE 3.5.9 on Kubuntu).

Thanks.

Not wanting to annoy anyone, but is there any progress on this?


Thanks!

It seems like the bug is fixed in 1.13.7 or some version before.

Closing according to the last comment.
Please open a new report for KMail2 if you still have this issue in KMail2.