Re: [Patch] Gpgme-related improvements

[Peter Bloomfield <PeterBloomfield bellsouth net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Albrecht:

On 07/01/2017 04:05:04 PM Sat, Albrecht Dreß wrote:
> Hi all,
>
> attached is a patch with several gpg-related improvements and simplifications.
>
> 1. Do not call gpg directly
> Gpgme supports listing external keys (i.e. on key servers) as well as importing keys from key servers into the local 
> key ring and updating keys in the local ring from key servers.  Thus, I replaced the operations talking directly with 
> gpg by the respective Gpgme operations which simplifies the code and gives better feedback to the user as gpgme takes 
> care of parsing the version-dependent gpg output.  And as there is no need for telling gpgme which gpg application to 
> use, we can completely drop the "--with-gpg-app" config option.  A new module (libbalsa source file) 
> implements helper to list keys and to run a key server operation as new thread.
>
> 2. S/MIME support
> It does not make sense to switch off s/mime support as its support in gpgme is completely stable since years, and we 
> check the availability of the various engines on start-up anyway.  I removed the "--enable-smime" configure 
> option which also removes some of the nasty #ifdef's in the code.
>
> 3. Convenience widgets
> For a nicer (I hope...) display, I wrote widgets for displaying a key's data and a key-related message 
> dialogue.  The key widget shows the relevant data in a more structured way and highlights expired, revoked, 
> etc. data clearly (try a message I send before December 2105; I revoked the old key).
>
> 4. Crypto workflow improvements
> Searching a key by mail address now requires an /exact/ match.  The old code would find the key for UID "some user isp 
> com" if the recipient is actually "user isp com" (substring match) which was actually wrong.
>
> If no key for encryption matches the recipient's mail address, Balsa shows a list with all keys as to handle 
> the case that a recipient failed to add the proper uid to the key.  However, the list was also shown in the 
> following case:
> - recipient's key exists with low trust
> - do not automatically accept low trust keys, so show the confirmation dialogue
> - user rejects the key (i.e cancel the operation)
> - the full key list is shown despite the cancellation
> Now cancel will /really/ cancel the operation.
>
> 5. Documentation and coding style
> Following my recent criticism, I tried to add Doxygen documentation and to follow Peter's proposed coding 
> style.
>
>
> Possible improvements:
> (a) in the key list selection dialogue, instead of showing few key details in extra columns, we could add a 
> hotkey/context menu to show the full key details in the new key dialogue;
> (b) listing all keys is slow, in particular if the local key ring is large.  Thus, we might want to show 
> something like a spinner while loading the key list;
> (c) in the send message dialogue, the protocol selection radio options (pgp/mime, openpgp, s/mime) are not 
> properly disabled if the respective protocol is unavailable.  I have no idea (and did not find any 
> documentation) how only /one/ radio item of a GAction can be disabled;
> (d) we might want to add an option to the message composer dialogue to check the key server (not only the local key 
> ring) if keys for recipients are available, but not yet in the local key ring.  When EasyGPG (see 
> <https://wiki.gnupg.org/EasyGpg2016>) has been fully implemented, GpgME will use WKD/WKS for that;
> (e) modern gpg versions will /always/ use pinentry.  So we might want to remove the code reading a key's 
> passphrase using out callbacks.
>
>
> As always, any feedback will be highly appreciated!
>
> Cheers,
> Albrecht.

Thanks for the contribution--that's great in so many ways! I checked messages with both a valid key and that 
revoked key--you've nicely clarified the display. I haven't had a chance to explore the other improvements, 
and I'll be on a slow-to-non-existent connection for the next week; I pushed the changes to master, so that 
we can all play with them.

Thanks again, and best regards,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAllY0w8ACgkQH1/UtbkqdPW0GwCeO87Mtg+1m3VSj5cWXNianwPA
SewAoJlaCNEtGJqyS/xtw/WVSryLn0kW
=M9ms
-----END PGP SIGNATURE-----