Bug 64424 - More fine grained color coding of GPG/PGP signed messages in KMail (wishlist)
Summary: More fine grained color coding of GPG/PGP signed messages in KMail (wishlist)
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 4.10.1
Platform: Debian stable Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
: 59626 87358 (view as bug list)
Depends on:
Reported: 2003-09-17 12:11 UTC by Richard Hartmann
Modified: 2013-03-08 09:21 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Richard Hartmann 2003-09-17 12:11:07 UTC
Version:            (using KDE KDE 3.1.3)
Installed from:    Debian stable Packages
OS:          Linux

I am not quite sure if this wouldn't belong to KGpg, but i had to choose one of them :)

When Kmail can validate a signature, but does not trust it, it's yellow. When KMail can not validate a signature, it's yellow, also.

One could, for example, make the second kind appear orange. It would just be convenient to be able to see these things at a glance.

Also, one could use different colors for different trust level (if this is already implemented excuse me, i never received trusted mails as of yet, still have to go to a signfest)

If the color coding is according to any standard you don't want to change, just forget this wishlist item :)

Comment 1 Ingo Klöcker 2003-09-17 17:37:41 UTC
You can specify different colors for 
a) OpenPGP message - encrypted 
b) OpenPGP message - valid signature with trusted key 
c) OpenPGP message - valid signature with untrusted key 
d) OpenPGP message - unchecked signature (because of unknown key) 
e) OpenPGP message - bad signature 
The default color for c) and d) is yellow. But you can of course specify 
different colors. In fact, the default color for d) should be red because if 
the signature can't be checked it is potentially a bad signature. 
Comment 2 Richard Hartmann 2003-09-17 21:10:04 UTC
Subject: Re:  More fine grained color coding of GPG/PGP signed messages in KMail (wishlist)

At the risk of sounding stupid: where can i set this?

Comment 3 Brad Hards 2003-09-18 14:16:48 UTC
Subject: Re:  More fine grained color coding of GPG/PGP
 =?iso-8859-1?q?signed=09messages_in_KMail?= (wishlist)

On Thu, 18 Sep 2003 05:10 am, Richard Hartmann wrote:
> At the risk of sounding stupid: where can i set this?
Settings->Configure KMail...->Appearance->Colors on my box.

We probably should think about the color defaults a bit more though.

Version: GnuPG v1.0.7 (GNU/Linux)


Comment 4 Bernhard E. Reiter 2003-09-22 19:43:32 UTC
Note that c) and d) basically are the same case: 
"not enough information to check the signature". 
And it just means this, not more, not less. 
It basically should be treated by the user as if there was no signature. 
Everything else is really hard to understand for the huge majority 
of users. 
Finer grained information are only useful in the rare case  
that you want to into the crypto mode administration and change 
something about the keys and the trust you have. 
Comment 5 Rolf Eike Beer 2007-09-19 19:31:52 UTC
*** Bug 87358 has been marked as a duplicate of this bug. ***
Comment 6 Rolf Eike Beer 2007-12-13 13:11:08 UTC
*** Bug 59626 has been marked as a duplicate of this bug. ***
Comment 7 Richard Hartmann 2007-12-13 13:32:18 UTC
Bernhard: Not quite. c) tells me the sender actually did the work required to generate a key. While this may seem to be irrelevant, there are several scenarios where this would help. For example, you could filter on it (definately not spam), it could provide a means of identification while maintaining anonymity or you can prove that the sender has put in enough computational effort the generate and sign the message. It would also tell you that your web of trust is not complete and, if you know the person reasonably well, try to close the missing link (yes, i know any two distinct general-purpose separate webs of decent size will interlink, over time)

Rolf: Thank you for your cleanup work :) Are there any plans to work on this for KDE4.1? As you are redoing the interface and everything anyway, this seems like the perfect opportunity to do so.

In any case, thank you for your work :)


