Right. I think this task inherited the assignee from its parent task.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Apr 2
Mar 12 2024
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.
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:
That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.
@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 25 2024
Openssl since version 3 supports aes-gcm and aria-gcm in cms. CMS has a different wrapper for AEAD. openssl Pull Request. I created test files (nistp384 key, certificates, messages), perhaps it will be useful.
Jan 24 2024
Hidden for Gpg4win-4.3.0-beta571, too
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.
The test file is now part of our test suite and passes.
We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.
Jan 16 2024
Interesting. I need to look closer at it. I scheduled it for 2.4 but it won't be in the forthcoming 2.4.4. There are still other interesting things on the short list (e.g. timestamping support) but we may do that only in 2.6.
Jan 5 2024
Hope so too. If there was a docker image or something I would gladly test it, otherwise I'll report back as soon as a release is out
We can't test this but assume that the fix for T6752 is sufficient here.
Jan 4 2024
Note that we now have also an option instead of the workaround from 2015
Dec 16 2023
We were hoping before christmas. But it is unlikely due to some other stuff we had to do. Early Jan. Definitely a priority for us right now to get it out.
Dec 15 2023
@werner Any news on when will 2.4.4 will land? I cannot figure out how to build the project from source, and I couldn't adapt the Fedora packaging to build it either. I would like to have a way to finally sign my git commits.
Dec 12 2023
Checking if the key is not otherwise used is unrelated and should be a diifferent Task since this also relates to OpenPGP. For me this Task is about creating a similar API for gpgsm (--delete-secret-key) that we have for OpenPGP.
Dec 11 2023
As it is so complicated to check all possibilities:
Searching by keygrip is actually fast with keyboxd.
Actually prio is rather low or even Wontfix. Since it has been this way forever and no one really complained. I think deleting secret keys esp. for S/MIME where you can't just create a testing key but need to have it signed by a CA is not really there.
I know I discussed this with werner several times and never really understood it because it makes for an inconsistent user interface / user experience. You delete an OpenPGP Secret key and then the keyfile is gone, you delete an S/MIME secret key and then the keyfile still exists. But it has been so forever T960
Maybe kleopatra should for the very rare cases where a key is used by multiple certificates do a search for the keygrip and warn if this also deletes the secret portion of another secret key? But that would then be also true for OpenPGP.
Dec 4 2023
Fixed. This regression was introduced with the fix for T5697: Kleopatra: Crashes or hangs on circular certificate chains.
Which certificate list? The list in the main view? Or the certificate list of a smart card?
Nov 28 2023
Nov 27 2023
Thank you very much on behalf of our S/MIME users. This also makes it easier for us in the frontend to show a consistent UI.
Tested on Windows with Kleopatra and 2.2 and with gpgme and 2.4 on Unix.
Okay, I known do the same what we do for a single root certificate, that is mark it as "not trusted" ('n').
Nov 25 2023
My very simple patch for this would be:
Nov 21 2023
is now hidden in VS-Desktop-3.1.90.287-Beta
Nov 20 2023
Nov 17 2023
Nov 15 2023
Nov 14 2023
Sorry @ebo tested this on Windows with 2.2. I myself should have tested it since the test is trivial and only took me about 30 seconds to type. Similar to T6701 this should have never reached the QA stage. I am including myself now that we have someone for QA that I test my own changes less. We need to talk / think about that in our whole team. We developers should test more before sending an issue into QA.
Nov 13 2023
Yes it is in the gnupg beta235 which is part of vsd-beta 277
Need to check if this is in the beta or not before moving it to the QA board.
Nov 10 2023
Nov 9 2023
Thanks, I will test this and if it works as expected I would also put it in 2.2. since it was pointed out to me from a customer at our approval institution and I think they will be glad if they see that this is gone in the next release and I don't see any regression risk associated with that change.
Pushed the change to master/2.4.
Nov 8 2023
I guess that it's a case of specifying static passphrase. If so, here is the patch:
diff --git a/g10/call-agent.c b/g10/call-agent.c index cb7053396..c44c1cddb 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -161,6 +161,7 @@ default_inq_cb (void *opaque, const char *line) || has_leading_keyword (line, "NEW_PASSPHRASE")) && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK) { + assuan_begin_confidential (parm->ctx); if (have_static_passphrase ()) { s = get_static_passphrase (); @@ -187,6 +188,7 @@ default_inq_cb (void *opaque, const char *line) err = assuan_send_data (parm->ctx, pw, strlen (pw)); xfree (pw); } + assuan_end_confidential (parm->ctx); } else if ((s = has_leading_keyword (line, "CONFIRM")) && opt.pinentry_mode == PINENTRY_MODE_LOOPBACK diff --git a/sm/call-agent.c b/sm/call-agent.c index 883c0c644..7f7205f26 100644 --- a/sm/call-agent.c +++ b/sm/call-agent.c @@ -222,7 +222,9 @@ default_inq_cb (void *opaque, const char *line) && have_static_passphrase ()) { const char *s = get_static_passphrase (); + assuan_begin_confidential (parm->ctx); err = assuan_send_data (parm->ctx, s, strlen (s)); + assuan_end_confidential (parm->ctx); } else log_error ("ignoring gpg-agent inquiry '%s'\n", line);
(I also found similar case for gpg as well as gpgsm.)
Oct 30 2023
works, the secret part is now imported, too, tested with VS-Desktop-3.1.90.258-Beta
works: my brainpool X509 testcertificate is shown as compliant
Oct 25 2023
Would love to test this, but I can't seem to compile this project, getting stuck at The system does not provide a working iconv function. Is there a Fedora based dockerfile or equivalent where I could build it? Here is the reference Fedora source. I have tried to hack it and build from a gitarchive, but I am still encountering issues No rule to make target 'audit-events.h', needed by 'all'. Stop.
Oct 24 2023
According to our rules an initial set of tags should never be a milestone but be in the Backlog or, if work already started,in the WiP column. Because it is anyway invalid, I removed the tags.
T6536 has been fixed. With today's commits the Brainpool curves are now also flagged as compliant in gpgsm.
Now fixed in 2.2 and 2.4 (commits rG08f0b9ea2e955209d467f1ff624bf7abd10ae7ac and rG7661d2fbc6eb533016df63a86ec3e35bf00cfb1f). See also T6752
Oct 20 2023
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.
Oct 17 2023
With VS-Desktop-3.1.90.246-Beta I can not import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey (ECC brainpool).
I do not see any error message.