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

That is just one bit different - Shouldn't we better have a wrapper as we used to do for other things?

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.

The next version will fix the wrong warning and also allow for an empty value.

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.

Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.

Setting to resolved as discussed with Werner

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

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.