Has been release quite some time ago (2.3.8 and earlier)

Will be released with 2.3.9

I just fixed a bug related to the DP. That might be related. See rG0c8299e2b56ef2e1

I see what I can do

Real Passphrase is "test"

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.

--import [files]
       Import  the certificates from the PEM or binary encoded files as well as from signed-only messages.
       This command may also be used to import a secret key from a PKCS#12 file.

This looks like a different but not too uncommon problem. For T6169 we need to get a PKCS#12 file to be able to replicate the problems - obviously that PKCS#12 should hold only test keys/certs.

This issue happens even if a user enters the correct password for the private certificate.

I think this is a duplicate of T4779 I am merging them because if it is not a duplicate T4779 is still the right issue because we need better error messages for PKCS #12 import

To identify/locate the issue, you can try command line:

The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

I am adding the gpgcom tag as this causes support problems because we do not really know if it is an invalid object with the correct passphrase or if just the passphrase is incorrect.

nice, that's great news! I'll have to try it out when I get a chance.

Funnily I created a file dirmngr/rfc3161.c last Sunday. I can't tell how long it will take but I am definitely interested in using GnuPG to create qualified signatures. Timestamp support is at least good for testing.

@werner There's renewed interest with protecting supply chains. GnuPG is used by a lot of open source systems. Is it possible to bump the priority on this?

Fixed in master and 2.2 branch.

I located the cause; Current implementation cannot parse the data like:

2611:d=5  hl=4 l=1632 cons:      cont [ 0 ]        
2615:d=6  hl=4 l= 500 prim:       OCTET STRING
3119:d=6  hl=4 l=1124 prim:       OCTET STRING

Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.

Needs to be tested with the current 2.2 version and a gcry_log_debugsxp should be added to the error output.

Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.113549.1.9.1 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)

fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113549.1.9.1 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.

We translate only those OIDs from RFC-2253 to have a stable set of names in the libksba interface. If you need anything else, you need to do this yourself. For example gpgsm does this in in parse_dn_part, gpa has the code in format-dn.

I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.

Attached is a proposed patch.

Attached is an even worse PKCS7 blob, that should be validatable given reliance on ca.rsa.crt, but it will be rejected by gpgsm because the PKCS#7 bundle includes ca.rsa.cross2.crt in it.

OK, i have replicated this successfully with no ed25519 involved. here's the new intermediate cert:

Which NIST test suite are you referring to? It might not cover certificate pathfinding in the face of multiple cross-signed authorities.

I do not have the time to analyse this in the context of our approved versions and to compare it to the NIST test suite. We also do not yet have support for ed25519 certificates.

Apparently only one of the secret keys is actually imported: the decryption key, but not the signing key.

The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

thanks, @werner!

Okay, okay, I had in mind that we print them because we used to put such certificates into the ephemeral certificate storage because it is not possible to check the signature. But I reliazed that this changed quite some time ago and we can view these error messages as informative only. They are now not anymore printed int quiet mode. Well, for 2.3 - not sure whether I should backport this to 2.2.