It should not be removed as I believe it is required to be compliant:

Thank you for the fix. Pushed the change modifying the commit log for the ChangeLog entry.

I'm afraid that your particular configuration would cause the problem of the negotiation.

Server is nginx with the following settings

We got a bit further, not sure what debug level you want, guru I've found to be too excessive:

Can you please try this patch:

After applying patch to nPth 1.6 no semaphore leaks detected. Tested with GnuPG-2.3.3.
There has been positive feedback from production environment as well.

@werner I have just tested this, and although it fixed it for one certificate, this one in this issue still fails. Here is the new debug given

Fixed in GnuPG 2.4.4.

AFAIK, we don't have any option to control the lower-level detail of GnuTLS for dirmngr of GnuPG.

Setting a date on the command line is in UTC, displayed in Kleopatra is the corresponding local date which might therefore be one day of. This is as intended and the same for dates before or after the Y2038 cut off.
-> Works with Gpg4win-4.3.0

Thanks for taking time to look into this. You have clearly identified the issue.

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.

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

Thanks @gniibe and everybody!

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?

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.

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

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.

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

No test environment in our QA dept.

Fixed in 2.4.4. Feel free to re-open if you still see problems.

No regression, assuming things work.

Fixed in 2.4.4 and 2.2.43 - see above for affected versions.

Closing because we believe things are fixed and our test suite confirms that. Feel free to -reopen in case your own file does not import with 2.4.4.

The test file is now part of our test suite and passes.

We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.

I did a couple of test on the command line which should be sufficient.

We need to fix 2.2.42 too. This because we backported the responsible patch.

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

In T6481#181779, @gniibe wrote:

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

I don't see the patch is applied. Please wait for GnuPG release 2.4.4.

Indeed, openSUSE has applied the patch: https://build.opensuse.org/package/show/openSUSE%3AFactory/gpg2

Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg
FreeBSD: https://cgit.freebsd.org/ports/tree/security/gnupg

Works as expected on openSUSE Tumbleweed with gpg2-2.4.3-4.2.x86_64:

$ gpg2 --version
gpg (GnuPG) 2.4.3
libgcrypt 1.10.3
[...]

In T6481#181724, @gniibe wrote:

i still observe the same behavior:

What do you mean? I can't replicate the behavior described by you, using the GnuPG from the repo, or the one of Debian 2.4.3-2.

i still observe the same behavior:

Thank you for the report.

In T6481#171399, @gniibe wrote:

• It is also possible for GnuPG to keep the behavior of 2.4.0, so that it doesn't confuse EasyPG.
  • This is a possible solution #2: change in master: rG2f872fa68c65: gpg: Report BEGIN_* status before examining the input.
  • But... it is difficult for implementation of GnuPG to guarantee this kind of behavior.

For a while, distributions can apply rG2f872fa68c65 for 2.4 series.

Why the limitation to a single OpenPGP keyserver?

Because otherwise the UI will get confusing if you get the same key
e.g. from multiple keyservers And it is AFAIK a limitation of GnuPG.
We could use a keyserver with a DNS entry again which randomly selects
a keyserver? To avoid always using the same one.

Actually, when having multiple keyservers, the following would work:

My suggestion would be the following:

I renamed the task accoringly.

Oh These are good points

This is not the first time I saw that users are confused by this. My wish would be to change the label of the Group at least to "S/MIME (X509) Directory Services"

Is the lack of display of entries in the listbox proper functionality?

Under "X.509 Directory Services" you can add "key servers" for X.509 certificates (aka CMS certificates, vulgo S/MIME certificates). For OpenPGP only a single OpenPGP server can be entered. The suggestion is the Ubuntu key server because it is/was one of very few reliable key servers.

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

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.

Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:

Tested with 2.4.4 beta and the problem shows only up with the parameter file but not when using --expert-full-gen-key or --quick-gen-key. The problem seems to be that the v5 flag is not enforced when using the parameter file. Thus the key is created as v4 key despite that we want to use v5 for the new x448 keys. It is not a severe bug becuase the key will work anyway using software supporting X448. Will of course be fixed for 2.4.4.

Alright.