Lookups can now be started after entering a single character. Wildcards like * do not seem to be supported by OpenPGP key servers.

Thanks for the analysis!

Hello, i did some debugging with my local sks keyserver version 1.1.6+ on Debian:

I have also improved the workflow when verifying detached signatures without corresponding signed file from Kleopatras UI in "non-automatic" mode, i.e. if "Automatically start operation based on input detection for decrypt/verify." is disabled in the settings.

Fixed. This was actually a regression introduced many years ago.

Actually, I get a very similar error message on Linux, if I run kleopatra --verify <detached signature file>

An error occurred: Kleopatra: Could not open file ".../detached-sig-with-different-name/verify-me-signatur.txt" for reading: No such file or directory (218136657)

Ready for testing.

Fixed in 2.2.36.

Fixed in 2.2.36.

Thank you for your report. That's my badness (forgetting to implement in pk_verify_md function).

It's true for key generation, but not for all cases.

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org?

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org? (I haven't found AppImages to download on gnupg.org.)

Hello ...

I may report, that I've tested this behaviour with "kleopatra" with serveral keyservers.

Please note that due to vacation issues the signatures use the gnupg.com Brainpool based release key and some Linux distributions come with Brainpool removed from GnuPG.

For the record, the valgrind trace for the crash is:

I guess the problem is that the fix for T5741: dirmngr does not ask keyservers for fingerprints wasn't backported to 2.2.

But this is with the default keyserver keys.ubuntu.com it shows the fingerprint if I do a search --with-colons with 2.3 and the same keyserver (addressed via IP) on the same machine returns results on Windows and says No Fingerprints in the app image. This is what I found so strange here.

Many keyservers return a maximum number of results. I have seen results being capped at 100 keys.

pinentry does the following to check if it's running in a GUI session:

// check a few environment variables that are usually set on X11 or Wayland sessions
const bool hasWaylandDisplay = qEnvironmentVariableIsSet("WAYLAND_DISPLAY");
const bool isWaylandSessionType = qgetenv("XDG_SESSION_TYPE") == "wayland";
const bool hasX11Display = pinentry_have_display(argc, argv);
const bool isX11SessionType = qgetenv("XDG_SESSION_TYPE") == "x11";
const bool isGUISession = hasWaylandDisplay || isWaylandSessionType || hasX11Display || isX11SessionType;

i.e. it checks if a few environment variables are set or have a specific value.

Looks like a duplicate of T5725: Kleopatra: Certificate lookup shows only one result even if there are 100s matches. Solution: Use a key server that returns fingerprints.

Hier scheint es sich um ein individuelles Problem zu handeln. Ich bin irritiert das die Fehlermeldungen von "gpgsm" also unserem S/MIME tool. Tritt der Fehler auch so auf wenn in den Einstellungen von GpgOL der S/MIME Support deaktiviert ist?

I agree, we should look for additional names when verifying checksums.

I can reproduce the problem. Under Windows it works, with my development setup with GnuPG 2.3 it works, but in the appimage I get the error that all keys were skipped.

So maybe add a hint with the workaround to the error message, maybe even link to some *.reg files that would fix it, with a big fat warning to respect and look out for your E-Mail providers attachement size limits. The 20MB thing from Outlook is nothing more than an educated guess by Microsoft in the first place, some providers have smaller limits and the user has to identifiy the server error code themselves anyways.

The problem is that we keep the original, encrypted, signed structure of the mail as a hidden attachment. When we then add the attachments we extracted from the original mail as "real" attachments in the Outlook data structures we basically double in size and hit an error in Outlook. It does not always have to be double, e.g. if the attachment was compressed in the encrypted data it can be much larger then the original mail. So this happens mostly with data that is not easy to compress.

Thanks. Applied. Also, fixed about a warning for ChaCha20.

I admit that documentation for users should be updated and/or semantics of options could be improved.