This bug affects GnuPG 2.1.20 when using keyrings (I guess most users upgrading from older versions do). This is fixed in 22739433e98be80e46fe7d01d52a9627c1aebaae.

Just wanted to chime in and say I am hitting this as well:

7 years old and meanwhile Kleopatra has been reworked. Further showing two fingerprint (for the signing and the too be signed key) is confusing. In particular because the passphrase for the signing key is usually cached.

Justus, will you please so kind and take care of this.

This is likely a duplicate or something really closely related to T3080.

If I hack the test suite to use the old keyring format, I see two tests failing:

This has nothing to do with the keybox file.

I suspect my issue T3123 is a duplicate of this. Did anyone find a solution how to get out of this situation?

The debug log includes communication between host PC and the reader, thus, it may include your input of PIN when you do that.

Ping? Otherwise I would provide the required information.

Reviewed and tested by "make check".

For your information.
Since 2.1.18, multiple readers are supported by internal CCID driver. PC/SC driver is not yet.
Since 2.1.20, gpg --card-status can have "all" or specific serialno of the card.
Perhaps, gpg --card-edit should support SERIALNO command as well.

I do have multiple readers. If I insert one card in each of my two readers, GnuPG doesn't choose the one it needs for any given operation. It's been three years, so I don't remember exactly what DOES happen. I think it just acts as if one of the two cards were inserted, and totally ignores the existence of the other. What I want is for it to dynamically use keys from whatever cards happen to be inserted.

Yes, I know it's not perfect but when the secret key is unknown to gpg-agent then it shouldn't attempt to use it.

Sorry, I just noticed this ticket now.

While T1983: gpg2 prefers missing secret key to available key on card for singing is in progress, change of T3119: gpg: Improve public key decryption is needed for decryption.

Sorry, I was wrong. The patch also works for signing to key.
The impact is gpg frontend always asks gpg-agent for card key.
It involves invoking scdaemon and accessing to USB.

For signing (not sign to key), here is my attempt:

Can we activate this for --import and --recv-key as guilhem requested?

I've raised the priority here because this bug gets reported regularly and it seems a shame that we haven't fixed it yet, despite having a patch available for quite some time.

The branch dkg/T1967 contains a fix for this. Please review!

I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org

I can't seem to reproduce the above or my original issue. I just upgraded to a newer Ubuntu release where gpg2 is now the default instead of gpg. Maybe that's what fixed it.

litmus test will be :

I can repropduce this with gpg (GnuPG) 2.1.17 on Chakra Linux.

Sorry, merging/closing is not good. This should be a subtask of T2291.

Do you configure your libraries?
Please check your system if you have ilbgcrypt 1.7.6 runtime library.
I mean: LD_LIBRARY_PATH and ldconfig.

We need to change how to access scdaemon from gpg frontend. Thus, I merge this to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)), setting its priority to High. Please continue at T2291.

Yes, 2.1.20 has the issue, too.
The crash report can be explained as: if the double-free can occur when multiple threads access to the cache at the same time, allocation in md_open may crash.

I finally got around to test this again - sorry for the long wait. I testet with 2.1.20 - same behaviour as in 2.1.19. Crash report attached.

Could the priority of this bug be pushed up? I was trying to follow the instructions to verify a Centos 7 install image, but was unable to view the fingerprint using the version of gpg I have installed on this system - gpg (GnuPG) 2.1.19. This feels like a very bad regression from a UX perspective.

I can confirm that scdaemon built from today's master (2.1.21-beta73) releases the card, and works as is for my use case.
Version that is included with zesty (2.1.15-1ubuntu7) still keeps the card reserved indefinitely, like all previous versions.

Yes, there are two things to implement; How gpg frontend use gpg-agent (1 in Werner's comment), and new shadowed key format support (2 in Werner's comment).

Thanks for suggestion. I'm sorry that I haven't caught this report. Now, it's assigned to me.
This is merged to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)).

I'm an active user of multiple smart cards and would like to see key stubs bound to multiple serial numbers at the same time. I took a look at the agent code and could try to prepare a patch that realizes this by allowing a list of serial numbers as a new shadowkeyinfo field. Would this be a welcome addition or would it possibly break things?

Thank you @gniibe, I will check if scdaemon from 2.1 solves my troubles and followup if it does not.

Thank you for your comment.
FYI, when card is removed, scdaemon invalidates cache. So, #1 is already done.
In 2.1.x, scdaemon releases the reader when it finds the card is removed.
(Not for 2.0)

I could argue that caching the information about the card and reusing it is pointless and dangerous if such cache is not invalidated when the card is removed. Next time the information is needed, there may be a different card lying on the NFC reader. And it certainly does not make sense to keep the card reserved for exclusive use when the card is physically long gone.

No way to fix, itself. Better warning/error message can be done.

This bug is not reproducible for me. I don't think it is Yubikey specific.
I suspect some failure for the transition from 2.0 to 2.1.
In GnuPG 2.1 the private keys are stored under the directory gnupg/private-keys-v1.d.
Do you have this directory?
How does it goes when you prepare another directory and specify that?
I mean:

mkdir SOME-NEW-DIRECTORY
gpg --homedir=SOME-NEW-DIRECTORY --card-status

This is fixed in bf8b5e9042b3d86d419b2ac1987a9298c9d21500.

Applied as ebe12be034f0.

I confirmed that it's 64-bit big-endian.
I wrote a patch for testing. D421: padding is needed for 64-bit big endian

If s390x is big-endian, we need padding at the start of the cell structure. So that the _flag can be compatible to the vector element.
I'll see on the porterbox myself, too.

I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.

Fwiw b83903f59ec5d49ac579f263da70ebc8dc3645b5.

@gniibe good catch! I'll fix that and we'll see if that improves things.

IIUC, cells are used for a place for vector elements.
I'm afraid what happens for memory space not used for vector elements.

resolved with 94645311f8a3e9ae33643512f87fbef41bf0556f

Please just keep discussing *one* issue per task.

It was run automatically. Installing libbz2-dev did not help.
Output stays the same.

Steps to (hopefully) reproduce
Cloned the developtment branch and reverified the commit hash described in
https://www.gnupg.org/download/git.html
[Removing https://git.gnupg.org/gnupg.git would be great, since cloning that did not work]
$ ./autogen.sh
$ ./configure --sysconfdir=/etc --enable-maintainer-mode && make
$ make check &> check.log
make does not exist also, though cpu seems to not work on

You need the development package installed (e.g. libbz2-dev on Debian-like systems). Then, rerun configure and rebuild.

$ gpg2 --with-colons --list-config compressname
cfg:compressname:nicht komprimiert;ZIP;ZLIB

Adressed in 94645311f8a3e9ae33643512f87fbef41bf0556f.