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.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

In T5157#139622, @gniibe wrote:

ARM64 has been only tested on platforms which support ELF.

While it doesn't looks good (using AMD64 even if it's ARM64), I think this patch should be applied:

diff --git a/cipher/asm-common-aarch64.h b/cipher/asm-common-aarch64.h
...

For the record, Thomas from mailvelope confirmed by signed mail that this is the correct id.

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

Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..