The problem seems to be that we don't return a status code with the
actual error via the --command-fd interface:

@gniibe Perfect, I got the update during the night actually. Thanks a lot for your work 🙏 .

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Did you restart Kleopatra after enabling the high contrast mode? I have implemented that Kleopatra doesn't change/set any background or foreground colors if high contrast mode is detected. Maybe the detection (in SystemInfo::isHighContrastModeActive) doesn't work.

All issues were addressed.

Hi lovely people,

I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?

Most things look good to me, it was automatically enabled when I switched Windows to high contrast mode. The only thing I noticed is that the fields where we explicitly set the background may not look to readable. Especially the Sign&Encrypt buttons because there we don't set the text color.

Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.

The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.

I am reopening this as the current behavior is strange in my opinion and should be changed before a release.
Currently the refreshopenpgpkeysjob does not refresh the OpenPGP Key by fingerprint but instead imports all keys with a similar e-mail address. This does not work for keys with no email. Also in case of public keyservers it can pull in keys that not belong to the user or are expired and so on.

@gniibe thanks for help.

Fixed in 2.2 and master. Did a couple of manual tests using 2.2 on Linux. gpgsplit comes handy to add a couple more tag-3 packets (same algos or one patched to camellia for the negative test)

This also points out that the cipher algos and modes of the symmetric encrypted session key packets where never checked for compliance. We only checked the compliance of the bulk encryption cipher algo.

This was added in b03fab09e188f7bb10237d4f20455e4026737e4e

Oh, there appears to be a reason for that. In line 699 of mainproc.c:

/* Symmetric encryption and asymmetric encryption voids compliance.  */
   && (c->symkeys != !!c->pkenc_list )

I have exactly this problem with yubikey here,
since i upgraded to gpg4win version 4.0.3 which contains gnupg 2.3.7 i get the same error as openpgp key not recognized.

The original issues have been addressed. Moreover, the actions are now available as buttons additionally to being available as context menu items.

@tigernero 2.3.8 is not yet released. Pretty sure gpg4win is a separate project, presumably you'll see a changelog entry here (as there is bumping to 2.3.7 in the latest 4.0.3) when it's in:
https://www.gpg4win.org/change-history.html
https://www.gpg4win.org/support.html

Agreed

The OpenPGP-related changes mentioned in T5832#161063 have been implemented.

I think this was mostly covered with T5362: Kleopatra: Add warning in compliance mode if gnupg version is not compliant and T5653: de-vs and GnuPG 2.3.3 error.