With the last release we improved the handling of sent mails, again.

Without more reports and without the info needed to analyze this further I'm lowering the priority.

I've applied your patch with an additional comment to our master branch. Thanks!

I think this can go to wontfix for now. Inline PGP inside of S/MIME,.. well that is not good.

I am pretty sure that this had the same underlying cause as T4332 which was fixed with Gpg4win-3.1.7

With the new keytreeview since 45f27eb3940617a8daff9b218b066ac482b9515d this is resolved.

This was fixed with c591cb20edfe70de29d343a6ce13c4b710bdeba6

This was resolved in a different way.

This was fixed.

Closing this as invalid until the info requested in the last comment is provided.

@werner This issue also applies to GPA. Looking at the edit key interface I can't see how we can handle this. Am I overlooking something or do we just loose the error information / is it not emited by gnupg?

Are you sure that it is related to accounts and not to the mail? E.g. if you copy that mail from the second account to the first account, is it verified then?

makes sense to me. I've applied your patch so it will be part of the next release.

I have a fix. I'll commit it later.

Fixed with: https://commits.kde.org/libkleo/245eff174331c49264d1248c529e0276e02e9e29

Thanks for the report. Indeed I can also reproduce it with my own key. For signatures from expired / revoked / disabled keys it shows "No public key" because GnuPG returns the same error in that case. We can fix that by looking up the key ourself.

@sapienza Can you try it with Kleopatra please and if it fails there, too please post the "Diagnostics" from Kleopatra. (See "Blocco note" in Kleopatra for the same functionality)

I've rewritten your patch a bit so that it falls more in line with our general style of helper functions and is more generic.

I've tested it with Gpg4win-3.1.7, too and it works for me so something must be special.

Unsupported protocol still means something with your GnuPG installation is strange.
Whats surprising me most here is that Kleopatra works for you.

I would be interested to here if it worked. But for now I'm closing this as resolved as there is no obvious next step.

As this task has no obvious next step I'm closing it.

Well in general we don't support installation into UTF-16 paths for Gpg4win, our installer prevents that. This is probably why this issue never came up.

Thanks for the report and the patch. As this results in multiple message boxes (which we create and not Libreoffice) I'll assign it high priority.

I'm interested if this works as you imagine with 2.3 I'm pretty sure werner worked on a problem like that.

Yep, I'd like that, too. Sadly G-Suite Sync does not support "PGP/MIME" which is the standardized format we need to put together a message with attachments in a Mail.
So for now we only have PGP/Inline support. See: T3545

I've looked into it alot first: If I use outlooks builtin S/MIME support it also does not work for me, at least over SMTP. I see the attachments but they have unknown type and if I double click them I get errors.

This was fixed afaik in 3.1.7 please let me know if this still does not work for you.

2.3 Release plan is around this summer. There will be a public beta sooner.

For Kleopatra there is a "TODO" to better handle multiple smartcard readers. E.g. that you can have mutliple tabs in the smartcard management view.

I agree with you and GpgOL handles it that way so for me this would work. But I'm not actually implementing autocrypt, so I also added @patrick to the subscribers.
I've talked about using key-origin in Enigmail with him in Brussels and I would be interested what he thinks Enigmail might require and if gpg could be improved for that.

Hi,
if I don't misunderstand you, we already have that:

My interpretation of the key-origin is that it's basically up to the application what it does with the information. It is added information, like the TOFU history we can have. I don't necessarily think in terms of "trustworthyness".