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.

Update found out the answer for this mystery but I need to know why from you guys:

With all respect. Should I wait for a follow-up or I should consider this case as closed?

With 2.3 we add the keyboxd which uses sqlite (and thus indices) as database. This makes lookups much much faster and avoids problems with several processes accessing the pubring.kbx. If you want to try this you can do so with 2.3:

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

That code in gnupg has not been touched in a very long time so this may be caused by some side effect.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

Currently, yes. After some testing, I'll backport it to 2.2.