These actions/commands or, more precisely, the documents those commands show, are only available in the commercial GnuPG VS Desktop release.

Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

@Jakuje, you are right. This is a plain error and we should do a new release to avoid false errors.

Thank you, applied.

You have to restart once. Then it goes away. We can't do much about this since we load the icons etc. at startup and don't have dynamic color changing. It might be better with the next Version which will update our UI Framework but no promises. I leave it open for now so that is a known issue.

Ikloeker is our resident accessibility expert and Kleopatra has a certificate for accessible software so I agree that we should not change it. Or is there a specific issue / condition for you that makes this extra hard to read?

For accessibility the contrast between text and background must be high. Therefore, I don't think we should change the color. In any case, you get what you asked for: A dark (green) background color.

Applied the change. I write the ChangeLog entry by commit message.

We provide the examples for a reason. Actually, two reasons: To test our changes ourselves. And to provide working examples for others. If your code doesn't work then you'll have to figure out where the example and your code differ. If the example doesn't work then we'll have a look.

@Karam, please test as suggested by @ikloecker.

@werner I 'm not passing nullptr to gpgme_data_release.
@ikloecker Honestly I didn't test it.
Is there anything wrong with code ? have anyone encountered such behavior ?
I was trying adding a timeout as a workaround for gpgme_op_verify to avoid hanging but it depends on the file size and how much it will take to verify it signature...

Check https://community.kde.org/Get_Involved/translation for information how to contact the translators and/or become active in translation.

The additional debug info are:

gpgsm: DBG: p12_parse:1998: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2006: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2021: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2054: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2061: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2069: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: DBG: p12_parse:2081: err=0 prk=0x0000000000000000,0x0000000000000000
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 4
gpgsm:              unchanged: 4

Is this issue resolved?

Oh well, it does not use the c++ binding .

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.