I can do correct handshake with GnuTLS, if specified.

Please configure your server so that an application with GnuTLS can interoperate. It is not GnuPG specific.

After the original fail - one of the things I tried was changing nginx server to allow TLSv1.2:

It looks like a failure of GnuTLS negotiation.

$ wget --server-response --spider https://openpgpkey.sapience.com/.well-known/openpgpkey/sapience.com/hu/me5xnfhbf3w9djpmxa3keq5q8s3rcgf1?l=arch 
Spider mode enabled. Check if remote file exists.
--2024-01-29 11:35:15--  https://openpgpkey.sapience.com/.well-known/openpgpkey/sapience.com/hu/me5xnfhbf3w9djpmxa3keq5q8s3rcgf1?l=arch
Resolving openpgpkey.sapience.com (openpgpkey.sapience.com)... 72.84.236.69
Connecting to openpgpkey.sapience.com (openpgpkey.sapience.com)|72.84.236.69|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [47]: Illegal parameter
Unable to establish SSL connection.

Fixed in rC128121e74b66: build: Use @FGREP@ by configure for libgcrypt-config..

Thank you. I recently fixed for use of egrep rC656ca459e3d8: m4: Update acinclude.m4 to use $GREP., but overlooked this one.

I upgraded to gnupg 1.4.4 now, the problem is gone. Thanks for working.

Thanks @gniibe and everybody!

Regarding https://invent.kde.org/pim/kleopatra/-/merge_requests/106 I cannot login to gitlab right now. Since I have to manually migrate my fdroid apps to the new phone and my 2fa app is one of them. But I agree with everything ingo said there.

We need to test the PIN, PUK and reset code stuff in 2.2

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.