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.
This is what GnuPG reports. For whatever reason it shows different things for the fingerprint and public key id.
(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.
(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)?
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.
(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!
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
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