I've mentioned this interop issue (and tried to propose clarifying language for the revised standard) in the IETF OpenPGP WG mailing list.

Please excuse my late reply. I was busy with other things over the last few weeks.

Here, we use keygrip search: https://dev.gnupg.org/source/gnupg/browse/master/g10/skclist.c$429

@dkg I mentioned it just because it was added as (part of the?) solution for Ed25519 issue, i.e. it is not something related to parsing of interoperable format but some further processing when secret key part is sent to the gpg-agent in some intermediate format.

I think rGba321b60bc3bfc29dfc6fa325dcabad4fac29f9c has nothing to do with interoperable formats -- how things are stored in ~/.gnupg/private-keys-v1.d is unrelated to the interoperable transferable secret key format specified in 4880 or its revisions.

It is a different trust model. The man page has some information but we meanwhile doubt that it will ever be of great use. It is over designed to be actually useful. Just don't care. For further questions, please use the mailing lists.

If I did enable "tofu" that was not on purpose and I would not know how. What are tofu related questions? Is there a doc you can point me to? (Also is tofu.db an annoyance, and if so in which way?)

TOFU is not used by default and thus the tofu.db does only matter if you have enabled TOFU. Its purpose is to track the use of keys and it also stored information which you explictly gave in response to TOFU related questions.

Hello,
I just hit the same issue in Ubuntu 18.04.5 LTS with gpg version 2.2.4-1ubuntu1.4 and the command line provided on post https://dev.gnupg.org/T3972#127356 by dkg has helped me fix it.
The faulty key was from the Tor project.

Right. However, the SOS thing should then also be used for secret keys. (FWIW, I wrote my last comment while you were writing yours).

@werner isn't it used just for the public key? The secret x25519 key, exported by GnuPG, looks as following (in the way it is stored in file):

We invented the 0x40 compression flag to declare that as native curve point format. With the introduction of 448 things got more complicated due to the new IETF statdards for this curev. This is the reason for @gniibe's proposal for a Simple Octet String (SOS) as a new data type in OpenPGP.

Investigated it more, and it looks problem is not in incorrect endianness. Exporting x25519 secret subkey from the GnuPG showed up that we still need to change byte order.
After some experiments I ended up with the following self-explaining code piece, which makes RNP-generated keys to work with GnuPG for import:

repeat:
    if (botan_privkey_create(&pr_key, "Curve25519", "", rng_handle(rng))) {
        goto end;
    }
    /* botan returns key in little-endian, while mpi is big-endian */
    if (botan_privkey_x25519_get_privkey(pr_key, keyle.data())) {
        goto end;
    }
    if ((keyle[31] != 0x45) || (keyle[0] != 0x40)) {
        botan_privkey_destroy(pr_key);
        goto repeat;
    }
    if (botan_privkey_export_pubkey(&pu_key, pr_key)) {
        goto end;
    }

There is also the issue that options flagged as ignore or forced in the global config file won't have an effect either. But indeed we could mark them as non-change.

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: