Yes. This is not a backend issue. Kleopatra can determine if it has connection to the keyserver but the issue is about that Kleopatra should determine that and indicate that.

A popular way is to export the subkey, delete the existing key pair, and then import the subkey back, so that the actual value of the master key will not appear in the key pair to protect the master key(The value of the master key will be backed up and stored in another safe place).
At this time, gpg -K will display the following for this key pair:

By " without a master key" do you mean a keypair where the private key for the primary key is missing?

Thanks. I push the fix of yours.

Just search for something.

Yeah, but cbiedl's issue is about something like that in Kleopatra for "users".

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.