Last week:

• Tokyo and suffered from train problem.
• PC/SC
  • multiple card support: T4620: no support for multiple (yubikey) smartcards plugged in at the same time
  • Investigate SCardGetStatusChange/SCardCancel for blocking API
    • Conclusion: It is racy when used for multiple access for cards with a single context
• My own environment of Windows
  • Takes more than a day to move from 1803 to 1903
  • Configure use of USB
  • Now ready for tests as a guest OS under Debian host

This week:

• Test new PC/SC on Windows

I created a branch for this task: https://dev.gnupg.org/source/gnupg/repository/gniibe%252FT4620/

I'm on the way to home (was in Tokyo with Christian's visiting Aoyama-Gakuin Univ.).
Not sure, I will be able to join on time.

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.

Last week:

• not much work other than responding private message for Poldi, to reporter of T4626
  • because of transition of summer vacation (school has been started and children complain ;-)
• In theory, multiple card/token support is not that hard, I think, so

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.

Last week:

• *-config issue: T4678: libassuan.pc missing include dir directive in cflags
• scd: APP switch PIV <-> OPGP
• T4228
• Fix for gpgrt_poll
• Factor out export_one_ssh_key, so that we can support exporting all subkeys in future
• private mail exchanges explaining it's not PAM-poldi, but greeter in KDE which is wrong

This week:

• bug fixes
• Learn PC/SC thing for scdaemon to support multiple readers/tokens
• Exercise with FPGA with SHA-2 implementation in verilog
  • I'm considering another device like NeuG standalone but with FPGA instead of MCU

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.

Last week:

• libgcrypt: T4663: libgcrypt: fix build without threads by adding an option to disable tests
• libgcrypt: publish rCcdaeb86f067b: ecdsa: Fix unblinding too early.

This week:

• security release of libgcrypt will be this month for T4626

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.

Last week:
For my environment, GnuPG and GPGME "make check" works well.

• Fix for extended key format for private key (master and 2.2): rGf588dd8d1766: common: Fix line break handling, finding a space.
• Remove fallback to PC/SC (master only): rG100642e77696: scd: Remove fallback mechanism to PC/SC.
• Fix erroneous status report of keys for public key decription (master only): rGd8a49bbcd1b1: gpg: Don't report NO_SECKEY for valid key.

This week:
Evaluate the security report.

Last two weeks:

• GnuPG
  • Fix in both of 2.2 and master
    • T4633: gpg argument "--passphrase=" yields 'missing argument for option "--passphrase="'
  • Fix in master, will be 2.2
    • rG98f4eff7ffde: card: Fix showing KDF object attribute.
    • rG858dc9564326: scd: Fix bBWI value.
    • rG996c497a864d: scd: Handle CCID bwi of time extension.
    • rG3ba091ab8c93: gpg,gpgsm: Handle pkdecrypt responses with/without NUL terminators.
    • rG15fe78184cc6: sm: Fix error checking of decryption result.
    • rGef2424144a07: sm: Support AES-256 key.
  • Fix in master
    • rG13bc0431ff1c: scd: Error code map fix for older Yubikey. <-- IMPORTANT for old Yubkey
    • For Unix, don't use gnupg_spawn_detached: rGb1c56cf9e2bb: common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr., rG044379772fc5: common: Fix the previous commit.
      • good things: gpg frontend synchronously confirms the invocation of gpg-agent/dirmngr (no race any more, if we care), less resource consumption because no double-fork
        • it was double-fork by gnupg_spawn_detached plus another fork by gpg-agent/dirmngr --daemon
      • Minor difference: gpg-agent/dirmngr could get controlling TTY again, if it opens a tty (no such code now and in future)
  • Learn pid_t and gnupg_fd_t
    • I think that I understand how it works now: someday we will need to migrate for 64-bit machine
    • A simple fix in GnuPG (it's not a total solution of migration, but a clean-up before possible migration), we don't need throw away information by masking: rGa64411c607d5: common,w32: Fix cast from gnupg_fd_t to call _open_osfhandle.

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.