GNOME Bugzilla – Bug 312064
Default Key Widget makes it impossible to Distinguish between identically labeled keys
Last modified: 2012-03-09 17:36:55 UTC
1. Create a key and label exactly like another. i.e. Same name and/or email address. 2. Open Preferences and select encryption settings. 3. Default key widget shows the same information for both key pairs Solution: Add keyid to default key widget
Good point. Although so we don't overwhelm the user we should probably only display IDs for keys that would otherwise display the same text.
Hmmm, after thinking of it further (and thinking of the future work I'm going to do) the way to implement this would be to create a SeahorseKey property: display-name (and accompanying seahorse_key_get_display_name). This property would calculate the name properly (appending the Key ID if needed) and we'd use this everywhere we currently lookup the first UID. I think this would help make things consistent.
Created attachment 54553 [details] [review] Fixes Bug as Nate Suggests
I added a seperate function because the short id showed up in the key manager as well, right next to the key id column.
I think the patch only adds the keyid when there's no email or comment. The original plan was to add a short keyid only when two keys (anywhere in a seahorse context) had identical username/email/comment. My implementation comments applied to seahorse before we refactored everything. The way to do it now would probably be in SeahorseContext, that's the only place that knows about all the keys that exist, and it could find colisions (maybe using a GQuarks or GHashtable, not sure exactly how I would do this) between display names and append the keyid. A function like seahorse_context_get_key_display_name would be necessary. Or maybe there's a simpler way to handle this?
Could a function similar to the filter on the key manager window work? Limit the results to the private keyset and when the results are greater than 1 append the short id.
Created attachment 65628 [details] [review] Differentiates key ids This patch implements two callback functions that determine if an additional identifier is needed and appends the short keyid if a duplicate display name is found.
I was sort of thinking of doing this in SeahorseContext, so we can have this support everywhere. It's a bit complex though, so I've been putting it off.
Idea: When a key is loaded, the Display name is loaded into a hash table, with the key id attatched, i.e. openpgp:FFFFFFFFFFFFFFFF. When someone queries the Display-Name property, the code that grabs that and returns it checks the hash table in the context first to see if the keyid returns matches it's own. If it doesn't, it appends the short keyid onto the display name. This of course would depend on the more unified key name bug.
I don't consider this a GNOME 2.28 target blocker. Setting the module specific target milestone instead.
Yes, I used the wrong field. Sorry for the extra work.
Any plans on fixing this in time for 2.28? Seeing two identical keys in seahorse-preferences is pretty disappointing.
Fixed in gnome-3-4 branch. commit aca5d826a827eff06de22c9742481d22f7cfe048 Author: Stef Walter <stefw@gnome.org> Date: Fri Mar 9 18:27:43 2012 +0100 Fix issue when multiple keys with same label in signer list * Add keyid after the user id if there are multiple keys in the combo are the same. https://bugzilla.gnome.org/show_bug.cgi?id=312064