Wed, Dec 11
Oct 29 2024
Oct 4 2024
Test on a dedicated Windows box (T 460, i5-6300U@2.40GHz, harddisk):
VSD Version | gpg version | Load time |
3.1.26 | 2.2.41 | 1:59 |
3.2.4 beta-2 | 2.2.45 beta 25 | 0:46 |
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.
Oct 1 2024
works, the Root-CA of the above example is only shown once any more. Gpg4win-Beta-50
Sep 30 2024
Will be available in 2.2.45 and 2.5.2
Now we are at 4 seconds. Available in master and 2.2.
Sep 27 2024
With that patch we are down to about 6 seconds.
Aug 14 2024
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.
Aug 13 2024
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.
Aug 7 2024
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)
Aug 6 2024
Alright. Done for master; backport will come soon.
Jul 31 2024
The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).
Jul 25 2024
Jun 20 2024
Jun 6 2024
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.
May 13 2024
May 12 2024
Yes, I think we should support this. Also X448. Thanks for the report and the samples.
May 7 2024
Apr 24 2024
Apr 2 2024
Mar 12 2024
Right. I think this task inherited the assignee from its parent task.
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).
Feb 27 2024
Feb 21 2024
Way to old. Does anyone still uses CAcert?
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 2 2024
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.