Thanks for the report.

I'm working on better support for Smartcards and esp. multiple smartcards in Kleopatra. IMO it should not be required for a user to explicitly write a reader port in the config.

I'm giving this an initial priority of "Normal" so that it's out of the triage list.

If you have -g / -Og could you please provide a backtrace?

Hi,
sorry we cannot help you with that. The keyservers might have unreliable results. It would only be a bug in Kleopatra if GnuPG on the Command line would find a key and kleopatra wont. Does it find other keys?
So you can try on the command line with "gpg --search foo@bar.baz" this would also show you on which server the keys are searched.

Thanks for the report I tried to reproduce this but cannot reproduce the mentioned behavior. So for now Low priority until we have found a way to reproduce it. I have tried unencrypted and encrypted mails and it works as expected.

I have opened T4939 to add the keylist mode with keygrip.

To end the failures I have modified the test, that needed to be done anyway since different versions of GnuPG behave differently.

Your guess is correct, but as this hole "Wizard" thing uses Qt Regular expressions its not super quick fix without having to introduce new strings etc.
So I just reduced the length. The new key generation in Kleopatra is pending a rewrite anyway. Requires way too many clicks ATM.

Thanks for looking into this!

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.

Sample how GpgOL handles this: https://dev.gnupg.org/source/gpgol/browse/master/src/keycache.cpp;6f5f48c3d60e0af52f1a9f0e51f60ee653eeeb31$269

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

Done in master

This is now implemented

apologies but I do not understand this issue. Please clarify. Were you having issues with "log" files or "lock" files?
What was your issue?

Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.

To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )

I don't have a Free BSD. Can you please try out the patch that I have appended to https://bugs.kde.org/show_bug.cgi?id=415168 ?

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

Thanks for the report. Indeed I closed this as a duplicated. Thanks @dkg for pointing out the patches.

For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.

The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.

In T4513#132777, @Valodim wrote:

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

Thanks for engaging constructively.

@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.

Hi,
Thanks for the report but, but we are not developers of KMymoney, I can only offer to help the developers if they have questions but please rather report a bug at bugs.kde.org regarding that so that they can figure out what might be wrong.

I renamed the ticket so that others don't think we generally don't support Office2019 because I use it myself and it works for me.

Hi, I am not sure what you mean by "The Icon does not recognize the created certificate".
Does it show you that the mail is unsigned when you view a signed mail?
What does the tooltip of the icon say?

Thank you for the detailed report.

I remember that I tested inline content-disposition handling in Outlook without GpgOL and try to do the same handling as Outlook would handle them. But then at the very least It should be shown as an attachment and not hidden.