PS: My bug will assimilate them all! mwhaha! or something ;)
Comment 8 kavol 2007-12-13 15:01:21 UTC
note, to marking bug 59626 duplicate, the point in that bug is about wrong signature status identification, not about color code (using comment #1, it's like having wrong letter assigned, not that the user does not see color difference between the letters), so it is not a duplicate - however I do not object against dealing with these things together ;-)

@Rolf - thanks for trying to sort out the old issues ... does it have anything to do with the recent threats about throwing all bugs away? (I really do not like this idea ... this bug is an example, this is a feature that really should make it into some near-future version of kmail)
Comment 9 Richard Hartmann 2007-12-18 19:26:49 UTC
In light of the impeding KDE4 release, I am going through all bug reports I am involved in. To the best of my knowledge, this issue is still open.
Comment 10 Myriam Schweingruber 2012-08-18 07:59:31 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 11 Luigi Toscano 2012-08-19 01:00:03 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
Comment 12 A. Sala 2013-02-26 15:22:44 UTC
At least part of these requests still apply to the version of Kmail shipped in KDE 4.9.5, as follows:

The issue with "expired signatures" signaled as "bad signature" in red should be, indeed, better handled (at least yellow, or arguably "green" if signature valid when the message was received by Kmail --I guess not "time when sent" because that can be spoofed--). 
I think this is a "bug" because signed messages before expiration are valid even if the signature later expires. In fact, that is what reporters of bug 295043 think, too. Please update status of either this wishlist and/or the referred bug accordingly.

So, apart from the other cases, information on expired signatures should be clearer... I guess "yellow" with extended info such as "warning: public key expired on 2013/02/04, but was valid at the time of message reception". Maybe a similar warning with revocations...
Comment 13 A. Sala 2013-03-07 13:40:02 UTC
After updating today, the above issue (comment 12) does apply (expired signature flagged in red as "bad") to KDE 4.10.1.
So, the wishlist (if anyone is still listening to this old thread), is still valid as of KDE 4.10.
Comment 14 Luigi Toscano 2013-03-07 22:03:24 UTC
(In reply to comment #13)
> After updating today, the above issue (comment 12) does apply (expired
> signature flagged in red as "bad") to KDE 4.10.1.
> So, the wishlist (if anyone is still listening to this old thread), is still
> valid as of KDE 4.10.
Thank you for checking.
Do you think that this could be considered a complete duplicate of 295043 now, or that they are still slighly different?
Comment 15 A. Sala 2013-03-08 09:21:18 UTC
(in reply to comment #14)
Well, I think that one thing is the "bug" which is well detailed in 295043: a signature "neither expired, nor revoked" at "the time of Kmail receiving 1st time the message" should be "valid", according to the trust of the signature.
So, indeed, that is a BUG: a valid signature is flagged as invalid by Kmail.
In fact, 295043 is a duplicate of 59626: this issue is hanging around since __2003__, wow!!!

So, then, a different issue is how do deal with that bug in the user interface. Of course, it will be up to the developer which fixes the bug, and maybe he will think on an easier/different solution as the proposed here. 

Thus, this "bug 64424" (wishlist for user interface) suggests to give by default additional information such as different colour for two possible issues "valid at the time of reception, but now expired", "valid at the time of reception, but now revoked", which combined with the original trust level might make the user think about double-checking.

So, in general, I think that they are not "exactly" the same: 295403 requires correcting the bug in whatever way kde developers think of. 64424 suggests how to do it via potential further information in the user interface that would fix the bug and provide more accurate info to the user. So, I guess that bug 295403 should be marked as a "subset" of this one, similarly to bug 59626.

To summarise my interpretation of 64424 whishlist:
Kmail2 provides NOW different colours for
 a- openpgp encrypted
b- openpgp signed valid trusted
c- openpgp signed valid untrusted
d- openpgp signed cannot check validity
e- openpgp wrong signature

although default for c,d are the same (yellow). 
Bug 295403 says that some messages are wrongly flagged as "e". I aggree.

This "wishlist" suggests a new set of status variables and associated colours and text in Kmail message display, at least consisting of:
 a- openpgp encrypted
b- openpgp valid signature ultimately trusted (green default)
c- openpgp valid signature untrusted (even c1, c2... for several trust levels? too complicated maybe) (yellow default)
d- openpgp signed cannot check validity (yellow default)
e- openpgp valid when received, now expired (might be green by default: expired without revocation doesn't raise any particular suspicion)
f- openpgp valid when received, revoked at a later date (might be red/orange by default... revoked signatures must raise suspicion, but the Kmail _text_ info must not be the same as "g")
g- openpgp bad signature

Disclaimer: I am neither a crypto expert at all, nor a software developer... I'm a plain end user playing with gpg signatures "just to learn", and I am not knowledgeable on the policies for setting kde bug status... so others will be able to make better suggestions and do the right "fusion" between this and 295403... but somebody might have a look at this 10-year-old pending thing...