In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

GPG Version :

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.

Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).

I see your situation

In T5442#146869, @gniibe wrote:

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

In T5415#146808, @KasparEtter wrote:

Please excuse my late reply. I was busy with other things over the last few weeks.

Yes, putting disable-ccid into ~/.gnupg/scdaemon.conf works for me with GnuPG 2.3.1 under macOS Catalina (10.15).

I still don't understand what the problem is/was, so I cannot judge whether it's better to recommend this manual configuration for Mac users or to disable CCID by default on macOS.

Please excuse my late reply. I was busy with other things over the last few weeks.

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).

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.

So, has this issue been solved?

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. 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).

@werner @ikloecker Any more thoughts / updates on this?

Thank you for your report.

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.

In T5436#146148, @ikloecker wrote:

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.

@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.

@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.

So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.

Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.

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.

(I disabled this boor and restored the state)

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.

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

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

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

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

Also let me know if there are any daemons I have to kill/restart when switching between GnuPG versions by changing the $PATH. Whenever I have problems with my YubiKey, I run gpgconf --kill gpg-agent, which I also executed when I switched from version 2.2.27 back to 2.3.1 but I have no idea whether this is required or sufficient.

Run gpg --debug ipc --card-status to quickly see the communication with the scdaemon.

@gniibe can you provide any commentary on why the gnupg ccid udev rule is so much smaller than the one debian maintains? Is the debian one considered authoritative these days?

Thanks @gniibe, that's very helpful advice and pointers. Very appreciated, cheers.

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.

Hi, as a contributor to NixOS I'd also like some guidance. I'm testing the 2.3 upgrade ahead of 2.4, and it "breaks" Yubikey UX that I know many of us use. This might be because we appear to not yet install gnupg's CCID udev rules installed. A few questions:

Thank you for the suggestion of disable-ccid that seems to have solved the problem.

I can confirm disable-ccid works, thank you!

Please have a look at the log:

IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).

Ok, thank you. I think task can be closed.

mkheader has CFLAGS_FOR_BUILD since libassuan 2.5.4.
gost-s-box has so since libgcrypt 1.9.0.

Ok.
But`CFLAGS_FOR_BUILD` not mentioned in build rule for mkheader

I'm sorry I disappeared on this issue for two weeks; I just got reminded of it by seeing the e-mail with the status change. I've updated to the latest gcrypt (which is the commit with the patch, now pushed to the repository) and was able to upload this to Apple without it being flagged; thanks!

CC_FOR_BUILD is used for building executables for the build machine.
CC_FOR_BUILD may be different to CC (for target).

Referencing external patches is not sufficient

What is vcpkg?

Sorry, I can't parse your message. Please describe the problem or feature requests. Referencing external patches is not sufficient. What is vcpkg?

Note that rndjent.c is already build with -O0 as can be seen in example above. That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

IIUC... Could you please try this patch?

diff --git a/random/rndlinux.c b/random/rndlinux.c
index a7a78906..c20c5d4c 100644
--- a/random/rndlinux.c
+++ b/random/rndlinux.c
@@ -35,10 +35,13 @@
 #if defined(__APPLE__) && defined(__MACH__)
 #include <Availability.h>
 #ifdef __MAC_10_11
+#include <TargetConditionals.h>
+#if !defined(TARGET_OS_IPHONE) || TARGET_OS_IPHONE == 0
 extern int getentropy (void *buf, size_t buflen) __attribute__ ((weak_import));
 #define HAVE_GETENTROPY
 #endif
 #endif
+#endif
 #if defined(__linux__) || !defined(HAVE_GETENTROPY)
 #ifdef HAVE_SYSCALL
 # include <sys/syscall.h>

Fixed in 1.42.

I was wrong in my last comment. Escaping by another \ is needed.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

So, I actually just filed an issue about this work: T5375, and then found this opposing task while following through on the various commits ;P... Apple actually forbids usage of getentropy in applications they publish to their App Store (citing ITMS-90338: Non-public API usage), and so there needs to be a way to disable this weak_import. FWIW, I'm not sure if this is only on iOS or on macOS as well (I haven't gotten around to trying to publish a macOS build with the new libgcrypt yet).

@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).

Or, if we keep the code of newline (so that it will eventually support path with a space in future):

Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.

@gniibe OK, so... "worst case": I guess this worked? ;P

@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(

@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.

I wonder if this works in your use case:

diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4
index d910754e..aeedaf10 100644
--- a/m4/gpg-error.m4
+++ b/m4/gpg-error.m4
@@ -65,7 +65,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
   min_gpg_error_version=ifelse([$1], ,1.33,$1)
   ok=no

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.