Bug 44699 - can't encrypt with gpg if the receiver's key is not signed
Summary: can't encrypt with gpg if the receiver's key is not signed
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: encryption (show other bugs)
Version: 1.4.1
Platform: Gentoo Packages Linux
: NOR wishlist with 498 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 138098 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-07-04 12:03 UTC by Julien Ponge
Modified: 2011-11-30 16:10 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Adding a passphrase callback (dialog asks for password) when gpg-agent is not running, see gpgme_set_passphrase_cb (2.94 KB, patch)
2007-08-23 12:47 UTC, Alexis Papadopoulos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Ponge 2002-07-04 11:53:19 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kmail
Version:           1.4.1 (using KDE 3.0.1 )
Severity:          normal
Installed from:    Gentoo
Compiler:          gcc version 2.95.3 20010315 (release)
OS:                Linux (i686) release 2.4.19-gentoo-r7
OS/Compiler notes: 

If you want to send an encrypted email to someone whose key hasn't been signed by yourself you won't be able to encrypt it. The dialog prompts you for a valid key because it can't find a good one.

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.

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.

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Ingo Klöcker 2002-07-04 21:16:23 UTC
-----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-----
Comment 2 Julien Ponge 2002-07-05 14:19:52 UTC
> 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
Comment 3 Marc Mutz 2002-07-05 19:40:22 UTC
-----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-----
Comment 4 Ben Burton 2002-10-04 00:23:47 UTC
 > 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. 
Comment 5 Louis Rush 2003-10-25 16:52:45 UTC
"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.
Comment 6 Thomas Zander 2003-11-02 16:13:33 UTC
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).
Comment 7 Thiago Macieira 2003-11-02 17:58:02 UTC
If you don't trust minimally, you shouldn't be sending encrypted mail. Locally signing with "I haven't verified" status should be enough.
Comment 8 Thomas Zander 2003-11-09 09:31:33 UTC
> 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.
Comment 9 Tels 2004-08-29 10:54:22 UTC
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.

Comment 10 Ana Guerrero (Debian KDE maintainers) 2005-02-23 22:20:47 UTC
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.
Comment 11 Jon-Pierre Gentil 2005-03-07 09:52:44 UTC
Does anyone at least have a patch for this?  Just to forcefully enable the OK button?  :)
Comment 12 Sune Vuorela 2006-01-17 00:18:23 UTC
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.
Comment 13 Thiago Macieira 2006-01-17 10:05:54 UTC
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.
Comment 14 Felix Eckhofer 2006-01-17 10:27:33 UTC
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.
Comment 15 Thomas Zander 2006-01-19 00:11:12 UTC
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.
Comment 16 Jon-Pierre Gentil 2006-01-19 00:15:42 UTC
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. 
Comment 17 Thiago Macieira 2006-01-21 18:45:34 UTC
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.
Comment 18 Giovanni Venturi 2006-01-21 18:53:31 UTC
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.
Comment 19 Thiago Macieira 2006-01-21 19:02:57 UTC
Are these friends of yours sending OpenPGP/MIME mails or standard OpenPGP/inline?
Comment 20 Isaac Clerencia 2006-01-22 16:31:53 UTC
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
Comment 21 Giovanni Venturi 2006-01-22 21:15:01 UTC
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
Comment 22 josh 2007-02-01 20:15:19 UTC
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.  
Comment 23 Thiago Macieira 2007-02-01 20:51:03 UTC
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.
Comment 24 josh 2007-02-01 21:24:35 UTC
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.
Comment 25 Thomas Zander 2007-02-01 21:33:08 UTC
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.
Comment 26 Thiago Macieira 2007-02-01 21:39:13 UTC
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.
Comment 27 Jon-Pierre Gentil 2007-02-01 21:40:24 UTC
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.
Comment 28 S. Burmeister 2007-02-01 22:34:17 UTC
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.
Comment 29 m.wege 2007-02-01 23:43:14 UTC
I agree and I think the current behaviour is quite annoying 
Comment 30 Ingo Klöcker 2007-02-02 00:36:16 UTC
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.
Comment 31 Sune Vuorela 2007-02-02 02:42:43 UTC
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
Comment 32 Thomas McGuire 2007-02-11 11:46:45 UTC
*** Bug 138098 has been marked as a duplicate of this bug. ***
Comment 33 Michael Skiba 2007-08-08 19:52:10 UTC
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.
Comment 34 Santtu Pajukanta 2007-08-08 21:23:54 UTC
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.
Comment 35 Gehold Bertin 2007-08-08 22:39:57 UTC
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...
Comment 36 Alexis Papadopoulos 2007-08-23 12:47:19 UTC
Created attachment 21462 [details]
Adding a passphrase callback (dialog asks for password) when gpg-agent is not running, see gpgme_set_passphrase_cb
Comment 37 Michael Skiba 2007-08-29 23:45:05 UTC
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 38 Alexis Papadopoulos 2007-08-30 11:38:04 UTC
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
Comment 39 Torsten Landschoff 2008-02-21 14:04:59 UTC
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!
Comment 40 Till Adam 2008-02-21 15:32:50 UTC
We changed this behavior for 3.5.9 (as part of the enterprise branch changes). Please confirm that it works as expected now, thanks.
Comment 41 Martin Steigerwald 2008-02-21 20:29:48 UTC
Thanks a lot for the info, Till. I will have a look as soon as kdepim 3.5.9 is packaged for Debian.
Comment 42 Daniel Hahler 2008-02-22 23:35:25 UTC
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.
Comment 43 Peter Lewis 2008-03-04 20:27:54 UTC
Confirmed: I see the same as Daniel Hahler (KDE 3.5.9 on Kubuntu).

Thanks.
Comment 44 Richard Hartmann 2008-07-01 13:33:43 UTC
Not wanting to annoy anyone, but is there any progress on this?


Thanks!
Comment 45 Timo Weingärtner 2011-06-11 15:12:27 UTC
It seems like the bug is fixed in 1.13.7 or some version before.
Comment 46 Anne-Marie Mahfouf 2011-11-30 16:10:46 UTC
Closing according to the last comment.
Please open a new report for KMail2 if you still have this issue in KMail2.