Note that if you run into problems with a smartcard you should run "gpg --card-status" once. GUI frontends usually do that and this is the reason why this regression was not detected. Will be fixed in 2.2.25 (T5140).

As @dkg noted T4592 is a duplicate of this and given that we have a mitigation in place we can also close this (older) bug.

Before step 2.d you should stop gpg-agent and other daemon

This was fixed in 2.2.24 with commit rG7f765a98fd662

If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

I looked the gpg-agent.log, it indeed suggested the problem fixed in rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN., which is included in 2.2.24.

Building and installing 2.2.24 at least made it not crash, the very least it's an improvement in that respect.

You have multiple readers and using PC/SC by specifying reader-port.
We fixed in master by T4998: scdaemon: PC/SC "No such device" without reader-port, and I didn't know similar fixes should be backported.
I will soon.

The problem seems to have returned in 2.2.24.

Thanks again for your report.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

It was a bunch or work and we are still not able to pass Unicode strings on the command line. Will eventually be done. At least people in Asia can now use their regular Windows account with gpg.

Thanks Werner! Seems like an important step!

Need another patch to export it:

diff --git a/g10/export.c b/g10/export.c
index 8dd0b07d7..339424e19 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -627,6 +627,57 @@ canon_pk_algo (enum gcry_pk_algos algo)
 }

I reconsidered this. Suppressing such messages with --quiet is oka and will be in 2.2.24.

For SPR532, we need following.

I'm pretty sure what happens, but apparently I haven't been able to explain it clear enough. To reproduce you can do like this:

1. On an old machine having GnuPG version 1, e.g. Red Hat Enterprise 5:
   1. gpg --homedir $PWD/homedir --gen-key
   2. tar cf homedir.tar homedir/pubring.gpg homedir/secring.gpg
2. On a more modern machine having GnuPG version 2, e.g. Red Hat Enterprise 8:
   1. tar xf homedir.tar
   2. touch apa bepa
   3. gpg --homedir $PWD/homedir --sign apa # Does the migration, and signs "apa"
   4. mv homedir homedir.moved # Don't remove, just move
   5. tar xf homedir.tar
   6. gpg --homedir $PWD/homedir --sign bepa # This will fail as explaine in point 5 of the initial description

The inotify thing is only used to detect a deleted homedir and stop the agent. AFAIU your problem is that a migration is triggered again. The migration status is a file ~/.gnupg/.gpg-v21-migrated - are you sure that you have extracted it again?

Applying following SOS-handling, the key can be handled.

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 9cb254e24..be7fc6d67 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -188,6 +188,76 @@ mpi_read (iobuf_t inp, unsigned int *ret_nread, int secure)
 }

Note that there is no problem for encrypted key, because it is handled by opaque MPI.

The whole TOFU stuff hash not yet been fully translated because there are conceptional problems with the way the code works.

FWIW, --enforce-passphrase-constraints does already work for symmetric-only encryption since 2.2.21 (rGae8b88c635424ef3). Thus this bug is actually a feature request to have a separate set of passphrase constraints option for symmetric-only mode.

No, overlapped I/O is not used. OVL is just a zeroed out memory area and thus hHandle is NULL. Errors are of course checked.

One bug is fixed in rGdd4fb1c8f668: gpg: Fix first zero-byte case for SOS handling..

Fixed in 2.2 branch.
Also, I found another issue of libgcrypt master, which is fixed in rC361a0588489c: ecc: Handle removed zeros at the beginning for Ed25519..
Further, I found different issue, and created T5116: GnuPG master shows an error when importing Ed25519 keys generated.

I think that it may occur with eddsa secret keys generated with 2.2, too. (In the 50% probability)

Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093

I recall that I had the same bug during development. Must have slipped in again - Good catch.

I have added support for this to gpgme (and gpgme++/qgpgme). See T5094.

By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584

I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."

I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.

On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.

I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.

In short eddsa secret keys generated with current 2.3 can't be imported with 2.2, right? That will lead to a compatibility problem, so we need to fix that in 2.2.

IIUC, it is an issue of GnuPG 2.2.
The condition is where the secret 'd' starts by the first bit = 1 (that is, >= 0x80).
I located the bug in agent/cvt-openpgp.c. The function do_unprotect calls convert_secret_key with skey[1] as usual MPI (not opaque),
and gcry_sexp_build with "(d%m)" will put additional 0x00 at the beginning, which results 33-byte secret in R_KEY. Then, when gcry_pk_testkey is called with R_KEY, when it checks, because 32-byte is expected, it returns GPG_ERR_INV_OBJ. Then, do_unprotect returns GPG_ERR_BAD_PASSPHRASE.

The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.

I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.

Minor remark: I would change this (in the documentation) to

gpg --quick-revoke-sig fpr fpr-of-signing-key [names]

as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).

SCD commands:

• DEVINFO
  • returns app apecific serialno
• SERIALNO
  • returns app specific serialno
• LEARN
  • returns canonical serialno

Backported to 2.2. Note that an updated libgcrypt is also required (for 2.2 and master)

For the Debian problem it might be better to use "gpgconf --launch" and we add an option here to wait for the daemon to be started. That can be implemented in gpg-connect-agent which then should get the same option.

Frankly, I do not like this change - in particulalr not for the stable branch. Having a timeout on connections is actually a Good Thing and better than to wait indefinitely. There is a high risk on regressions and that is not acceptable for the stable branch. The branch already had a couple of regressions in 2.2.2x and we need to fix them and not introduce others.

All right, using the current master a Windows user with a Unicode name (e.g. Ⓐlfred E. Neumann) is now able to use gpg properly. Quite a lot of changes were required and backported to 2.2 will also be some work. More testing is of course required. Note that libassuan needs to be taken from Git until we have done a new release.

I created this patch D509: Yubikey supports two (or more) apps, serial number problem.

But changing just the displayed S/N should not disturb anything.

No, the above patch makes OpenPGP app stop working.

(I don't know well about Yubikey specific serial number.)

Thanks for the quick analysis.