Hi Jeff: Am 15.03.17 01:55 schrieb(en) Jeffrey Stedfast via balsa-list:
So I took a look at the gpgme code in libbalsa, specifically the code that deals with prompting the user about selecting a key to use for signing and/or whether or not to trust a low-validity key. It looks like this could largely be done *before* calling GMime methods.
Yes. Actually it /should/ be done before! It also offers new options, like linking preferred key id's to users in the address book (as in Kontact/Kmail).
In the case of selecting a key, you could simply pass the fingerprint (instead of the email address) if the key as the userid argument to g_mime_*sign().
Or, as the bulk of work (GUI interaction etc.) has to be done by the caller anyway, as a GList of gpgme_key_t items - which saves you the (costly) lookup operation!
I could possibly add a GMimeSelectKeyCallback to GMimeCryptoContext or something for the select key thing…
IMO, there are three different situations when we pass a list of user-id's (i.e. mail addresses) to GMime: - There is exactly /one/ matching key for the user reported by gpgme. No callback is necessary. - Gpgme reports multiple matching keys. Even if the callback returns the list of matching keys, the caller still has to deal with the GUI, including the option to cancel the whole process. - There are no matching keys, e.g. because the message shall be sent to an alias which is not included in the key's user id's. In this case, the caller must list /all/ keys, and again the process could be cancelled. I think if the GMime encrypt function would expect just a list of gpgme_key_t's, which shall be assembled by the caller, this would simplify everything a lot, inter alia eliminating the cancellation path from the callback. Listing keys/certificates is an expensive operation, btw, in particular if the key ring is large, or if the cert store is slow (like a remote ldap server). The callback approach might require the same operation several times, which could actually add a considerable delay. So, you are right, all the key selection work should be done /before/ calling GMime!
I could possibly do something similar for making sure that the user wants to encrypt to a low-validity key.
Again, I think this should be done before calling GMime. If the caller includes untrusted keys in the gpgme_key_t GList and doesn't set the proper option for the GMime method, just fail with an appropriate error code. A callback might be called multiple times if the GList contains more than one untrusted key which is tedious. If the caller is responsible, the GUI could be optimised (e.g. in a dialogue like "The following n keys are untrusted: <show the complete list>"). Cheers, Albrecht.
Attachment:
pgp9rWkfczdgF.pgp
Description: PGP signature