@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:

Fixed in GnuPG 2.3.1, so, add the tag for GnuPG 2.2.

Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.

The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.

Thank you.
Applied both to STABLE-BRANCH-2-2 and master (changing new function name).

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

Ah, I see that when there is no card reader, it returns "Service is not running" with PC/SC.
Let's fix that.

When testing under Windows "scd devinfo --watch" returns immediately with ERR 100663614 Service is not running <SCD>
Probably also if you would use PC/SC on Linux but I have not tested this.

So far -- unlike the previous patch -- this seem to help (but since the issues are infrequent I can't be entirely sure yet).

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

T4702 is our release info task for 2.3.0

@gniibe Hi! Can you estimate, when this feature will be released?
I have not found this patch in the latest GnuPG release tags (in the Git repository) either by the name or the commit hash.

Lowered priority because in reality it is not possible to get a certificate for an arbitrary SigG key on the card. Only accredited CAs may issue certs and they want to keep full control over the key generation.

do_sign() calls find_fid_by_keyref() which does a switch_application(). So, I think the SigG application should already be active. But, yes, please have a look at it.

We need to switch to the SigG application. Shall I look at it?

It seems you have a pretty good understanding and also test cases at hand. May I ask you to apply the suggested pacthes to master?

Already have set another, thanks gnibe! See ya!

Please change your passphrase for your card, BTW.

Good. The error recovery worked well.

Yes, that worked. Thanks for the tip and sorry for the noise ;-)

I think that ... For some reason, your private key file under .gnupg/private-keys-v1.d has wrong serial number.

Thank you for your testing.
May I ask more test, please?

Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.

Yes, makes sense. Although, you should use datalen = indatalen; in the last line (to prevent typos in the numbers).

IIUC, for completeness, it would be good to add the lines like:

In T5167#140229, @gbschenkel wrote:

Nice, I gonna apply the patch and see if resolves for me!

Nice, I gonna apply the patch and see if resolves for me!

Reading the code again, I think that some configuration of NKS card doesn't work well, when it has no certificates but keys (e.g. IDLM config).
I'm going to fix do_readkey as well (the approach #1).

In T5150#140039, @gniibe wrote:

With little (mostly no) knowledge of NKS card, I think I fixed this issue.

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

Thanks a lot for your time to locate the problem. I took the approach of #2.

This works now. Thanks.

I'm not sure why I thought that it would work now. With current master I get

$ gpg-connect-agent "SCD READKEY --info-only -- 39400430E38BB96F105B740A7119FE113578B59D" /bye
ERR 100663414 Invalid ID <SCD>

I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Changing modes will I lose/change my OTP and FIDO codes?

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Thanks a lot.
Let me explain the situation.

Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

I think that T5150 was also not fixed completely.

I found a bug which resulted "Not Found <SCD>" when "SCD KEYINFO" is used with "--data" or "--".
It is fixed in rG54b88ae46062: scd: Fix KEYINFO command with --data option..

Fixed in master. I will backport to 2.2.

I was wrong. Patch is being updated...

I can't see how it occurs. "SCE KEYINFO" and "SCD READKEY" with keygrip both goes exactly same code path (the difference is only the "action" argument).

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

You better wipe ecc_d_padded or use xtrymalloc_secure.

Here is a patch: