Here, we use keygrip search: https://dev.gnupg.org/source/gnupg/browse/master/g10/skclist.c$429

jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).

With sqlite3 using -static-libgcc, I confirmed that GnuPG and its friends are built well with newer mingw on bullseye. And I lightly tested GnuPG on Windows.

Ah, I realized that the build for sqlite3 in Speedo has a patch using -static-libgcc.

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

Thanks for your report.

Thanks. I push the fix of yours.

Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).

I test on ppc64 machine (POWER9, big endian).

CVE-2021-33560

Thank you for your report.

Let me rephrase from a viewpoint of mine (an implementer).

The paper describes another problem: interoperability (or interpretation) of "ElGamal encryption", and its impact.

This is another test case for GNU C library's strncmp:

This is the minimized test case.

Possibly, it keeps running at calibrate_s2k_count, for some reason.

I was wrong.

I am testing with rGccfb5e0a7dc6: scd: Use SCardStatus for pcsc_get_status. on GNU/Linux.

Sorry, it's my fault.
Fixed in rGac731dbbbd21: gpg: Fix allocation for EXTRAHASH..

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

Applied in rG32baa9acfb15: scd: Serialize READER_TABLE access for PC/SC..

Please note that we don't use lock in apdu_dev_list_start/finish any more.
Use of lock is narrowed, only within apdu_open_reader function.

Make the lock holding narrower, and it allows no exposing reader_table_lock.

Exposing reader_table_lock would be better.
I found a dead-lock condition when apdu_close_reader is called during apdu_dev_list_start/finish.

I wonder if PCSC_SHARE_SHARED is related or not.

And if the coding style of hiding mutex_lock/mutex_unlock inside different functions matters, we can expose the mutex to its user.

Last commit will be:

The second commit is replacing a use case of close_pcsc_reader by clearing pcsc.rdrname and calling release_pcsc_context.
This makes the use of close_pcsc_reader to its original purpose only (== closing PC/SC reader as a method of close_reader).

OK. As I pointed out a commit having multiple things may make analysis difficult, I should have been careful.
So, let me fix the problem by multiple commits.

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.

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

@colemickens We don't maintain any ccid udev rules in GnuPG. What do you refer?

Perhaps, if a distro haven't offered setting of USB, it would be better to configure GnuPG build with --disable-ccid-driver and only support scdaemon with PC/SC. GPG for Windows does so.

1. It's a breaking change for system with both of PC/SC and CCID. T4673 due to T3300
   • If you configure with no libusb, users don't need 'disable-ccid' option.
2. I don't know how "wide".
3. In Debian, it is maintained here: https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/scdaemon.udev
4. Yes.

To set DISPLAY, dbus-update-activation-environment is your friend.

FYI, for me, on a machine with Debian GNU/Linux, I use Sway, it works fine with pinentry-gnome3.

Backported in rC3f48e3ea37ad: ecc: Check the input length for the point..