GNOME Bugzilla – Bug 109305
libseahorse to provide common crypto components for gnome apps
Last modified: 2004-12-22 21:47:04 UTC
The following is probably better suited to some kind of Gnome App Enchancement Proposal, but as far as I know that does not exist. libseahorse could provide the following: 1) API (ABI?) consistency Gpgme is not API or ABI stable. Because of this users must either jump through hoops to have both installed (unless you use gentoo ;) or have to choose between sets of apps. libseahorse could provide a consistent library that would work with any reasonable[1] version of Gpgme. 2) Code simplification Apps using libseahorse would not have to deal with the intricacies of Gpgme[2] and could instead use 'sugar' functions. Since this is a library, all apps using it would benefit for bug fixes, etc. It would also use common glib structures and utilities, such as a GList of user IDs instead of a GpgmeRecipients that must contain keys. 3) Common dialogs, controls libseahorse could provide a passphrase dialog, a bonobo control to show a signature verification status, and a bonobo control for configuring gpg(me). Users would then benefit from a common interface no matter what app they use. The passphrase entry could also support saving a passphrase for a session, provided some way to notify the library of the end of a session. 4) Common configuration The configuration control would allow users to select: * encrypt to self: if selected, the default key would always be added to an encryption recipients list * default key: this would also be the default signing key * ascii armor: this isn't necessarily applicable to all apps[3], but would affect the encryption and signing of files 5) Common error dialogs This may not be necessary, but could be helpful and remove some of the burden from app developers. What I want to know is would apps use this library, and if so what else would be needed? I imagine the following set of operations[4], though more can be added: * import: from file path or text, returns number of keys added * encrypt: from a file path or text given a recipient list, returns the new file's path or the encrypted text * sign: from a file path or text, returns the new file's path or signed text. For text would use clear sign, for files would create a detached signare. There would also be corresponding methods to sign with a specified key. * decrypt: from a file path, file part, or text, returns the new file's path or the decrypted text given the file part or text * verify: from a file path, file part, or text, returns the verification status [1] Reasonable being the latest of a stable branch and at least the latest of an unstable branch, but possibly more. [2] The only items I can currently imagine being used by the app are GpgmeError and GpgmeSigStat [3] Could apply to any app that deals with file attachments: email, IM [4] All operations returning text would return utf8 valid text no matter what the ascii armor setting is
Because it makes sense and would be easier than doing another way, libseahorse could also provide a nautilus component and preferences capplet. Also, I think it would appropriate to store configuration in gconf:///system/gpg/. Please correct me if I'm wrong.
OK, a few notes here, as I'm a moderate user of GPG and such. Most of my GPG use is through Gabber (GNOME Jabber client, supports GPG encryption of messages), and through Evolution. Both of these are GNOME 1 applications at the moment, and both have GPG support that pre-dates the existence of gpgme (AFAICT). They use GnuPG directly. Comments point by point: 1) The apps I use don't use gpgme, so don't care about it's API problems. They haven't generally had any problems with gnupg compatability, except for a bug in 1.0.7 which broke a few things. What does using gpgme buy one over using GnuPG directly? 2) This sounds sane, but why is gpgme complex? Seems like gpgme is just a wrapper for GnuPG, and if so, having another wrapper is redundant. The other part of this is pretty techincal, and I didn't follow it. 3) This sounds like a really "high level" API for managing GnuPG. If that's the idea, then this sounds good to me. Not sure exactly how it's different from the 2, though. 4) Isn't the "default key" thing already handled by GPG? Or are you just proposing the things that need to be configurable by the interface, and not that these things are seahorse specific? As for the ASCII armor, I think it ought to be "hard" to make that the default for sending email, as there is an RFC for the right way to sign/encrypt email. 5) Why is this separate from 3? What apps would use this library? Mail/chat clients, and the file manager. Not sure what else, though. Import would also "need" the ability to go out and "find" a key based on keyid, IMO. I think that's all at the moment, though I think this sort of discussion belongs on the desktop-devel-list far more than bugzilla. Though perhaps putting together a good proposal to send there is worthwhile.
> What does using gpgme buy one over using GnuPG directly? AFAICT it basically does all the parsing work and abstracts things into data structures. It can also support different backends such as gpgsm. > why is gpgme complex? Seems like gpgme is just a wrapper for > GnuPG, and if so, having another wrapper is redundant. Each operation requires a gpgme context that may need to have a passphrase callback or set the signing key. Another wrapper may seem redundant, but it would be needed in order to be able to use common preferences to set the signer and have common passphrase dialog and configuration between apps. > Isn't the "default key" thing already handled by GPG? Maybe, but not really in gpgme (at least not completely) > Why is this separate from 3? Because I didn't put it there (?) > What apps would use this library? Any document related app could save users the step of having to do the op in nautilus. It could also allow clear signing of docs. Gedit is a good example. > Import would also "need" the ability to go out and "find" a > key based on keyid, IMO. I'm taking this to mean an intelligent search that will transparently get a key based on a keyid. This would be needed if the user wants to encrypt to someone and does not have that key. Yes, this would be awesome and certainly seems possible.
Balsa people said that they might use libseahorse if it provided an interface for automagically getting keys from a key server. They also mentioned that their gpg support is temporary until gmime is usable. So, I think the best thing to do would probably be to bug gpgme people for keyserver support, and possibly help out with the pgp/gpg aspects of gmime. I believe gpgme is also planning (in the far off future) to provide bonobo controls. So I'm going to close this and continue working towards 0.8, which should have a nautilus component & possibly a gedit plugin.