Fixed.

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?

I would add "Provide a verbose message of why the key cannot be imported".

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

Pushed the change by Ingo.

I finally recognize this change: rG638526d37fee: agent: Allow signing with card key even without a stub key..
I should have seen this yesterday.

Thanks a lot.
Let me explain the situation.

Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break.

Sorry, no. Although the output of --list-packets should not be parsed and is subject to change with each versions we know that ppl do it anyway and things start to break. Even when we added lines starting with the usual comment sign (#) to indicate the offset of the packet, we received quite some bug reports. Thus such chnages will only be done when they are really needed. For all other the rule is still: Use the source, Luke.

Thank you! And for what it's worth, I think your version,

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:

In T5166#139903, @ikloecker wrote:

Maybe the line (pksign.c:328)

algo = get_pk_algo_from_key (s_skey);

should be moved to the start of the else-branch (pksign.c:484):

Maybe the line (pksign.c:328)

algo = get_pk_algo_from_key (s_skey);

should be moved to the start of the else-branch (pksign.c:484):

else
  {
    /* No smartcard, but a private key (in S_SKEY). */

The problem is that in agent_pksign_do() the algo is read from s_skey (pksign.c:328), but s_skey is NULL because agent_key_from_file() fails to find a local KEYGRIP.key file in private-keys-v1.d. The code then reads the public key from the card (or a stub file), but it fails to set algo from s_pkey. The following patch fixes this:

In T5166#139883, @gniibe wrote:

I think that the semantics of gpg --quick-gen-key <KEY> card (currently) assumes keys are available on card.
IIUC, it is for some specific (very special) use case to specify same key creation time to the key on card.
I don't know well about this use case.

Anyway, because of this, (currently) the first run results undefined behavior.

It would be good if it just means "creating key(s) on card".

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?

Pushed in rE9ee011259f81: build: Use AC_CHECK_TOOL to detect objdump for cross build..

Thank you. I'm going to apply it, modifying a bit.

I think that the semantics of gpg --quick-gen-key <KEY> card (currently) assumes keys are available on card.
IIUC, it is for some specific (very special) use case to specify same key creation time to the key on card.
I don't know well about this use case.

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.

Thank you very much

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.

Select your key in the certificate view, click right, select "Backup Secret keys ...", store to a file. Then copy that file in a secure why (USB stick etc) to the new box, import it there.

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.

Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.

And I also did a backport to 2.2 :-) See rGa028f24136a062f55408a5fec84c6d31201b2143

We should not do this.

In T5130#139220, @ikloecker wrote:

Re-opening. Now trying to generate new keys fails with a "Wrong card" error.