<table><tr><td style="">aheinecke added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D3140" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>Regarding Björns comments. For case 1 I agree.</p>

<p>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.</p>

<p>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.</p>

<p>There is a small rationale for this given on:<br />
<a href="https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Attaching_a_pubkey_to_all_emails" class="remarkup-link" target="_blank" rel="noreferrer">https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept#Attaching_a_pubkey_to_all_emails</a></p></div></div><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D3140#inline-12215" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">aheinecke</span> wrote in <span style="color: #4b4d51; font-weight: bold;">pgpkeymessagepart.cpp:81</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Yes,... *blushes for gpgme*</p>

<p style="padding: 0; margin: 8px;">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.</p>

<p style="padding: 0; margin: 8px;">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 :-/</p>

<p style="padding: 0; margin: 8px;">In qt this would be a keylistjob that takes a QByteArray.</p>

<p style="padding: 0; margin: 8px;">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.) :-)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">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: <a href="https://bugs.gnupg.org/gnupg/issue2819" class="remarkup-link" target="_blank" rel="noreferrer">https://bugs.gnupg.org/gnupg/issue2819</a></p>

<p style="padding: 0; margin: 8px;">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)</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>rKDEPIMADDONS KDE PIM Addons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D3140" rel="noreferrer">https://phabricator.kde.org/D3140</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>dvratil, aheinecke, mlaurent, bjoernbalazs<br /><strong>Cc: </strong>knauss, emanuel, mlaurent, kde-pim, KDE PIM, spencerb, dvasin, winterz, vkrause, dvratil<br /></div>