Does not show fingerprint in key import dialog
Bug #1257939 reported by
itzeme
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
seahorse |
Fix Released
|
High
|
|||
seahorse (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
Using the seahorse option to find and import remote public keys, the properties dialog does not show the correct fingerprint but the key ID instead.
to reproduce:
go to remote, find remote keys, enter a valid search term, select a key from the results and select properties in the context menu of the selected key.
bug was confirmed using the following versions:
3.10.1 (using ArchLinux)
3.2.2 (Using Ubuntu 12.04.3)
information type: | Private Security → Public Security |
Changed in seahorse (Ubuntu): | |
status: | New → Triaged |
Changed in seahorse: | |
importance: | Unknown → High |
status: | Unknown → New |
Changed in seahorse: | |
status: | New → Confirmed |
Changed in seahorse: | |
status: | Confirmed → Fix Released |
To post a comment you must log in.
I presume this is due to some limitation in the key search protocol that is being used. Compare the following two sks keyserver searches:
http:// pool.sks- keyservers. net:11371/ pks/lookup? op=vindex& search= seth.arnold pool.sks- keyservers. net:11371/ pks/lookup? op=vindex& search= seth.arnold& fingerprint= on
http://
Perhaps 'fingerprint=on' isn't an option on all keyservers? Or perhaps they are using a more meager search mechanism that doesn't expose this information cheaply.
Once the key _has_ been imported, the fingerprint is then available.
This might also be a failing at the GPGME interface level; I understand gpg --recv-key, when given a fingerprint, will download a key matching only the keyid, and it does not verify that the fingerprint matches before saving the key into the keyring. I'm having trouble tracking down a reference for this behavior though.