Still there are two places where we use "SCD serialno --demand <SERIALNO>". One is g10/skclist.c where we list available keys, another is the funciton card_key_available in agent/command-ssh.c .

By the change of rG9f39e0167d06: agent: Fix ask_for_card to allow a key on multiple cards., the SERIALNO in the stub is just an auxiliary information, not identifying the card. Now, it is the keygrip for key to identify/select the card.

I did too many things at once.
I'm going to divide up into pieces.

For OpenPGP card v3.x, the data object is available, but it doesn't come with a button physically. So, I think it's no use.

Fixed in master.

This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.

If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:

It appears (for me) correct behavior.

Well, gpg-error is special. For other libraries, adding -I and -L is enough and good.
Fixed in master.

Thank you. I only tested a configuration where installation of libassuan has same prefix as libgpg-error. That's the reason why this bug exists.

It was fixed in GnuPG master by rGc395f8315362: agent: Terminate pinentry process gracefully, by watching socket. and rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM..
Those will be in GnuPG 2.3.

Thanks for your report.
I think that adding an option for disabling tests is too much.
If it were AC_SUBST, we could use HAVE_PTHREAD in tests/Makefile.am.
In the current situation, just modifining t-lock is easier.

I think that I located the cause of this bug:

For my environment (Debian buster's 2.2.12 and another one from GnuPG master), both (no argument and foo) work well.
The invocation with argument let pinentry pop up to ask passphrase.

My understanding is: it was introduced by rG370f841a0135: Enhanced last patch. in 2009 to give information to client (for a specific command at that time), possibly in a hope that server side would support the feature for all commands (and client could benefits).

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

I'm going to push this change to master.

I was afraid that there are wrong usage where HANDLE is passed where int for fd is expected (or opposite).
But it seems, there are only usage where it should be gnupg_fd_t ideally but using int.

I'd like to push your change to master, if possible with exact check.
Do you intend to put your comment to the master repo? Or, it's for discussion?
It's OK for your topic branch, but, I feel that it would be too long to be included to master repo.

I'm confusing if following API should use gnupg_fd_t or not:

• iobuf_fdopen, iobuf_fdopen_nc
  • Perhaps, these are using int for fd, like es_fdopen
• set_attrib_fd ?
• read_passphrase_from_fd ?
• set_status_fd ?
• is_secured_file ?

As far as I know, usually, gpg/gpgsm can assume same version of gpg-agent.

I pushed a fix to master: rG858dc9564326: scd: Fix bBWI value.

Except w32_system function, it's done.

APIs which need revise (where we use pid_t):

API which uses int for fd:
GnuPG common:

• gnupg_create_pipe, gnupg_create_outbound_pipe, gnupg_create_inbound_pipe
• gnupg_spawn_process_fd

gpgrt:

• gpgrt_make_pipe (not yet exposed to public API)
• gpgrt_spawn_process_fd (not yet exposed to public API)

HANDLE type casting to long is wrong (it results masking the value to 32-bit, which is not needed).
I fixed:

• rGa64411c607d5: common,w32: Fix cast from gnupg_fd_t to call _open_osfhandle.
• rE655ed9d83889: w32: Fix HANDLE to internal fd conversion.
• rEf93a0358dc82: w32: Fix cast to internal fd.

I see your point (I am also the one who implements reader/token). That's reasonable argument.

Thanks for your report, with helpful log.