Version: (using KDE Devel) Installed from: Compiled sources pgp/mime emails signed with a now expired key, are shown as with bad signature. probably is known (the code to handle this is commented), but i didn't saw anything like that filed. I see in KMReaderWin::sigStatusToString (kmreaderwin.cpp:1740): 746 switch( status_code ) { (gdb) p status_code $6 = 8 and in the source code: /* PENDING(khz) Verify exact meaning of the following values: case 7: // GPGME_SIG_STAT_GOOD_EXP return i18n("Signature certificate is expired"); break; case 8: // GPGME_SIG_STAT_GOOD_EXPKEY return i18n("One of the certificate's keys is expired"); break; */ Best wishes, Juan. ps. if you want i can attach test case.
i forgot to say the most important thing (and yes the code i paste has nothing to do with the red mark). Using the inline pgp signature, "i get he signature is valid, but the key's validity is unknown." and a yellow mark.
The yellow mark is correct behaviour, as far as I can tell from your description. Note that what you call "inline" actually is PGP/MIME and thus OpenPGP conformant.
So is KMail at fault here or isn't it? Can someone with more knowledge of pgp semantics comment, please?
*** Bug 123288 has been marked as a duplicate of this bug. ***
> So is KMail at fault here or isn't it? I see it as a KMail fault ... the signature is valid - if the email was *sent (and signed) before the expiration date then the signature cannot be invalidated just because time passes; the signature would be invalid if it was *created*, not read, after the expiration date imagine a real world example - you sign some agreement for a limited time frame, e.g. one year; after some more years things go wrong and the agreement becomes important at court ... could you imagine that the judge says, looking at the paper with your signature, that the signature is invalid, the ink on the paper (and the record at the attorney) cannot be taken as a proof that you signed it, just because the agreement has expired a few years in the past?
This is basically a request for more types of trust visualisation. Because of this I'll mark this as a duplicate of a newer bug which in fact asks for a superset of features that would also solve this problem. *** This bug has been marked as a duplicate of 64424 ***