FWIW, I received that mail but I hope that this bug is at least fixed with today's fix for T7213. Thus not re-opening.

Can't find a mail - closing the ticket. Feel free to reopen or send me a mail to werner dot koch at gnupg.org but replace the org by com.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

I've sent you an email about it. It might have html elements due to markdown-here.

Sorry, for not following up earlier. Can you please do me a favor and run the last tests again, this time adding -v and --debug 1 to the invocation? Feel free to forward the output to my private address is that is easier (wk at gnupg.org).

See also: https://gnupg.org/blog/20240125-smartcard-backup-key.html

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

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

@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?

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.

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

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:

@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

Is in 2.4.4 and will go into 2.2.43

Also fixed in the fortgcoming 2.2.43

Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24

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.

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

Tested this some time ago.

That is a feature. Consider the case that ~/.gnupg is on network file system and thus possible in use on several boxes. Thus before we remove stale lock files we do not only compare the PID but also the hostname. Granted, this is rare but we have had such cases in the past with locks.

That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:

So dirmngr already has that option.