Thank you all for your quick feedback.

I've confirmed the patch fixes the issue. I'm planning to backport it to a revision of 2.3.7 in the Homebrew package manager.

I'm the user OJFord referred to above (my access to this bugtracker just got approved this morning). I tested the rGf34b9147eb30 change on my Mac, and it does indeed resolve the issue there.

I haven't had a chance to try it myself yet, but another user writes in the Reddit thread linked above:

It will be in 1.10.2.

It will be in 1.10.2.

Applied to 1.10.

Thank you for your confirmation.

Hi there!
I can confirm this regression on my yubikey 5 Nano with 2.2.36 (2.2.35 works) - on archlinux. Yubikey firmware 5.4.3, ed25519 keys too. Some more info:

I'm going to backport this to 2.2, as it found useful.

Yes, I am using ECC keys:

Key attributes ...: ed25519 cv25519 ed25519

It's in 2.3.7.

Fixed in 2.3.7.

And 2.3.7.

Fixed in 2.2.36.

Perhaps, rG53eddf9b9ea0: scd: Fail when no good algorithm attribute. should be backported to 2.2.

Fixed in 2.3.7.

Thank you. I learned that there is new firmware, version 5.4 series.

@gniibe Thanks - mine's 5.43. (And the working 4Nano is 4.34.)

In gnupg/common/ttyio.c, the function w32_write_console does:

• Call WriteConsoleW, and when it fails, it calls
• WriteConsoleA

Please let us know, your firmware version number (in bcdDevice) by lsusb.

I suggest to submit a patch with the changes you'd like to see. Please read
https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING
for information how to contribute to gnupg.

I can confirm this issue with a 5C Nano returning the error, but a 4C working successfully. Downgrading to 2.2.35 does resolve the issue.

I wouldn't call that particular thing technical specification, because it really has potentially a strong user visible impact (i.e. expected passphrase works or not - both cases, whether any other newline characters are included or not, as well as whether it would simply ignore any characters beyond a maximum length).

I'm not sure whether the manual page should be blown up to a full technical specification.

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?

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.