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

This pretty much highlights a general problem of groups: If the distribution groups for the email client are managed independently from the certificate groups then there will inevitably be discrepancies. The obvious solution is the usage of groups managed by a central service for email addresses and certificates. (Or an encrypted mailing list service.)

Applied your patch (from gitlab) to both (master and 1.10).

Applied to both (1.10 and master).

You are right, there is no way to use DRBG with SHA384 by libgcrypt.

Applied to both (1.10 and master).

Applied to both (of 1.10 and master).