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

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

It worked again, attaching the screenshot. Unfortunately had disabled the logging and hence no log info.

No plans to work on this.

Long since resolved.

For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom sign.mk during the build process. By default the path to the included sign.mk is gnupg-vsd/sign.mk in the src repo. But that can be changed of course.

Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.

This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12

Oh! Very Nice! Thanks for this. I've commited it with adding the uninstall parts.

I could find no issue with the error handling for verify errors.