Did you remove .gnupg entirely? Secret keys are stored in .gnupg/private-keys-v1.d. If it remained, you didn't import your secret keys.
If it was the case, I'd like to merge this report to T3391: cannot import subkey that was once marked to be on a card.

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

The "Reliability History" says (in Chinese):

异常代码: c0000005
异常偏移: 0002b6c0

The error code c0000005 is something like SEGV on POSIX, I guess.
It occurred at the address 0002b6c0.

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.

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

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)

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.

With Debian's GnuPG 2.2.12, I got an error:

With bata1449, I cannot reproduce it.
I can import by gpg --import key-uids-sec.pgp
I tested with Debian's libgcrypt, as well as libgcrypt master (4a50c6b8).

Thanks for the info and my apologies for the regression. Please see my comment on T5045.

Pushed the change.

I am facing a really similar problem currently in version 3.1.13 (on windows 10)
Although the self-test shows all checks passed. I found out that there is an issue with the cache dir file not being created/loaded.
See:

IIUC, fix can be like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 996c3b0f..646bbc60 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -147,7 +147,12 @@ class GpgmeWrapper(object):
                     gpgme.gpg_raise_callback_exception(slf)
                 return result

The action to switch to the "Smartcard management" still lacks an icon. In the old KDE icon theme Oxygen there was an icon ("secure-card"), but the new Breeze icon theme lacks this icon. I have requested an icon for this for the Breeze theme. See https://bugs.kde.org/show_bug.cgi?id=428278.

My sks keyserver is in Linux Ubuntu 18.04 LTS. As a client I'm using windows 10 and gpg4win is 3.1.13.

Hmm, interesting. I'm using the Back button all of the time to get back to the certificate list from the smartcard manager. Might be a Windows-only bug.

Are you on Windows or Linux? What version of Kleopatra or Gpg4win are you using?

See also T5098 - I am sorry for this regression. We are working on a fix.

Which version of Gpg4win did you install, from where, and which OS version are you using? Why did you install gpg4win at a non-default location?

Please ask your distribution . What I see here is a problem with the packaging of a dedicated build system. This is not the build system which comes with GnuPG. Feel free to reopen if you can show that this is a native gnupg build problem.

Hi Zetrick,

Hi Zetrick,

Perhaps, don't allow automatic use of available card keys would be better:

diff --git a/agent/command.c b/agent/command.c
index 160979dae..b6286becf 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2292,13 +2292,7 @@ cmd_scd (assuan_context_t ctx, char *line)
       if ((argc == 1 && !strcmp (argv[0], "SERIALNO"))
           || (argc == 2
               && !strcmp (argv[0], "GETINFO")
-              && !strcmp (argv[1], "version"))
-          || (argc == 2
-              && !strcmp (argv[0], "GETATTR")
-              && !strcmp (argv[1], "KEY-FPR"))
-          || (argc == 2
-              && !strcmp (argv[0], "KEYINFO")
-              && !strcmp (argv[1], "--list=encr")))
+              && !strcmp (argv[1], "version")))
         xfree (l);
       else
         {

This is due to access control for "extra" socket.
Fixed in T5062: gpg: error getting version from 'scdaemon': Forbidden.

Hi all, I have this issue in Win10 in correct installation. Si I am interested what can I do to repair this issue. GPG is working correctly, but Kleopatra's selfcheck show this issue. Thanks. Portug

OK I found a very interesting thing here, @werner and finally I can reproduce this problem:

That is a version of gpg4win which we don't support or even know about. Please ask at their support site. Sorry.

Thanks for the report. Indeed, the convenient C99 feature of variable definition in a for statement does only work in recent gcc versions and thus it should not be used in GnuPG related code. (https://gnupg.org/faq/HACKING.html was out of sync with the version in gnupg's master repo which falsely stated that it is an allowed features.)

The name field is marked as optional but it is mandatory. This should be fixed.

Thinking that maybe the gcc version is too old I tried using instead CentOS gcc7 development environment (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) (which doesn't come out of the box). This was an educated guess as c99 is only partially supported in gcc-4.8.5. I have now successfully built:
libgpg-error-1.39
libassuan-2.5.3
gpgme-1.14.0
using gcc 7.3.1. All make check tests have passed.

The json problem can be overcome by changing the configure line to:

Actually I don't use systemd unit to start gpg-agent (creating that service file in systemd and make it start automatically) but I run it manually within the script. Also the script has selfcheck not to run multiple gpg-agent like below:

We encountered the same issue today, and below is the debug messages. It works as expected once we downgraded to 2.2.21. We're on Arch Linux.

Version 2 is a bit too unspecific. Which version of what software are you using. Which OS?

Good catch. Thank you.

Hi,
I corrected all the accents. I created a PR here https://github.com/gpg/gpg4win/pull/3

Any ideas? Is there any other info needed that could help move this along?

There is a conflict between the systemd based launching of gpg-agent and gpg's own launching of the agent. Further systemd seems to remove the /run/user/UID directory which unlinks gpg-agent's socket. gpg-agent's self-check notices this after a minute and termintates itself.

I think that rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixes this issue.

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

Great, thank you @gniibe.

Thanks for your report.