Test on a dedicated Windows box (T 460, i5-6300U@2.40GHz, harddisk):

Overall effect of these changes tested on a small Windows VM is only 47 -> 26 seconds. Did also tests with --kbx-buffer-size but that does not make it better than the default, either.

works, the Root-CA of the above example is only shown once any more. Gpg4win-Beta-50

Will be available in 2.2.45 and 2.5.2

Now we are at 4 seconds. Available in master and 2.2.

With that patch we are down to about 6 seconds.

Did a quick manual test import and encryption/decryption with VS-Desktop-3.2.93.1-Beta with the relevant test-X509 certificate.
Works as expected.

I made a ticket on bugzilla with ready-made tests for S/MIME, but on close inspection a different structure appears for S/MIME and another for qualified signature (openssl could not verify token extracted from CAdES-BASELINE-T signature). However, these tests can be very useful.

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.

This patch has a new fix for T5793 which is now only used where needed.

I don't think that we can do much manual testing here because we have all test cases anyway in the regression test suite and our local non-public regression tests (which has the p12 files we are not allowed to publish)

Alright. Done for master; backport will come soon.

The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).

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.

Yes, I think we should support this. Also X448. Thanks for the report and the samples.

Right. I think this task inherited the assignee from its parent task.

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

Way to old. Does anyone still uses CAcert?

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

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