It looks like having it set will stop fallback from working entirely? Would you say that this cannot be fixed if WAYLAND_DISPLAY is set like I do above?

Thanks for the analysis!

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

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.

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.

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

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

@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.

Please find the requested log attached.
I don't know, where to look for such a file (candidate).

@gniibe Sorry for bothering but I couldnt find any answers to this online, is there any ETA for the v5 specification being released?

In T6050#159616, @gniibe wrote:

Thank you for your report.

V5 key (which is used by Ed448) is not implemented yet. See the function convert_from_openpgp_main in gnupg/agent/cvt-openpgp.c, where it parses the version of the key; Only version 3 and version 4 are implemented.

Please note that the implementation is buggy and not for use, because the OpenPGP v5 spec has been changed since then.

Thank you for your report.

I think it's worth noting that this is not restricted to encrypted e-mails but signed-only e-mails also.

Thanks for the log and the analysis so far. In the log it is visible that the problem is that gpgol cannot create a temporary file to store the mails contents. Due to this it fails later as it has no data to encrypt. The storage as a temporary file was added in 3.1.16 to allow more embedded outlook objects since we now ask Outlook to first serialize the file. I wonder why this only occurs to very few people. Obviously it works for most people, including me.

Thank's Diedrichs for this hint.
Here it works again using Gpg4win V.3.1.15.

I've tried a few things now. Reinstalled Office, reinstalled GPG4win, reset Windows 11 with recovery when still worked. Nothing helped.

I've tried a few things now. Reinstalled Office, reinstalled GPG4win, reset Windows 11 with recovery when still worked. Nothing helped.

oh no

No, unfortunatelly problem is still existing.

Hat sich das Problem gelöst? Bei mir tritt das seit gestern auf auf. Ich kann nichts mehr signieren oder verschlüsseln. andere Plugins habe ich deaktiviert, es beliebt trotzdem.

This problem does not seem to exist in GnuPG 2.3.6.

My intention to refer rG7b1db7192 was to specify the HEAD of STABLE-BRANCH-2-2, meaning "the head of STABLE-BRANCH-2-2 today". The commit itself has no meaning.

I fixed the title, because it is not a Windows only issue.

The mentioned "g10: Fix garbled status messages in NOTATION_DATA" has nothing to do with the problem. So it can'r be the actual cause. Anway, I hope to get a 2.2.36 out this week.

I can replicate the error by 2.2.35, but I cannot replicate it with rG7b1db7192.
I tested:

• GNU/Linux
  • i686
  • x86_64
• Windows
  • i686

The likely cause is that the secret key is not protected. Problem seems to be in gpg-agent.

Looking again at your report, I don't think it is an IPC problem (bad magic cooky was my assumption). I can replicate this with the current 2.2 but not with 2.3. Both un Unix.

In T6031#159248, @werner wrote:

{please add comments instead of adding the description - a changed description makes it hard to understand follow up comments. I will change the title, though for clarity.]

Please don't play ping pong now,

Please report such bugs to RedHat - they use a modified Libgcrypt and thus it's there bug.

The length limit of the signature sub packets are not reasy to pre-compute. Better to have a fatal error than a corrupt message. I am not sure whether we want to change this to a regualar error message - at that point we anyway need to stop.

I will try, but it will likely be a while. In any case I believe you will need a Red Hat-family distro to trigger the bug; it happens when gpg trys to encrypt with a key that uses a public key algorithm libgcrypt does not support.

Please provide a test case.

Reopening as gpg’s handling of the situation is very much suboptimal.

Applied to 1.10 branch.

didn't seem to work with 1.9.x

Closing as I believe this is a downstream bug.

Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.

Here is a test signature with long notation data. During verification gpg faults when emitting the NOTATION_DATA lines.

Thank you. Applied.