Indeed, GnuPG's IPC uses TCP connections from 127.0.0.1 to 127.0.0.1 taking the destination port (and a cookie) from a file. We can't change that easily to the new Unix socket implementation Windows recently introduced. I hope there is a way to exclude localhost->localhost from congestion control.

FWIW: It does works when using GNUPGHOME instead.

This has always been the case. git blame shows for check_signatures_trust:

Done

BTW, do we really need a C++ API for this? Might make sense due to the need for a context.

Well, we also have the gpgme test suite which tests a couple of other things and for obvious reasons we need to keep this stable. Granted, sometimes we had to change the gpgme test suite as well. My personal preference would be your second choice.

I can't replicate your findings here . In a test directory w/o a gpg.conf:

Uihhh

Did you also tried with --no-sig-cache ? That could help to get a better insight into the reason for that difference.

Please test using the latest gpg4win installer (beta145).

The problem is that it may take really long to read the certificates form a card and some card applications even require to give a PIN for reading the certs. A background operation may thus surprisingly lock up the box

rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.

Please use "unbreak now" only for *released* software with a criticial bug.

master is development and you can't expect that it always build on all platforms.

We do not have an error code for Admin PINs. The Admin PIN is also an OpenPGP card specific termm and other cards use different terms. For example a NKS has no Admin PIN at all but an alternative PIN.

New API gpgme_op_random_bytes is now in master (gpgme 2.0). Use tests/run-genrandom --help for testing. Extra features will come soon.

Please try again. This was due to a change in the RBL we use. Might be fixed now.

Looks like scdaemon which I experienced today also but without having enabled scdaemon logging.

I don't see a bug here and any change in this domain disks a regression with existing data. BTW, the mode byte was not even part of the signed data before signature version 5.

My comment from a year ago still holds true; you may want to fix your testing framework and re-openig this bug iff you can show that there will be no regression with PGP 7 and later.

Also fixed for 2.4