GNOME Bugzilla – Bug 157818
Keyserver support
Last modified: 2005-07-03 14:44:47 UTC
I've been working on keyserver support for seahorse. This bug will track progress.
Created attachment 33625 [details] [review] Patch with basic underlying support This patch contains nearly complete underlying support for keyservers. Keyservers are accessed using the gpgkeys_* plugins similar to how GPA does it. The code has not been debugged or tested. I'm posting it here so people can look at it and possibly contribute comments or ideas.
In libseahorse/gpgmex-keyserver.c, there is a list of #defines from GPG's include/keyserver.h. If GPG changes those defines, will something critically break to let us know they need to be changed? Or can it break in a way that lets someone know they need to be changed? There are a lot of files that only have #include <gpgmex.h> added, but none of the functions in the C file have changed names, while in gpgmex.h, the functions have changed names. Is this because they only use a Macro from gpgmex.h that hasn't changed names, or will this patch not compile?
Thanks for taking a look. Yes, the return values from the gpgkeys_* plugins are copied from gpg. Actually this is how GPA does it. They aren't exposed anywhere in the gpg headers or anything, which is a shame. Perhaps we could request this change in gpg. Yes, I moved the GPG_IS_OK, GPG_E and other macros to gpgmex.h. I'm thinking that gpgmex is where we'll put our extensions to GPGME. Perhaps I should name it seahorse-gpgmex.h. These features should really belong in GPGME, and perhaps the GPG developers will see fit to include them at some point.
Committed all the basic GPGMEX code.
Created attachment 33970 [details] Key search results window Mockup of key search results window.
Created attachment 33971 [details] Key search dialog Mockup of keyserver search dialog.
When displaying the key search results, have we already downloaded all of the keys and haven't imported them yet? If we haven't, what shows up in the properties dialog when you click the properies button? Do we need that button?
You're right, we haven't imported them yet. But we do get information from the server such as: - subkeys - userids - expiry date - revoked status - expired status etc.... My thought was to display the Properties dialog but disable or remove all the fields that we don't have yet (before importing). WDYT?
I think the properties dialog with some of the fields disabled would work. It might be appropriate to place much of this information in the key search results window, much like the regular key manager window does. For instance, we could have columns such as: Name(includes main userid and email address), Key ID, Expiration Date(add a revoked identifier to the expiration date and expired fields of this column), # of subkeys. Then, if more information was desired they could click on properties. I'm not sure that properties is such a good term. Maybe "Key Information"? I do realize that is how we use properties normally though.
I think that we should show the same colums as the user has visible in the key manager window. The only column that doesn't apply is 'Validity' and that could either be hidden, or set to 'Unknown'.
Agreed.
A list of all the basic operations possible on a keyserver search results window. IMPORT FEATURES - Import to local keyring (menu item/ctx menu) - Drag and drop to local keyring window EXPORT FEATURES - Copy key to clipboard - Save Key As... (menu item/ctx menu) - Drag and drop to nautilus UPLOAD FEATURES - Drag and drop from nautilus - Paste key from clipboard - Upload key ... (menu item) OTHER - Key Properties - Key search (starts a new search) Missing anything?
Not that I can think of right now. We will want to add some of the upload functions to the regular key manager window. Additionally in the normal key manager window, we'll want to be able to select one or more keys and update them from a keyserver. There ought to be an update all keys option as well.
Yes, those would be in the main window. Along with a 'search for remote keys' or some such option. MAIN WINDOW KEY SERVER FEATURES - Search for Remote Keys - Upload to Keyserver (selected keys) - Update from Keyserver (selected/all keys)
I really don't get used to bugzilla... BTS is nicer! ;-) Only one point: I don't see the need for being able to upload a key you have just searched for using the new dialog. IMO, upload should be only in main window, as you upload keys from your public keyring to the server. Nice work!
True 'upload' should only be found in the main window. BTW, I'm thinking of removing 'Delete' from the main window toolbar and replacing it with the key server search item. Reasons: - Deleting a key is less frequent action - Deleting a key is context sensitive (as are some other toolbar items, but this is a stroke against it) - We need to encourage others to use key servers in order to perpetuate the web of trust thingy. - Need to limit our toolbar items.
Created attachment 34199 [details] [review] Updated patch for keyserver support Updated patch. Includes keyserver search dialog code.
Created attachment 34206 [details] Screenshot of partially working key server support Many rough edges, but key server support is coming along.
Created attachment 34207 [details] [review] Patch with working (but rough) key server search support It runs, and searches a key server without much fanfare (or even progress updates :)
Committed initial keyserver support. Currently only supports searching, you can't do anything else with the keys.
Created attachment 36403 [details] [review] Adds return keypress functionality to the entry field It was anoying me that pressing return in the entry field of the search dialog didn't start the search. This patch only adjusts the glade file to add an accelerator and map it to the ok_clicked handler the search button uses.
I noticed today that me cvs build sucessfully imported keys from a keyserver. Is this something new you, Nate, committed? How hard would it be to get exporting to a server working if import does indeed work?
The export code is all there but building it into the UI requires the progress dialog support.
Completed LDAP key server support today. Publish and Sync works.
Created attachment 48026 [details] [review] re-adds the press return to search functionality I think this was lost when the dialog was changed to include selecting keyservers and DNS_SD servers.
Looks good to commit to HEAD. I'll do something similar on the stable branch. This patch doesn't apply because the dialog has changed.
Committed to HEAD.