Hidden for Gpg4win-4.3.0-beta571, too

In Gpg4win-4.3.0-beta571 with GnuPG 2.4.4-beta132

>echo test | gpg --sign --default-key F8D51DE0EE16E9B57009B8DE458612006D8E6F0D
gpg: Warning: not using 'F8D51DE0EE16E9B57009B8DE458612006D8E6F0D' as default key: Key expired
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: Unusable secret key
gpg: signing failed: Unusable secret key

works in Gpg4win-4.3.0-beta571

@aheinecke For Gpg4win I do not have a suitable test version yet.

Is the problem that another success message is shown after deleting the local copy?

The fix was not included in the Testbuid...

Does not work in Gpg4win-4.2.1-beta178

works in Gpg4win-4.2.1-beta178
Note to self: need to check with "to the second" expiry time, in case this only occurs with summertime

works in Gpg4win-4.2.1-beta178

It is still there in VS-Desktop-3.2.1.0 insofar as 2 dirmngrs are started. It was only fixed insofar that it is no longer more than 2.

reopened. Because of reverted commits there is again no error message when trying to write to a write protected folder, see T6917.

moved to milestone 3.2.0, as 3.2.1 does not exist as column...

Works in VS-Desktop-3.1.91.9-Beta.

Another hint: When they checked "write temporary files in the folder of the encrypted file" they got a message window from gpgex "Error returned by the GnuPG user interface: Input/output error".

This is what it looks like for VSD curently:

Note for myself: This is the behavior for key resolving in GpgOL. GpgEX has different code for this and the above examples will not work.
In GpgEX the group is not resolved into its component keys currently.

Finally officially tested with Gpg4win-4.2.0 and a Yubikey 5 NFC. Works for both OpenPGP and PIV.

Tested with Gpg4win-4.2.0 and a Yubikey 5 NFC.
CSRs are generated for both available keytypes rsa2048 and nistp256.

In T6891#180473, @aheinecke wrote:

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

I saw this recently on a imap subfolder with between 4- and 5000 mails. I have marked a few hundred new ones as read in one go. The folder does not even have mail threads in it and I've never used that function anyway.
This was on my work account @gnupg.com (the only account where I use KMail). Should we ask Werner for details of the server?

works with Gpg4win-4.2.0

As it is so complicated to check all possibilities: