You need to get you toolchain correctly installed.

After randomly finding this issue I wonder: Is it possible (and does it make sense) to change the title of this bus to something like "big key causes massive CPU usage" (if I understood it all correctly)?

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.

Thanks for your reply, but it is an OPTIONAL feature. The annoying part is not deleting the files. Comparing hundreds of time stamps to ensure you are current on what you want encrypted vs. unencrypted files that are either under development and/or complete, and therefore ready for encryption. This frequently needed comparison takes a significant amount of time, and is prone to error. Any responsible user will ensure there are tested file backups to prevent catastrophic losses, or they can simply NOT use the option.

A bug was reported against this version which could happen also to older versions of GnuPG 2.2. In case of a crash please apply the patch over at rG8ec9573e57866dda5efb4677d4454161517484bc or wait for 2.2.23

See https://bugzilla.opensuse.org/show_bug.cgi?id=1176034 for the original bug report. I was not able to replicate the crash but the bad reads. The error is pretty obvious: The code expects that all fields are zeroed out.

I'm actually trying to do the following:

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.

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:

See also: T3506

I have removed that feature intentionally. There were some issues where encryption errors were not properly reported to Kleopatra and handled by Kleopatra. This could result in catastrophic data loss. I have fixed ~3 issues regarding to that and then decided that in our architecture we cannot absolutely guarantee that this never can happen and cannot happen in the future. We have resolved all the issues, but they could occur again.

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:

In T3362#137094, @werner wrote:

There is not a lot of demand for this, thus we have not continued to think about it.

@gniibe: We could implement this on the card by extending our ugly hacks on the login-data DO, which are currently:

Everything up to a LF is considered a mailbox or account name.  If
the first LF is followed by DC4 (0x14) control sequence are
expected up to the next LF.  Control sequences are separated by FS
(0x18) and consist of key=value pairs.  There are two keys defined:

 F=<flags>

 Where FLAGS is a plain hexadecimal number representing flag values.
 The lsb is here the rightmost bit.  Defined flags bits are:

   Bit 0 = CHV1 and CHV2 are not synchronized
   Bit 1 = CHV2 has been set to the default PIN of "123456"
           (this implies that bit 0 is also set).

 P=<pinpad-request>

 Where PINPAD_REQUEST is in the format of: <n> or <n>,<m>.
 N for user PIN, M for admin PIN.  If M is missing it means M=N.
 0 means to force not to use pinpad.

A new 'C' flag maybe?

There is not a lot of demand for this, thus we have not continued to think about it.

I think I am doing to try to do this on top of the work of Szabolcs Nagy[1] with the goal of making it portable, and also serving as a test cast to my carry-less multiplication intrinsic RFC[2]. Hopefully I can also remove the manual register allocation that makes it still a derivitive work of Andy, however this algorithm takes advantage of the communicative properties of carry-less multiplication, which is mult(H) on page 5 of the gcm spec[3], this communicative property works differently than with addition and multiplication in a way I do not entirely understand.

In T3362#103156, @gniibe wrote:

@werner , I understand your poiont.

So, the best approach would be:
(1) Define some DO (Data-Object) or attribute/flag per key to control timeout or "force" by the card itself.
(2) Modify scdaemon so that it always ask authentication state to the card before doing crypto operation.
(3) Modify gpg frontend so that it shows those attribute/flag and setup.

Then, it is the card itself to control timeout or "force".

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

As a workaround please run

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?

Let's continue discussion at T5040

There seems to be a problem with Gnuk and thus Nitrokey tokens with 2.2.22. We are investigating this. See T5039.

and Andy is the sole author, and he even told me personally by e-mail this
a long time ago when I was interested in the libcrypt library of glibc is .
He also licensed cryptogams for the Linux kernel (because of WireGuard)
however that did not make it into the version the version that was merged
(some of his code is already there, and IIRC includes the ghash at issue
here).

If we can use the code please first commit the original code to the repo and only then apply code style fixes.

We need to clarify two things:

So, things I see are needed to be done for inclusion of this patch are:

1. GNU C coding style fixes.
2. Adding comment about that this implementation is based on GHASH implementation by Andy Polyakov with original license. This needs to be checked with @werner , but I think following would be sufficient:

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.

I mean:

diff --git a/common/utf8conv.c b/common/utf8conv.c
index 7804dbfcd..bdab225a9 100644
--- a/common/utf8conv.c
+++ b/common/utf8conv.c
@@ -138,7 +138,7 @@ handle_iconv_error (const char *to, const char *from, int use_fallback)
          native encoding.  Nowadays this seems to be the best bet in
          case of errors from iconv or nl_langinfo.  */
       active_charset_name = "utf-8";
-      no_translation = 0;
+      no_translation = 1;
       use_iconv = 0;
     }
 }

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.