run-genkey is working fine in my test environment as well.

Keeping the lock over the call to the function does not look very robust to me. This is why I removed it. And since then PC/SC worked on Windows for me. Modulo this:
All these changes don't tackle the real problem that windows gets struck in a removed-card state.

Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.

The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader

I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.

The commit rGbb8e3996e44f: scd: Fix problem with reader list becoming empty. removed READER_TABLE_LOCK holding between apdu_dev_list_start and apdu_dev_list_finish, that opens possible stale resource access for CCID driver: reader_table[slot].ccid.handle

Thank you for your report.

I am also a MacOS Big Sur user who recently upgraded to 2.3.1 and had problems after upgrading. In my use case, I use the yubikey as the authentication for pass password manager which uses gpg under the hood.

This revision was committed with rM276187f6b62a: core: Extend gpgme_key_sig_t with trust signature members.

This is better name. My point was that if we ever use that to create such a field the developer should not assume that arbitrary REs can be used here. We need to have some practical value here and I would prefer to see only the domain name. However, OpenPGP allows for arbitrary REs and thus we may see them here. This is problematic but we can't do much about it.

Well, all I can say is that
./run-genkey --loopback "elektra testkey (gen-gpg-testkey)"
creates a key without any problems and without asking for a passphrase. Even, if I add the GPGME_CREATE_NOEXPIRE flag to the call of gpgme_op_createkey. At least, from a terminal.

That would required that we also add an option --enable-ccid-driver - better tell the macOS folks to put diable-ccid-driver into /etc/gnupg/scdaemon.conf

FWIW, I think that it is a Bad Thing to use unreleased stuff from 1.8 for Debian packages. Only released versions sshould be used or patches we explicitly made to fix a bug. At the very least Andreas should have asked upstream whether this commit should be used for Sid.

Also fixed in version 1.8: rCbd662c090bd4: ecc: Fix the previous commit.

Note that the handling e part uses standard MPI in 1.8 (while it is done by opaque MPI in 1.9).

Or... we could add --disable-ccid-driver as default for macOS.

If it is built with LIBUSB enabled, please try adding the following to your scdaemon.conf:

disable-ccid

Thank you for your response! I tried out all variants of gpgme_pinentry_mode_t and implemented a passphrase callback (using gpgme_set_passphrase_cb as suggested). It turns out that the callback is not invoked at all. However, if I switch back to gnupg 2.2.27, the callback is being invoked and the key is being generated (using the passphrase specified by the callback, as expected).

The problem might be that gpg tries to ask for a passphrase which fails on the CI. Try setting a passphrase callback and setting the pinentry mode to loopback. See https://dev.gnupg.org/source/gpgme/browse/master/tests/run-genkey.c$435.

Thanks for testing. I hope to get 2.3.2 out in two weeks.

After upgrade:

Added documentation for the new fields.

• Renamed trust_regexp to trust_scope.
• Use part of _unused for storing trust_depth and trust_value.

Thank you for taking time to look into that. There are couple of issues in the CAcert bug tracker talking about the same issue but if, (I see right), the certs still miss the usage flags:

RFC-5280 states in 4.2.1.3 for Key Usage:

The error code is: No Readers Available. With the latest version you should have seen that string.

Meanwhile we did some more tests on Windows and so you many want to try our betas at

I had a similar issue in Windows 10 too. In my case, the issue occurs only when my home path has non-ASCII characters. After I changed home path it works well.

Any chance looking into this @werner?

In T5359#145741, @werner wrote:

Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?

Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?

I'm referring to this: https://www.gnupg.org/howtos/card-howto/en/ch02s03.html