[Differential] [Commented On] D3140: Add formatters for application/pgp-keys and application/vnd.gnupg.wks body parts

[aheinecke (Andre Heinecke)]

aheinecke added a comment.


  Regarding Björns comments. For case 1 I agree.
  
  For case 2 I think a dialog / deep check if the key updates the key in the keyring should be out of scope of this patch. I would also dislike a dialog as we already have the messageviewer and are able to display various actions in the messaageviewer.
  
  I would say let's add some functionality for handling pgp-keys and then we can probably improve on that. I don't see much usecases for attaching the public key and in EasyGPG we rather discourage it in favor of Web Key Directories / auto-key-retrieve on signed messages. So I would rather encourage users to publish their key out of bounds.
  
  There is a small rationale for this given on:
  https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Attaching_a_pubkey_to_all_emails

INLINE COMMENTS

> aheinecke wrote in pgpkeymessagepart.cpp:81
> Yes,... *blushes for gpgme*
> 
> And we need one here. This is fragile and dangerous. We can have multiple keys in a application/pgp-keys file. This would only show the last one. When a user is then offered to import the key (which I suggested in my other comment) he can be tricked into importing multiple keys with different fingerprints / userids. Also without an action gnupg determines by itself what it does with the data. E.g. try to decrypt it. I can't really think of an attack that could utilize this but maybe.
> 
> I've written a new gpgme command for this gpgme_op_keylist_from_data which takes a gpgme_data_t and returns a keylistresult. Just need to get it upstream, which is surprisingly a bit difficult as I use "gpg --import-options import-show --dry-run --import" where upstream says that this is not technically a keylisting :-/
> 
> In qt this would be a keylistjob that takes a QByteArray.
> 
> I'll let you know when we have API for that. (But Packagers will not like us if we depend on unreleased again. So maybe we should then use that with an Ifdef version guard.) :-)

Upstream didn't accept my first patch as there are multiple ways to implement it and the best way (imo) is only available with a very recent gnupg version. This needs some discussion but it was pushed back with a "There are more important things at the moment". So this feature will come but not super soon. I have an issue for this: https://bugs.gnupg.org/gnupg/issue2819

In the meantime your hack is probably ok (Although as with the other gnupg process call it would be better to use GpgME::Engine info to figure out which "gpg" to call)

REPOSITORY
  rKDEPIMADDONS KDE PIM Addons

REVISION DETAIL
  https://phabricator.kde.org/D3140

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dvratil, aheinecke, mlaurent, bjoernbalazs
Cc: knauss, emanuel, mlaurent, kde-pim, #kde_pim, spencerb, dvasin, winterz, vkrause, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20161031/cdff61dc/attachment.html>