Implemented in master.

It looks good.

With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

Fixed and backported.

Err.. Just removing the check may be the correct fix; It doesn't make sense to limit capability here.

I think rGe573e6188dad: gpg: Fix --default-key checks. should be fixed as:

diff --git a/g10/getkey.c b/g10/getkey.c
index ad5dd8e01..cc908964e 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1860,7 +1860,8 @@ parse_def_secret_key (ctrl_t ctrl)
           PKT_public_key *pk = node->pkt->pkt.public_key;

rGe573e6188dad: gpg: Fix --default-key checks. is suspicious.

Last week:

• gpg: use "SCD KEYINFO --list=auth" for ssh access (1)
  • SSH access change
  • GETATTR by KEYGRIP
  • READKEY by KEYGRIP

This week:

• [DONE] gpg: use "SCD KEYINFO --list=auth" for ssh access (2)
  • Don't use $AUTHKEYID anymore
• Check use case of $ENCRKEYID (other than keygen)
• Do same for $SIGNKEYID

$AUTHKEYID use cases have been removed.

The particular part of mkheader compilation with -O0 was introduced by dkg for cross build support.
I believe that -O<number> (where <number> is not zero) is common but -O<something-other> is dependent.
Requesting non-optimization by -O0 seems GCC specific.
(I grep-ped autoconf-archive and observed the use cases of -O0.)

Last week: Basically off

Last week:

• Chopstx USB driver for GD32VF103
  • in the master branch of Chopstx

Considering the concrete use case(s), it is more rational to support listing by capability.

Last week:

• Recover from cold (which I got when I visited elementary school)
• accounting for my business
• a fix of nPth for corner cases
  • On GNU/Linux, only expose npth_rwlock* API when __USE_UNIX98 or __USE_XOPEN2K, because PTHREAD_RWLOCK_* is only available in this condition.

This week:

• Investigate remaining SERIALNO issue for scdaemon: T4695: Remove SERIALNO as an identifier to select keys
• Set up my test environment for:
  • Scute with Yubikey using PIV
    • Are there any site for testing this? Shall we have a page for testing X.509 client certificate authentication?
• USB driver for GD32VF103

Todays topic from me:

• T4772: Release libgpg-error 1.37
• T4659: Release Pinentry-1.1.1
• T4294: Release Libgcrypt 1.9.0

Last week:

• Chasing a bug in: T4256: gpg-agent: Spurious pinentries for an already unlocked key when decryption OpenPGP in 10 threads
  • If gpg-agent's option auto-expand-secmem can dismiss the pinentry pop-up, my analysis is correct
  • fundamentally, the total fix may be possible by serializing cryptographic operations
    • simple way is only one operation at most
    • ideally, multiple operations at once by measuring amount of available resource
• scan the tasks: Mostly for pinentry and libgpg-error to consolidate common things
  • those are not high priority, though
• confirmed that: on GD32VF103
  • USART and SPI are as same as GD32F103/STM32F103
  • USB is different, it's like STM32F105

This week:

• scan the tasks
• write an invoice to g10code
• considering a proposal (2020) to Purism
  • Fully Free (PCB design, firmware) USB Keyboard
  • If it is OK, use of GD32VF103 (RISC-V) would be good

In 2.2.18, this fix is not included. (partial fix was reverted)