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.

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.

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.

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

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

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.

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

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.

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.

Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

115.3.1esr

Yes, there is clearly a problem with the handling of NDEF. I have a fix for that but there are other oddities in that pkcs12 object. Do you have the Firefox version you used to create this?

That has been done modulo the bug which existed for both versions, I fixed today (T6536)

Okay, I found and fixed the import problem in 2.4 and will backport this to 2.2

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

With Gpg4win-4.2.1-beta31 I can no longer import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey. Error is "Invalid object".

With VS-Desktop-3.2.0.0-beta214 and Gpg4win-4.2.1-beta31 the error is "Bad Passphrase" in this case.
I do not see a reason why this ticket is still open.
The already resolved Kleopatra Task T5713 is probably a duplicate of this one.

pkcs12 import should be backported, too

I don't see a value to do this for 2.2 and introduce a regression with that.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

Needs to be checked again with stable. No backport to 2..2, though.

Currently, Kleopatra cannot do anything about this. get_passphrase in protect-tool.c asks those questions and doesn't support a way to give the user more context (e.g. by providing the file name). Once gpg-agent allows giving context, Kleopatra can add for example the file name to the data to import.

yes, one down, two to go...

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

Same for the backport to 2.2 which uses the same test suite.

This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

Partly done for 2.4. The cram-octet-string stuff is missing, though.

This has long been fixed in 2.4. Given that Libgcrypt has support for PBKDF2 we can back port this.

Use Kleopatra which constructs the DN for you ;-).

I had a brief look at this. I don't think there's a way currently to convey "CRL Error" via a keylist result to gpgme. The --with-colons format would probably need to be extended.