Thanks !

A real fix will be in the next gpgrt release

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

This has been fixed some time ago when the UI for generating OpenPGP keys was rewritten.

In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)

works

Actually we should switch from putenv to SetEnvironmentVariable et al. because that avoids problems wit different Windows libc versions, for example in DLLs.

Fixed in rG8e8971403f75: w32: Fix gnupg_unsetenv..

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Well, the modern way, recommended by the FSFE, for license notices in source files is SPDX instead of verbose license notices. https://reuse.software/

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

works

This is now ready for testing.

You are using the basic pinnentry which comes as part of the basic installer. Almost everyone does not use this but Gpg4win which has a real pinentry. See http://gpg4win.org You don;t need the program statement then because gpg is installed in the PATH.

Sorry, it looks like no problem.

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