This patch changes all the logic of finish_lookup.
It should be only when secret key lookup.
D297: 785_sign-fix.patch has been changed to do that, and it was applied to the master.

Applied to master.

Fixed in master, applying D297: 785_sign-fix.patch.
If needed, it will be in stable 2.2 branch, in future.

@bluca I created a ticket for smartcard, so that this ticket can focus on the issue of available keys on host. If anything, please add comment to T3416: gpg should select available signing key on card (even with -u option).

I have updated D297: 785_sign-fix.patch patch to minimize the impact only to secret key lookup.

Here is finish_lookup with want_secret flag.

This has larger impact for key lookup.

While trying to identify the cause of this problem, I found that the import doesn't success with expired key.

My change only addressed the use case with smartcard. So, I removed [TESTING] tag.

Now, 2.1.22 or later supports automatic selection of secret key by available key on card.
Closing.

OK, I changed my own purpose. I don't touch internal representations.

Committed to both branches (master and 2.2), so, closing.

In GnuPG 2.1, secret keys are under control of gpg-agent. Currently, it is not deleted by gpg frontend.
Please run:

$ gpg -K --with-keygrip

It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.

While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.

Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..

When Thhmmzz is specified, no adding 12 hours, that's the intention of the code, I suppose.
However, the implementation is wrong, since the beginning (not supporting "Z" or timezone for ISO-8601. interpret the string as UTC).
I will take that, too.

I think that adding 12 hours by parse_expire_string make sense.
The test suite should be fixed.
I will.

In the log, I found:

Possibly, timezone (of build machine) matters.

@werner , I understand your poiont.

Please try this patch:

Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

I applied the change to libassuan.

Don't need to check macOS version. Simply, if it's not defined, define INADDR_LOOPBACK.
That's better. Because it can support other cases.

It will be in the next release (2.4.4).
Thanks for reporting.

The description of this bug report is not correct.
_POSIX_C_SOURCE should *not* be defined to use INADDR_LOOPBACK for the system.

With following files, I managed to emulate similar experiment. My intention is to replicate.

For me, I cannot replicate this issue with 2.1.20, either.

I tried to reproduce the problem with gpg-2.1.22 or later, but I couldn't.
What I did was:
(1) Prepare expired key of 2D182910, by removing three signature of current public key.
(2) Set "ultimate" trust with the key.
(3) Import current public key of 2D182910.

For the record, the authentication status reset by VERIFY command was introduced in OpenPGPcard specification V2.2.
I think V3 card supports that.
Gnuk 1.2 supports this reset feature.

Yes. For the use case of GnuPG, it is better to support disabling (unauthorize) use of keys.
On the other hand, IIUC, the original OpenPGPcard implementation is designed/implemented under the influence of other smartcard usages.

Unfortunately, not all OpenPGPcard implementations support command to unauthorize use of keys.

Let me explain the situation.

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

In Fedora, they use this patch:
https://src.fedoraproject.org/rpms/libgcrypt/blob/6c13b08816b206b3ff2bab09fe55157cb3417fd1/f/libgcrypt-1.8.0-build.patch

Pushed for master.

Bonus: less memory usage and performance improvement.

Re-opening.

For me, it works. Please re-open if you still have any issue for NetBSD.

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.

I think that this issue is fixed in 2.1, which use KS_FETCH instead of KS_GET with fingerprint.
Please test with 2.1.
We don't change 2.0.

D441: card: Yubikey factory-reset failure is the patch.

This may fix the problem for new version 4.2.7:

Fixed in 2.1.22.

GnuPG 2.1.22 in Homebrew is out: https://github.com/Homebrew/homebrew-core/commit/39a392ffd6ac20a36ea8a4aec5c4dc5febcfc1d6
Please check it out.