Fixed for gpg < 2.3. To make the fix also work for gpg 2.3, T5462: gpgconf: Make gpg/keyserver option available again needs to be fixed.

Thank you, indeed it was my fault. After -enable-O-flag-munging it compiled (btw before that it spitted the same error in jitterentropy as the one referenced in the apple case, so maybe it's that?)

Ah, I realized that the build for sqlite3 in Speedo has a patch using -static-libgcc.

Yes, --x509server does better convey the semantics of this option.

We use libgcc_s_sjlj-1.dll only for for gpg4win's C++ code which is gpgme's c++ binding and the Qt stuff.

I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.

So, has this issue been solved?

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

Thanks for your report.

Now, it is still time to change the name of the new option "--ldapserver". "--x509server" maybe?

Take care: It is not clear whether you may use a [C} subkey for certification. GnuPG currently accepts this but the RFC can also be read as primary keys needs to to do the certification.

In T5404#146459, @werner wrote:

I implemented the new format in 2.2 but we need to discuss how to handle this in gpgconf.

For signing (aka certifying) another key you need a (sub)key with the "certify" capability. Your signing subkey can only be used for signing data but not for certifying keys. This isn't specific to gpgme. See https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21.

Yes, you need the secret part of the primary key. gpgme has this info but it is easy to miss. Even our gpgme/tests/run-keylist.c debug tool did not show it directly. I modified it to make this more clear, see the latest gpgme commit. Here is an example for my key:

$ ./run-keylist --verbose --with-secret  63113AE866587D0A
keyid   : 63113AE866587D0A
caps    : esc
flags   : secret
upd     : 0 (0)
fpr    0: AEA84EDCF01AD86C4701C85C63113AE866587D0A
grip   0: CE5C1F1B8C96F1A078A2D1932EEE738A854ED976
curve  0: ed25519
caps   0: sc
flags  0:
fpr    1: E05BA20ED4F17768613B03C53CD7B3A055039224
grip   1: 7A1E3130C9CBDBF203A0AD8E186D9C511D5019FF
curve  1: cv25519
caps   1: e
flags  1: secret
fpr    2: 8777461F2A074EBC480D359419CC1C9E085B107A
grip   2: FF35C6E765F440145095750DC97D43D496C5ABEA
curve  2: ed25519
caps   2: s
flags  2: secret

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.