Bug 341760 - Objecttreeparser will display the latest added key when displaying who signed an email.
Summary: Objecttreeparser will display the latest added key when displaying who signed...
Status: RESOLVED WORKSFORME
Alias: None
Product: kdepim
Classification: Applications
Component: messageviewer (show other bugs)
Version: GIT (master)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-12-10 20:44 UTC by Dan O.
Modified: 2018-10-27 03:54 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan O. 2014-12-10 20:44:03 UTC
When I receive a signed or encrypted email, objecttreeparser will properly verify or encrypt the email, and set the proper color in the email. What then happens is that the message signer and key id are displayed as whatever the latest key i added to my database is. This is merely a cosmetic issue, but it's incredibly annoying and may unveil a larger issue.
The issue lies in ObjectTreeParser::writeOpaqueOrMultipartSignedData. The contents of 'result' are correct, result = m->verifyResult(); returns the proper signing key information. The contents of 'key' however have the wrong key, and that's what ends up getting displayed. That is set by key = m->signingKey();.

I added debugging strings to track down the issue. My keystore contains 7 keys, for reference. 
My example email has been signed by mgorny. 
qDebug() << "There are " << key.numUserIDs() << " in the key of " << key.userID(0).email() << " ID"; for whatever reason returns "There are  4  in the key of  kristian.fiskerstrand@sumptuouscapital.com  ID", later debugging shows that key.keyID() equals 0B7F8B60E3EDFAE3.

Conversely 'result', which should contain similar information to key actually does not. 'result' actually contains the correct information, and reports the fingerprint as the correct key of B07A1AEAEFB4464E.

The issue here appears to be that either key = m->signingKey(); is returning the completely wrong key, or that different code should be used to return said key.

Reproducible: Always
Comment 1 Sandro Knauß 2017-01-18 20:36:04 UTC
Is this still an issue with KDE APplications 16.X? 
There were many changes regarding verification and excryption, so it makes sense to test again.
Comment 2 Andrew Crouthamel 2018-09-26 22:22:47 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Andrew Crouthamel 2018-10-27 03:54:59 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!