Bug 64424

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. 
 

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?

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.

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

iD8DBQE/aaG5W6pHgIdAuOMRAm35AJ9OwhO07wvvxR74WitG4kDktrtDawCeKeW1
qgwk59xSWGoXNL6m9C+dd3E=
=KKwc
-----END PGP SIGNATURE-----

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. 
 
 

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

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

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 :)


Richard

PS: My bug will assimilate them all! mwhaha! or something ;)

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)

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.

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.

Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.

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...

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.

(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?

(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...