Bug 292405 - KGpg shows wrong key ID for certain keys
Summary: KGpg shows wrong key ID for certain keys
Status: RESOLVED FIXED
Alias: None
Product: kgpg
Classification: Applications
Component: general (show other bugs)
Version: 2.6.x
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Rolf Eike Beer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-25 18:54 UTC by villevallo666
Modified: 2015-01-08 21:52 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.8.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description villevallo666 2012-01-25 18:54:06 UTC
Version:           unspecified (using KDE 4.7.4) 
OS:                Linux

using kgpg 2.6.2 in conjunction with gpg 1.4.11 and importing the keys 0x7282B245 and 0x7CD2EAED, kgpg lists these keys wrongly as 0xEE8FBB5A and 0xF88D8EF4 respectively.

Reproducible: Always

Steps to Reproduce:
using kgpg 2.6.2 in conjunction with gpg 1.4.11 and importing the keys 0x7282B245 and 0x7CD2EAED, kgpg lists these keys wrongly as 0xEE8FBB5A and 0xF88D8EF4 respectively.

Actual Results:  
using kgpg 2.6.2 in conjunction with gpg 1.4.11 and importing the keys 0x7282B245 and 0x7CD2EAED, kgpg lists these keys wrongly as 0xEE8FBB5A and 0xF88D8EF4 respectively.

Expected Results:  
using kgpg 2.6.2 in conjunction with gpg 1.4.11 and importing the keys 0x7282B245 and 0x7CD2EAED, kgpg should list these keys as 0x7282B245 and 0x7CD2EAED respectively.
Comment 1 Rolf Eike Beer 2012-01-26 21:49:18 UTC
This is what GnuPG reports. For whatever reason it shows different things for the fingerprint and public key id.
Comment 2 villevallo666 2012-01-27 00:43:48 UTC
(In reply to comment #1)
> This is what GnuPG reports. For whatever reason it shows different things for
> the fingerprint and public key id.

the lower 32/64 bits of a key fingerprint are not necessarily identical to the key ID! cf. 
<http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-3.1.1.1>
output of 'gpg -k --fin' is correct. kgpg has a bug.
Comment 3 villevallo666 2012-03-19 19:46:59 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > This is what GnuPG reports. For whatever reason it shows different things for
> > the fingerprint and public key id.
> 
> the lower 32/64 bits of a key fingerprint are not necessarily identical to
> the key ID! cf. 
> <http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-3.1.1.1>
> output of 'gpg -k --fin' is correct. kgpg has a bug.

*bump*
Seems like there are no serious kgpg users out there. Did actually anybody compare what's shown by kgpg and gpg for the keys in question (no matter if short or long keyid-format)?
Comment 4 Rolf Eike Beer 2012-03-19 20:57:19 UTC
I read the thing you posted in your URL as follows: if there is a 160 bit 
fingerprint and you want the 32 bit key id from it, use the low-order 32 bits. 
And that is exactly what KGpg does for your key (and any other). In fact this 
is the first key where I ever see that these things don't match. And I quite 
don't understand yet why.

If you want to get this fixed you have two options: send a patch with a good 
description of what is happening or show me that this has hack value. Flaming 
only drops this to the bottom of the list of things I will hack on.
Comment 5 villevallo666 2012-03-20 13:50:33 UTC
(In reply to comment #4)
> I read the thing you posted in your URL as follows: if there is a 160 bit 
> fingerprint and you want the 32 bit key id from it, use the low-order 32
> bits. 
> And that is exactly what KGpg does for your key (and any other). In fact
> this 
> is the first key where I ever see that these things don't match. And I quite 
> don't understand yet why.
> 
> If you want to get this fixed you have two options: send a patch with a good 
> description of what is happening or show me that this has hack value.
> Flaming 
> only drops this to the bottom of the list of things I will hack on.

Sorry, flaming wasn't intended.

"it is not possible to calculate a 64-bit or 32-bit keyid from a v3 fingerprint." is what I wanted to point out by that URL. Guess I should've referred to the whole #section-3.1.1 or to #section-3.1.1.2.

Sorry for not knowing any C/C++. The fact that kgpg obviously interprets the lower 32/64 bits of a v3 fingerprint as the key id instead of relying on gpg makes this fix mandatory.

Thanks for your time an effort!
Comment 6 Rolf Eike Beer 2012-03-20 19:41:11 UTC
Git commit 2a100ae8d203107d17e438f67f65d26a4949cccc by Rolf Eike Beer.
Committed on 20/03/2012 at 20:39.
Pushed by dakon into branch 'KDE/4.8'.

distinguish between key id and fingerprint

M  +5    -5    core/KGpgKeyNode.cpp
M  +3    -3    core/KGpgKeyNode.h
M  +4    -4    core/KGpgOrphanNode.cpp
M  +2    -2    core/KGpgOrphanNode.h
M  +2    -2    core/KGpgUatNode.cpp
M  +12   -4    core/kgpgkey.cpp
M  +4    -2    core/kgpgkey.h
M  +2    -2    kgpginterface.cpp
M  +1    -4    model/keylistproxymodel.cpp
M  +15   -1    model/kgpgitemmodel.cpp

http://commits.kde.org/kgpg/2a100ae8d203107d17e438f67f65d26a4949cccc
Comment 7 Rolf Eike Beer 2012-06-11 17:59:16 UTC
Git commit 2d252cf08c51866a6acebe705db11b29941691bf by Rolf Eike Beer.
Committed on 11/06/2012 at 19:29.
Pushed by dakon into branch 'KDE/4.8'.

fix key comparison returning wrong values

This fixes a regression introduced in 4.8.2 with commit
2a100ae8d203107d17e438f67f65d26a4949cccc when trying to fix bug 292405.
Related: bug 298465, bug 301618

M  +7    -5    core/KGpgKeyNode.cpp

http://commits.kde.org/kgpg/2d252cf08c51866a6acebe705db11b29941691bf