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.

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I fully agree. That was actually my itention - not sure why the coded ended up as it is.

Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,

The pincache is actually not what you think it is. It is only used to allow switching between different application on a Yubikey which reqieres a new VERIFY command after switching back to the first application the card. What you feel as caching is the state of the card, which usually keeps its verification state until the card is powered down.

Frankly, I am pretty sure that the new base64 encoding of the fingerprint leads to less diligent comparison of the fingerprint by the user. I don't understand why they did not used a truncated hex output or zBase32 .

Thanks for using GPA. Unfortunately, I have to tell you that GPA development has been stopped and I can't say whether we will fix that bug any time soon. Please consider to switch to Kleopatra which is the standard key manager included in gpg4win.

FWIW, we can and should run our test suite under valgrind from time to time

(I disabled the account of this boor)

(I disabled this boor and restored the state)