Thanks for your info.

Or your card has the key to certify and its fingerprint is: CB522FE0379DDF40A93400D7E4BC91FACDA9A65B

Simply, we need the output of gpg --card-status to identify which key is on your card.

Please show us your card information. Does it have unrelated signing key?

With the fix of T4623, this bug is now fixed.

Fixed in master, using Libs.private support.

Fixed in master.

Documentation for the regular expression of Jim Tcl: http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_jim_built_in_regular_expressions

Created gniibe/regexp branch.

RFC4880 (and older version of RFC2440) referes Henry Spenser's REGEXP. There are three implementations: https://garyhouston.github.io/regex/

Or, #5 would be:

@Amaud, I read your code in Python. IIUC, it asks users PW1, Reset Code, and PW3 to setup, just before registering KDF DO (as you describe in https://dev.gnupg.org/T3891#114950).

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

Thanks for concrete cases. Sorry, not responding earlier. It was an experimental feature, firstly only available in Gnuk Token.

On Solaris, the test errors are because of:

USAGE
       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}
       privilege.

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

Thanks. I see the situation for Solaris 11 Openindiana. In master (will be 1.9.0), it has no problem.
We need to fix in 1.8. I will.

Please give us log for Solaris 11 Openindiana.

I think that this ticket and https://bugs.debian.org/346241 handle different things, although both do key selection.

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;

$ export GNUPGHOME=<somewhere>
# Create a key with "C"-only capability
$ gpg --quick-gen-key "test-user <chuji@gniibe.org>" ed25519 cert
# Create another key (or get/import it)
$ gpg --quick-gen-key "2020-user <chuji2020@gniibe.org>" ed25519
# Sign with the first key to the second key with --default-key
$ gpg --default-key 7694AB44DED1154CEB981059B0B36418AF85C918 --lsign 72FF31542DB059A507BAF81BE05523DEB4B018E6

(where 7694AB...85C918 is the first key and 72FF31..B018E6 is the second key)

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

$AUTHKEYID use cases have been removed.