While trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.

According to our rules an initial set of tags should never be a milestone but be in the Backlog or, if work already started,in the WiP column. Because it is anyway invalid, I removed the tags.

T6536 has been fixed. With today's commits the Brainpool curves are now also flagged as compliant in gpgsm.

Now fixed in 2.2 and 2.4 (commits rG08f0b9ea2e955209d467f1ff624bf7abd10ae7ac and rG7661d2fbc6eb533016df63a86ec3e35bf00cfb1f). See also T6752

Well, see my very first comment.

Well, this bug is fixed by using a decent libgpg-error or configure it correctly.

Should we have a gpg_error_from_w32() as companion to gpg_error_from_syserror() ?

Your tools don't use the chain validation model which is required for QES (at least according to German laws). A signature is still valid even if the certificate has been revoked. You need to consider the context and the time the certificate was revoked.

Is currently not enabled, sorry. Use git:// ot the mirror here at dev.gnupg.org. Note that we sign all our commits using a token and as such it is a stronger security prove than a just an arbitrary TLS connection.

Sorry, we have nothing do to with this pypi thing even if that file claims " The GnuPG hackers".

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

Actually we never use uint8_t* because that is c99 and very uncommon except for some MCU projects. Instead we use unsigned char *. The use of void* is often used because this allows to pass arbitrary types to a function without requiring ugly and error-prone casting at the caller site.

You don't need a library but just one object file.

@fse: Github is not an option here. We don't use it and thus everything relevant to Libgcrypt needs to be documented here and not at some external platform.

Sure it does not. That is the whole point of the loopback thing.

Yes, there is clearly a problem with the handling of NDEF. I have a fix for that but there are other oddities in that pkcs12 object. Do you have the Firefox version you used to create this?

I am wondering a bit about the gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> which is not the string I expected for this error:

I forgot to backport one patch. With that patch we get what we expect:

Core part done.

Form the Gnupg-2.2 commit rG936954a18a2df made sure that the hkps:// prefixing from kleopatra is ignored.