@landro , Do you have any key which might require passphrase update for its expiration?
I mean, do you have an gpg-agent option of "max_passphrase_days" set (default is not set).

(Since I was writing by phone, the sentence was terse. Sorry. This time, by PC.)

For smartcard, yes. The feature for ssh with smartcard has been available more than ten years. I recently apply the approach to gpg frontend.

@landro Thanks a lot. I think that we see some failures in the log, and there might be another bug in the failure path.

Fixed in npth 1.4.

Fixed in npth 1.4.

Fixed in npth 1.4.

In T1983: gpg2 prefers missing secret key to available key on card, I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

Basically, done.

In the crash log of 2017-05-22, I can't find any race or violation of shared object. It looks like some malloc related error.
Does gpg-agent emit error message(s)?

cgi finished.
translation has been finished except testimonials.

Sorry, my fix was not good. Re-opening.

It is applied to the master in the repo.
I took over the control so that I can close this revision.

Reviewed and committed in 2.1.21. Phabricator only support closing a revision by the author.
So, I've taken control of this revision to close.
Thanks.

BTW, in the test suite, gpgconf is invoked to kill gpg-agent/scdaemon/dirmngr. But it uses say, /usr/bin/gpg-connect-agent, which might be not yet installed.
I found such errors in Debian build: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=arm64&ver=2.1.21-1&stamp=1494993589&raw=0

I put another bug in 2.1.21. Please try: rGa8dd96826f84: g10: Suppress error for card availability check.

Err... it's my badness. rG97a2394ecafa: g10: For signing, prefer available card key when no -u option. introduced this bug. It checks if a key on card is available by agent_scd_serialno.
Call to start_agent with FOR_CARD=1 may cause an error if there is no scdaemon installed.
I need to fix skipping such errors.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

Fixed in 2.1.21.

Reference of stripe's checkout.js: https://stripe.com/docs/checkout

Here is the spec.

Patch applied and pushed to STABLE-BRANCH-1-4.

https://developer.apple.com/library/content/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html

Applied to master (formatting the commit log), and pushed.

The debug log includes communication between host PC and the reader, thus, it may include your input of PIN when you do that.

Thanks for your explanation. Now, I got it.

Reviewed and tested by "make check".

Thank you for the patch.
I'm not sure yet about the workflow of this site. I created a ticket for this and applied the patch and pushed.

Patch applied and pushed.

T1967: GnuPG should select a key for signing without trying to use missing subkeys and T1983: gpg2 prefers missing secret key to available key on card is related, possibly.

For your information.
Since 2.1.18, multiple readers are supported by internal CCID driver. PC/SC driver is not yet.
Since 2.1.20, gpg --card-status can have "all" or specific serialno of the card.
Perhaps, gpg --card-edit should support SERIALNO command as well.

Sorry, I just noticed this ticket now.

While T1983: gpg2 prefers missing secret key to available key on card for singing is in progress, change of T3119: gpg: Improve public key decryption is needed for decryption.

Sorry, I was wrong. The patch also works for signing to key.
The impact is gpg frontend always asks gpg-agent for card key.
It involves invoking scdaemon and accessing to USB.

Appending exclamation mark (!) to the keyid, you can specify exact match for the key.
I think that you can use 0xADCF72E06DBC3057! for git commit.
Please try.

For signing (not sign to key), here is my attempt:

Thank you for reporting. Sorry, I couldn't understand some part of your report. Perhaps, due to some terminology.

gnupg/distcheck aborted in #1046 and #1047 with 5min timeout, but it takes more than 8min.
Please modify timeout for gnupg/distcheck.

Thanks for your confirmation. I pushed the commit.

I suspect compiler optimization.
If you are with debugger, please check the function dns_ai_setent in dns.c.
When type==DNS_T_A, it sets sin_family = AF_INET. But it does some violent memory access for modern C.
Then, the value is accessed through saddr->sa_family.
I wonder if (*ent)->ai_family is correctly set here.

What is your architecture of the machine?
If it is related to the alignment of memory, I put a change: rG892b33bb2c57: dirmngr: Fix alignment of ADDR.
It will be in 2.1.21.

Pushed: rG116cfd60779f: g10: invalidate the fd cache for keyring.