Mar 6 2024
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).
Mar 4 2024
Feb 7 2024
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
Feb 6 2024
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?
Feb 5 2024
I would have expected an error message right after
Feb 4 2024
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.
Feb 2 2024
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
Jan 30 2024
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
Jan 29 2024
Jan 26 2024
Is in 2.4.4 and will go into 2.2.43
Jan 25 2024
Also fixed in the fortgcoming 2.2.43
Jan 24 2024
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.