@leder I agree that it is useful if OpenPGP public key can be (directly or indirectly) retrieved from a card.

One more idea: It is a riddle to me why I can configure keyserver http://pool.sks-keyservers.net/ and then do a --search-keys, but it is impossible to do --receive-keys with the following error:

Thank you, gniibe!

I have run the DbgView test twice, I don't know if there is the data you need.

Please note that your private keys are on your card, together with finger print information. But there is no place to have OpenPGP public keys on the card. I guess that this is a possible cause of confusion.

Now I am even more confused! This is key No. 1 - the number on the keyserver w/ --search-keys:

On an OpenPGP card the key no 1 (OPENPGP.1) is a sign-only key - you can't use it for decryption even if you somehow managed to encrypt to that key. That restriction is enforced by the card.

thanks for the report. Between Gpg4win-3.1.12 and Gpg4win-3.1.11 KF5ConfigWidgets was indeed updated so your report might point to a regression in that library.

Hello Werner,

Your problem seems to be that you don't have a copy of your public key anymore. The uni-mainz keyserver might be configured not to return expired keys (if I read the output above correctly). I was able to to retrieve your key using the standard pool (in particular from the server sks.pod02.fleetstreetops.com). The key is expired but that does hinder you to decrypt. Run "gpg --card-status" once tomake sure a stub file is available.

Now I changed the gpg2 keyserver and can see my public keys on the public key server:

The following patch make it work:

Thanks for your information. No debug output any more, as I already figured out things.

In case of Ed25519 certificate signed by Ed25519 key with only few names and flags it seems to be just below 500 bytes. This could of course grow if names are added or larger public key is being signed.

You need to get you toolchain correctly installed.

Well, from the viewpoint of card specification, "a message M of arbitrary size" for Ed25519/Ed448 in RFC8032 is not good, because card has a limit for buffer size and the protocol in the OpenPGP card specification requires the steps of (1) the message M is buffered and then (2) the compute the signature.

It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.

Hi,
I have tested a GnuPG Token with Gpg4win-3.1.12 and generating a key with Kleopatra did not work
With 2.2.23-beta4 that contains: 0a9665187a7cbf68933b7162fb5f974177684a50 I have repeated the test on Linux and first the key-attr change that Kleopatra sends fails:

I just confirmed that Gnuk has a limitation for the input length is less than or equals to 256.
So, this is the issue of Gnuk, not GnuPG (or at least, Gnuk has the problem).

Please show us concrete example of debug output by scdaemon, when you run ssh-keygen.
You can have a setup in .gnupg/scdaemon.conf like:

I've meant scdaemon rather than OpenSC. I'll correct the descritpion.

gpg-agent has only very limited support for ssh certificates which is the reason that your command fails.

I should add a test with Gnuk to my Windows quick test after a release.

Thanks a lot. Applied and pushed.

I can confirm that the patch seems to resolve the issue for me.

I think that following patch can solve the issue:

Yes, I do have a signing key (that is distinct from the primary key, primary key I don't store on the smartcard).

Ah, I see the situation of the regression.
When the token is not yet accessed at all, scdaemon misunderstood as no signing key.

Do you have a signing key in your card or not?

FWIW, here an example of warnings we use. Yes it starts with -Wall but there are a couple of more specific warnings and at a few places we even use pragmas to disable warnings. And it depends on the compiler version used.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and >warnings we ignore with gcc.

Hmm. Now, even with a fresh session, dirmngr, GNUPGHOME not set, etc. it seems to work. It correctly uses the config file and the keyserver, and the logs show the Home and Config variables are set and communicated correctly.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and warnings we ignore with gcc.

I found the bug by compiling the package with C/C++ compiler clang and flag -Wall.

Fixed in gnupg and gpgme. it is not serious because that is just a failsafe check; libksba creates these strings and it does it correctly.

We have the same flaw in gnupg.

I think we should make zlib a mandatory dependency.

In T4977: dirmngr not working with linux kernel parameter ipv6.disable=1, EAFNOSUPPORT fix was applied in 2.2.22.
I think that original problem in this report is fixed.
Please test with 2.2.22.

Actually, configure already has the check.
If it's really needed to build without zlib, you can use this patch:

From 76920ac034490e4860ad6abe9891e3b1c0813363 Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka <gniibe@fsij.org>
Date: Fri, 28 Aug 2020 11:02:13 +0900
Subject: [PATCH] Until compression is implemented, build with no ZLIB can be
 done.

Thanks. Applied to 2.2 and master.

Was easier to fix than expected. Thanks for the report. Fix goes into 2.2.22.

[These damned typos in commit messages ;-)]

The keyserver options control how gpg imports or exports keys to the keyservers. Thus they indeed belong into gpg.conf.

I have a couple of keyserver-options statements in there, but no keyserver statement. Should the options be located in the dirmngr.conf file instead?

I guess you have a keyserver statement in your gpg.conf.
By using

What is the current encoding? OEMCP ?

So if gnupg version >= 2.2.22 Kleopatra needs to convert the passed filenames to UTF-8 and pass them with the --utf8-strings option to gpgtar. This needs to be changed in Kleo. -> Assigned to me.

Done for master and 2.2.22 - libgpg-error 1.39 (not yet released) is required for the actual fix.

Fixed for 2.2.22

Thanks for reporting. Fixed for 2.2.22. repeat==0 works like before and repeat>1 also (that is several passphrase pinentries will pop up).

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.

If you use

Just reading this issue in detail.

It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.