Is in 2.4.4 and will go into 2.2.43

Apologies! That was from the CentOS Server. Below are the current details
for the recently upgraded Alma Linux servers. Will upgrading to the most
recent version fix the issue?

As in my test case Kleopatra didn't check the box for "with subkeys" when the extension wouldn't work I propose as minimal solution:

• disable the checkbox if no key would be extended anyway + info why the box is not checkable (via tooltip)

Oh, well it does happen only with --status-fd=2 because of a c+p error by me. For status-fd > 2, as used by GPGME, there is no problem, because this is handled by an exception list.

You are (of course) right, gpg -k shows the keys in that order. Which is different from the order shown in the smartcard management view and what gpg-card shows. So lets drop that point for now and maybe discuss this some time in the future.

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