Small correction: The fixed byte I talked about may have the values 1, 2, 3, or 4.

Unfortunately you can't pass extra arguments.

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

This has CVE-2020-25125

2.2.23 has been released and announced.

The fix will be in the 2.2.23 release (T5045).

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.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

To implement this it would be best to have an gpg_strerror variant which does not call dgettext.

re 1: Correct utf-8 truncation would be quite some work. In this case the message is in the Assuan interface is a debugging aid. Translation is not necessary so we can try to disable it.

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.