Please enable all debug information in scdaemon.conf, like:

verbose
verbose
debug-level guru
debug-all
debug-ccid-driver
log-file /run/user/1000/scdaemon-verbose.log

The file scdaemon.log is short and contains only:

2017-12-24 12:32:53 scdaemon[4347] écoute sur la socket « /run/user/1000/gnupg/S.scdaemon »
2017-12-24 12:32:53 scdaemon[4347] gestionnaire pour le descripteur -1 démarré
2017-12-24 12:32:53 scdaemon[4347] pcsc_establish_context failed: no service (0x8010001d)

Thanks for your testing. please give me scdaemon.log with updated scdaemon.

With latestes master, there still appears:

--- ~ » gpg --card-status                                          2 ↵
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: selecting openpgp failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:

Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)

Im mean GnuPG fails for messages from a particular sender, while it works for messages from other senders.

Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?

The new reader arrived. Works find for every message - except obviously this one sender.
See reader https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116 ti should support large APDU. Same error messages
I think we are on the wrong error track here. It is not the reader. I now tested 4.

Thank you for your cooperation.

I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.

For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.

Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00

For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.

It's in gniibe/scd-kdf-support.
I think it's good to add to GnupG 2.2 branch.

If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.

I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.

Another log is not needed, as I located the issue. If you can try building GnuPG from Git repo (it's 2.2 branch now), it helps us a lot.

Thank you. Do you still need the log files with the settings suggested by Werner? Would I have to compile the master branch to see if it works now?

Thank you for scdamon.log. For the card reader, the interrupt transfer notifies no availability of the card before PC_to_RDR_IccPowerOn.
I fixed this issue in rG0bb7fd0cab2d: scd: Enable card removal check after select_application.. Let's see if it works well for the card reader.

This is the actual error message from your log file:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: idVendor: 04E6  idProduct: 5119  bcdDevice: 0525
[...]
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID submit transfer (83): 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed

For some reason, scdaemon.log is not yet available here. Please put it again.

Ok, edited ~/.gnupg/scdaemon.conf to contain

You may have other changes on your system as well.

But this does not explain why it works on the same system with GPG 2.1.11 instead of 2.2.2.
Here is what happens after applying the suggested quick fixes:

--- ~ » sudo pcscd
--- ~ » sudo chown enno /dev/bus/usb/002/005                        1 ↵
--- ~ » sudo chgrp users /dev/bus/usb/002/005                      2 ↵
--- ~ » ls -l /dev/bus/usb/002/005
crw-rw-r-- 1 enno users 189, 132 16 nov.  15:17 /dev/bus/usb/002/005
--- ~ » gpg --card-status
gpg: selecting openpgp failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

So you either need to start pcscd or you fix the permission of the device so that GnuPG's scdaemon can access the card reader using its internal access method. There are probably some udev rules which need to be adjusted. For a quick check you can manually change the owner or group to your own user or one of your groups. Then it should work again.

Dear Werner,

Entering on the shell

lsusb | grep USB

Implemented in a branch: gniibe/scd-kdf-support

Changes for Gnuk is done. It's now testing. It will be in Gnuk 1.2.7.

D441 applied. Closed.

I am pretty sure that older cards required this behaviour. It might have been a workaround for a bug in scdaemon, though - I am not sure. So we should test this with all available card versions.

I am closing this bug report, as I can't get feedback to fix something.

gniibe: Can you check the status?

Hello.
I am having the same problem with my Yubikey v4.

D441: card: Yubikey factory-reset failure is the patch.

This may fix the problem for new version 4.2.7:

That is the way I get my certificate signed, there is nothing I can do about it ;-)

It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).

Fixed in rG69614d55018d: scd: Support longer data length for special DOs for v3 card..

Given that 2.0 only gets important updates, and for 2.1 it is fixed, we can close it.

@werner I request re-consideration. I *have* read the discussion, and remain convinced that a parameter that allows shared access is necessary.

gpgtools will have to update.

This is on purpose. Please read the discussions. Use card-timeout in scdaemon.conf or "gpgconf --kill scdaemon"

If this is gone in master, please close this bug. Thanks :).

Issue seems to be gone in gpg (GnuPG) 2.1.22-beta75

Specification is finished.

bit 0 (in smartcard context, we say b1 as it starts from 1) of Extended Capabilities specifies if KDF-DO is supported.

Tag for KDF-DO is assigned as:

Automatic creation of socket directories creates cleanup trouble for projects previously relying on the agent-shutdown if $GNUPGHOME is removed: https://notmuchmail.org/pipermail/notmuch/2017/024550.html

Here is the spec.

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.

By the commit: rGf053f99ed0b0: scd: Handle unexpected suspend/resume by CCID driver., I put some code to handle such an expected return from the device.
Please try.
I couldn't reproduce this on my machine. (Suspend-to-RAM keeps my USB device running.)

It looks like the device got suspended and resumed.
But the application (scdaemon) didn't get noticed by libusb.
So, scdaemon kept communicating as usual, but got unexpected msg type = 0x81,
which is error report status (RDR_to_PC_DataBlock).

FWIW, the syntax of "vendor-id:product-id" is used for USB for any USB tools.

In T3082#95656, @gniibe wrote:

Thank you for your comment.

I think that a practical approach for us would be having a list of vendor-id:product-id in a file under gnupg/doc/ and maintain the list.
It will be up to distributions to use the list to build hwdb, udev rules, or whatever.

Thank you for your comment.

In T3082#95636, @gniibe wrote:

(3) We don't know which smartcard reader works fine, while we know some readers don't work well.

While I understand your request, it's complicated.