GNOME Bugzilla – Bug 774611
Fails to display the signing key when it has multiple subkeys
Last modified: 2017-01-12 12:29:21 UTC
Created attachment 340120 [details] Test signed file Steps to reproduce the issue: - import the key in test.asc (`gpg --import test.asc`) please note this key has two subkeys. - save test and test.asc in $FOLDER - `cd $FOLDER` - `seahorse-tool --verify test.sig` Issue: the notification shows "Good Signature Signed by on 2016-11-16" please note there is nothing between "by" and "on". Expected result: the notification should show "Good Signature by Seahorse bug test key <test@example.org> on 2016-11-26"
Created attachment 340121 [details] Test signature
Created attachment 340122 [details] Test signing key
Actually the issue is specifically when the signing key ID is not the "primary" key ID. In practice, so long as it's not the first subkey reported by GPGME (which is used as the primary ID).
Created attachment 340131 [details] [review] daemon: Add a hack to find subkeys identities The SeahorseContext does not contain PGP subkeys IDs, so is unable to find the object corresponding to them. This is problematic for example for finding the identity corresponding to a signing key if that key ID is a subkey of the primary PGP key. For the moment, add a hack to search through all PGP keys and check whether they have a corresponding ID when the normal hash table lookup failed. A better solution might be registering the subkey IDs in the context's hash table so that the normal lookup would find the corresponding key. However, such a change is not trivial as each module is not responsible for registering with a specific ID but only for reporting one single ID corresponding to the key to add. Also, registering subkey IDs might have more deep incidence on other code, which makes it a riskier change when not being familiar with the code base.
Created attachment 340132 [details] [review] daemon: Fall back to displaying the key ID if the key is not found Better display a key ID in the notification than nothing at all. This should not really happen once the first patch is applied, but I still think that it's better to have fallback code to display *something* for the key in the notification, as otherwise it just results in an empty placeholder.
As said, the first patch really fixing the issue here is quite ugly and dirty. If having subkeys in `sctx->pv->objects_by_source` doesn't break anything, a slightly better yet reasonably simple fix might be to alter `seahorse_context_take_object()` to add an entry for each SeahorsePgpKey's subkeys. It would still be ugly as it requires SeahorseContext to still special-case handling of SeahorsePgpKeys, but well, it seems that SeahorseContext already only really handle PGP at this time, as suggested by the comment in `seahorse_context_canonize_id()`.
Merged into libcryptui git master. Thanks for the changes. They make sense. This library is on its last legs, however. Attachment 340131 [details] pushed as bdd2fd5 - daemon: Add a hack to find subkeys identities Attachment 340132 [details] pushed as 6a4d4b8 - daemon: Fall back to displaying the key ID if the key is not found