OK, so after debugging the issue and finally digging into the code I realized that I don't see the fix I did the first time....it turned out I committed the fix to release/23.04 branch but forgot to merge it into master and as such the change did not make it to 23.08 - which is probably why it seemingly "came back" after you upgraded. I've cherry-picked the fix to release/23.08 branch and merged it to master.

works

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

works, VS-Desktop-3.2.0.0-beta214

This is NOT the bug reporting form. You will find the form at https://dev.gnupg.org/maniphest/task/edit/form/5/

In T5903#176176, @ikloecker wrote:

Please submit a separate feature request for this.

In T5903#176175, @uwi wrote:

I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").

I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").

Edit: The text below was wrong. The error given below only occurs when the combined path+filenmae is to long on windows.
An emoticon in a file below the folder to be encrypted does not hinder encryption via GpgEX.

It's been a few years since this task has been active.

Here's another data point.

works, tested with VS-Desktop-3.2.0.0-beta214.
For the remaining issue with a certain date range see T6736

Lot's of things changed in the meantime.

HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.

Lot's of changes since 2.4.

The choice in the calendar "widget" changed to in 1/2/3 years in all cases. Those options work but the last choice "no date" has no effect.

Eva and me tested this using our 2.2.42 release candidate on Linux and
on Windows and were not able to replicate your problem.

Works, setting "compatibility-flags vsd-allow-ocb" in the gpg.conf causes new keys to be generated with the AEAD feature flag OCB. And encryption to that key then uses OCB mode as long as the compatibility-flags is set.

Eva can you please try to reproduce this? I can't really imagine that this is true since we have soooo many users with yubikeys and do a lot of internal testing on them. To be fair please try with your standard devuan GnuPG and not just with an up to date version.

Actually, a GUI to maintain the keys in an LDAP would be helpful for many sites.

This works insofar that it is now possible to set "none" (via the registry in VSD):

Yes I can see that gpgtar correcly lists the directory with procmon, accesses the files but fails to create the output file indeed.

Instead of all the debug options, please use

From my practical expexperience, @ebo's suggestion will work best for me. The other thing I have seen is to not use -signed but to append the initials of the signers.

In 2.2, KEYINFO output doesn't support A-flag for the information if card is online or not.
We need to clean up this discrepancy.

I pushed rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. to fix this issue.