Well, we have always expanded envvars in registry values. You need to create the value as an REG_EXPAND_SZ type, though.

Fixed for 1.8.8

Thanks for investigations! Indeed, we do change byte order when storing/loading private key, as MPI should be big-endian, while curve25519 private key is little endian.
Do I correctly understand that we should store it in the MPI as it is (like with Ed25519)? It would be nice to clarify that in the RFC draft.
Another thing is that in my test even if byte order is not reversed in the secret key (including the attached test key), GnuPG still asks for password, reporting "error sending to agent: Bad passphrase".

Hi Werner, I need this for a potentional customer. And generally I need this in config, too. because in support we have to send customers configuration files which they do not need to edit and variables are important because of file system permissions. But most immedialtely I need this for homedir registry.

Because an existing setting in gpg.conf overrides the keyserver set in dirmngr.conf

jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).

With sqlite3 using -static-libgcc, I confirmed that GnuPG and its friends are built well with newer mingw on bullseye. And I lightly tested GnuPG on Windows.

The problem here appears to be that the "MPI" of the curve25519 secret key is not actually a standard-issue big-endian OpenPGP MPI -- it's an opaque bytestring expected to be passed to the underlying "native" implementation of x25519, in the same way that the secret key is handled for Ed25519.

investigating the subkey in python:

looks to me like you've got the byte ordering of the Curve25519 secret subkey reversed from the way that GnuPG expects it.

fwiw, gpg-agent complains that the keys don't match:

why not use gpgconf with the dirmngr component to set the keyserver option there?

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