I also think this makes the most sense.

In my opinion, --locate-key should locate encryption key.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

There are some problems with the definition of --locate-key. Further discussion required.

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

gpg4win 3.1.6 is released which contains this fix.

Changes backported to 2.2

We also need to fix for encryption and signature in CSR.

Builds fine now with GCC 9. Thanks for looking into this so quickly.

Fixed in master, by removing use of compound literals. Compound literals are not portable feature (even for C99 code), so, it's good to avoid when we can.
Still dns.c uses C99 features of struct initializer with name.

Fixed in master.

No more complaints thus time to close.

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.

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

Jochen could you please test this on one of our test VM's again and resolve this then?

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

gniibe: Can you check the status?

2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)

Re-opening.

I also have to add that, if this really has been resolved, it only covers up the case if the missing subkey(s) is/are on the smartcard(s), it does not solve the problem when none of the missing signing subkeys are in smartcards (as in, all on different computers). And it's clear that for version 2.1.22, it fails to get the available subkey on the disk for this case.

@gniibe: I've tested 2.1.22 (from Debian experimental) and, while gpg --sign works, other programs (eg: git tag -s) still prompt to insert the card of the first signing subkey, despite the card with the second signing subkey being present.
Is that expected?

It's there in GnuPG 2.1 for a while, and bugs introduced by change were fixed.
So, I'm closing this bug.

@fogine , I'm afraid your comment is related to this bug particular report of T1983: gpg2 prefers missing secret key to available key on card.
And your problem cannot be replicated by my environment with 2.1.22.
If you still have the issue with 2.1.22, please open new ticket.

gpg (GnuPG) 2.1.21
libgcrypt 1.7.8

I added a new task status "Testing".

On Wed, 28 Jun 2017 15:47, noreply@dev.gnupg.org said:

What tests do you want to be done?

What tests do you want to be done?

Given that we have no TESTING status, the only way I can handle this is by keeping the ticket open and add the TESTING flag. Closing a bug which has not been tested is a bad idea.

@werner An open ticket should mean there is something that can be acted upon. Unless you are saying that we should actively look for regressions or should actively do more testing, this ticket should be closed now. There is plenty of peripheral information that will remind us of this ticket in case more issues resurface related to this change.