Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).

I test on ppc64 machine (POWER9, big endian).

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.

You can easily do this with gpg-connect-agent

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 implemented the new format in 2.2 but we need to discuss how to handle this in gpgconf.

Fixed. Kleopatra no longer tries to parse the keyserver option and treats it as simple text (instead of as URL).

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.

@werner @ikloecker Any more thoughts / updates on this?

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.

You should anyway use --quick-gen-key.

So what do you think is the threat here?

Setting a curve type (which shouldn't be necessary) like "Curve-Type: ed25519" doesn't help either. While this makes the check in gpg pass, the gpg-agent process re-checks the parameter set and rejects it with the same error message.

My concern is not a disloyal administrator, so I disagree with that priority.

CVE-2021-33560

Thank you. I checked what was missing and all looks good. But do not understand why the last gpgsplit xfree was not applied. We are leaving a block where this variable is dynamically allocated so even without error we need to free it.

thanks!

The error codes we use are a combination of code and location.

Could make --multifile work on windows 10, documenting the workaround here.

I give this a low priority because all those infos are easily retrievable from config files.

Thank you for your report.

Let me rephrase from a viewpoint of mine (an implementer).

The first two patch sets are now applied with the exception of
the gpgsplit fix; I did not applied that patch to add a free() in case of write errors.