Could you write a quick patch file for that? (I don't have a working source build, I am using the Fedora spec file + patches)

The old debug output is in genral okay but what I would do is to add a couple of log_debug calls like

Does the run-verify example (in gpgme/tests) hang when verifying a corrupted file?

@werner I managed to recover the old .p12 that has the error. And this is still replicable. Is there a debug flag that would be useful or can we setup some private live-debugging for this?

Closing this outdated ticket

I'm attaching a proposed patch. We should decide whether this is the correct encoding to use for SHAKE128 and SHAKE256, because they are variable-length output functions and there is an alternative encoding that has a field for the length, which is likely better suited, but currently not really well supported by libgcrypt (since this would be dynamic content in the ASN.1 encoding).

I would have expected an error message right after

I agree. Any automatic use of the embedded filename will be potentially problematic security-wise. The only safe use is probably as a value in an interactive dialog, and even then, only if the user doesn't accept a dangerous value.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.

Unfortunately I have deleted the .p12 with the CA chain, and I don't know how I've generated it. It also contained my production certificates so, kinda sensitive to upload here.

Okay, I push the change for the extended salt size. Regarding the import of CA certificates, I have not seen any problems. In fact it is pretty common. Did you test with with 2.4.4. A test file would be helpful.

Ok, I have tried again the series of workarounds that I initially posted on the main description, and I managed to fix it by striping the CA certificates. So the current issues here are:

• Allocated salt is too small. https://dev.gnupg.org/T6757#182217 fixes for now
• Cannot import a .p12 that includes CA certificates as well

Fixed by changing server as noted above.

Thanks for all the help @gniibe.

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: