Thank you for the bug report and your suggestion.

To test this you need a key with a subkey (including the primary key) that is marked for signing and authentication, but not for encryption. Open the Subkey dialog, insert an OpenPGP smart card, right-click this subkey and select Transfer to card. Select the Authentication slot when you are asked which card slot the key should be written to.

Here is the patch which will go into the next release

From f61a5ea4e0f6a80fd4b28ef0174bee77793cf070 Mon Sep 17 00:00:00 2001
From: Werner Koch <wk@gnupg.org>
Date: Tue, 22 Nov 2022 16:36:46 +0100
Subject: [PATCH] Fix an integer overflow in the CRL signature parser.

thank you, works for me.

Thank you, looks good to me.

Please use gpgme.pc to configure your build. Your options are:
(1) With Autoconf:
(1-1) Use pkg.m4 and PKG_CHECK_MODULES (which uses pkg-config to access gpgme.pc)
(1-2) Use gpgme.m4 and AM_PATH_GPGME (which uses gpgrt-config to access gpgme.pc)
(2) Or... use pkg-config to access gpgme.pc.

In T6282#165263, @werner wrote:

It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.

It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.

great hack

I updated gpgme.m4 to include configuration of GPGRT_CONFIG.
Using this new gpgme.m4, it should work.
Using this new gpgme.m4 plus old gpg-error.m4, checking GPGRT_CONFIG is duplicated.
Using this new gpgme.m4 plus new gpg-error.me, no problem.

I overlooked the use case of gpgme programming not using libgpg-error. This use case should be supported.

@aheinecke What additional information do you need ?

You need to handle them in a correct way. Just checking with gpg is
not enough because you don't know what has been signed. You need to
look at the signed data which gpg gives you by using the --output
option. And there you see only the signed data and not the extra
"aaa" you added after having signed the plaintext. It is not
different from adding stuff before the -----BEGIN PGP SIGNED ... line.

In T6272#165067, @werner wrote:

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

Thanks. There should also be SPDX indentifiers everywhere.

Fixed, to be released with Gpg4win 4.0.5.

On the command line using:
gpg -o output.txt --decrypt "yourfile.asc"

There must be something special with the message. Can you save the message to a file and use the command line to decrypt it? Is there anything special with it? Is it maybe a binary and not text? Although I tried decrypting random bytes with the notepad and it worked for me. Is the message very large? Anything unusual? Or does it even happen for you when you encrypt a short text to yourself and then decrypt it again?

fixed

Fixed

We develop many versions of pinentry, but not the one for macOS. Therefore, we cannot help you. Please contact the developers of pinentry-mac (https://github.com/GPGTools/pinentry) or the homebrew maintainer of pinentry-mac (https://formulae.brew.sh/formula/pinentry-mac).

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

Note the relationship to T4195, T4826, and T4766

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

So what should I do now? Should I report it to OpenSSH team?

We won't do that. FWIW: We started to work on a 64 bit WIndows version of GnuPG.

Fixed for master but not yet tested.

There is a utility named kbxutil which can be sued to dump the pubring.kbx file without any post-processing by gpg. I would check whether there are any other keys after the VideoLAN key. iirc, kbxutil ist not commonly installed; you may need to build the software yourself or copy the pubring.kbx to Linux and check it here.

I think there is a mixup here. I believe that you are experiencing https://dev.gnupg.org/T6192 (From 2019) which is a fairly recent regression and was discovered by our internal QA in September. As we did not get reports about this we only gave it low priority.

The first report? In history, i know, on older versions, this issue was also exist and reportet.

@gniibe: Thanks for looking into it.

I tested on the machine with:

Surely not. We just take the key from those certificates. Note that ssh-add merely imports a key permanently into gpg-agent's key store.

In order to remove the SHA-1 algorithm in Arch Linux package keyring, I need to resign one of my sub keys but the backsig (0x19) remain in SHA-1 as reported here.
I didn't find any solution with gnupg to update it since this bug report was opened in 2020. Do you plan to address this in a near future?

I don't have common.conf but I do have pubring.kbx. I meant I plan to remove that key from my keyring because it's like a decade old and expired, but I figured maybe it was somehow related to this bug since it's the last key shown, so I've left it in.

Are you using the keyboxd ? ("use-keyboxd" in common.conf) or is this using the default pubring.kbx.

Oh yes, the usual import statistics should be shown here.

Are you sure you are using SSH user certificates for SSH authentication? I have trouble with SSH certificate authentication instead of public-key authentication.

The latter. Detecting mail addresses with regexp is anyway a kludge and we have more stringent code to detect mail addresses in a user-id.

I am using this many years now without any problems. Also my collegues and many other folks I know. Thus the question is how your system differs from commonly used systems.

I have tried the stable version (2.3.8). Sadly, it doesn't work. 'agent refused operation' again. And I think it may have nothing to do with OpenSSH certificates because NIST256&384&512 keys do work in this situation.

@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.

We do not support OpenSSH certificates but ignore such requests. However, the keys from the certificates will be imported correctly. You should use the stable version of GnuPG (2.3.8) and not the LTS version 2.,2.

This is the first report we have on such a problem despite of hundred thousands of users. "Triage" means that we need to look at a report to check its priority.

@werner , why set to "needs triage"? At this moment plugin must be disabled if customer read crypted SMIME E-Mails. So it is critical. disable checkbox "SMIME" will not work correct. Enable "SMIME" will only encrypt as Text, but some E-Mails have HTML.
We have this issue on all systems (Windows 10 and Windows 11)