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.

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.

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

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.

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

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

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.

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.

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

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

Just search for something.

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.

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?

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

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

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.

In T5393#145098, @gniibe wrote:

Please note that *_error-from_syserror accesses system's errno which may be cleared by xfree.

Having a fallback in Kleopatra makes sense because very old HKP keyservers don't return the fingerprint and LDAP keyservers not using the modernized schema do neither.

Please read also the report T5442 which is basically the same.

Thanks for the well written report. We had another already, and thus I merged it into T5415.