Fixed in GnuPG 2.4.4.

For the particular issue reopened for GnuPG 2.2.41 is fixed in GnuPG 2.2.42.
Please note that we can't fix the cause itself, the hardware problem.

Fixed in 0.3.2.

Fixed in NtbTLS 0.3.2.

Fixed in 2.4.4.

Openssl since version 3 supports aes-gcm and aria-gcm in cms. CMS has a different wrapper for AEAD. openssl Pull Request. I created test files (nistp384 key, certificates, messages), perhaps it will be useful.

Are you seriously using version 2.0 which had its EOL of 6 years ago? Libgcrypt 1.5 EOF was even a year earlier. Sorry, I won't look into that.

Additionally I would find it sensible to display the keys always in the order of the keyslots.

The behavior is different between the old and the new versions. gpg-agent, the backend exits with the shell closing in the old version. But, if I start it with the new version, it stays running unless explicitly closed. I wonder if this means that we should run gpg-agent on all servers?

Also fixed in the fortgcoming 2.2.43

Hidden for Gpg4win-4.3.0-beta571, too

Possible fix for testing as patch: https://invent.kde.org/frameworks/kio/-/merge_requests/1540

Just a reminder, this is important for 384 bit keys (see T6379).

The state of the brain is:

Kleopatra behaves as intended (by me). Only subkeys meeting the following conditions are extended together with the primary key:

• skip revoked subkeys which would anyway be ignored by gpg;
• also skip subkeys without explicit expiration because they inherit the primary key's expiration;
• include all subkeys that are not yet expired or that expired around the same time as the primary key

These gpgsk files are standard private-keys-v1 files with an additional Backup-info line showing for example the keygrip.
There are no certificates in the file, thus we can either use gpg or gpgsm as driver.