Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.

I did some reworking and the outcome of the READKEY command is now (agent log):

I checked it: There was an empty bin/gpgconf.ctl, and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

For non-vsde-enabled installations the green check symbol is okay because in the given context (encryption) it indicates that the key can be used.

Seeing that there are "groups" in Kleopatra, I read the docs, and they suggested that the groups are for addressing multiple recipients.

Settings -> Configure Groups.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

Pushed to this site. Thanks for noting.

I think this is still missing a tag in git (I don't see it in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=tags)

I've run into a variant of this, too. If I generate they key just using (genkey (ecc (curve "Ed25519"))), it is recognized as an encryption key. One needs to use (genkey (ecc (curve "Ed25519")(flags eddsa))).

works

@gniibe I have submitted D565 to change the error message on curses initialization to "Required environment variable not set"

Its not used, so it can't harm.

Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.

It effects Yubikeys and ZeitControl cards (version 3.4)

Many thanks for the information. I suspected it also, but wanted your assessment.

We got a user report that the issue did not occur before their update from 3.1.25 to 3.1.26

Well, virus checkers aren't perfect. If 1 out of 65 checkers reports a finding, then the probability that this finding is a false positive is very high. You would better report this to the vendor of NANO-Antivirus, so that they can fix the false positive warning.

Thank you.
Applied to both (master and 1.10).