Problem 2 comes from the fact, that gpg4win packages gpg 2.4.0, but the new archive code needs gpg 2.4.1.

works with gpgtar (GnuPG) 2.2.42-beta102, too

I could not reproduce the problem with a self-build gpg4win 4.1.1 (e5dee8abf3045c970f4ba7a0dd7ee5daf08fe7cb). Please list the content of the folder Unterordner.

Only Sign results in the same error as Sign+Encrypt (which was the picture above)

Any volunteers to write a manual? ;-)

The reason may be the following text/comment I found in gpgrt.texi:

This manual documents the Libgpg-error library application programming
interface (API). The goal is to that all functions and data types
provided by the library are explained. However, for now this is only
a stub and not very useful.

Please contact the translation team for the Chinese language. They are responsible for the translation of Kleopatra. See https://community.kde.org/KDE_Localization/zh-cn

Fixed in master and 1.10 branch.

No, it would break the verification of too many signatures.

Probably, this change should work:

diff --git a/po/zh_CN/kleopatra.po b/po/zh_CN/kleopatra.po
index 56b06e04..f34112a9 100644
--- a/po/zh_CN/kleopatra.po
+++ b/po/zh_CN/kleopatra.po
@@ -4680,7 +4680,7 @@ msgstr "发件人"
 #: src/crypto/gui/resultitemwidget.cpp:132
 #, kde-format
 msgid "Force decryption"
-msgstr "强制加密"
+msgstr "强制解密"

After testing the builds of master for several distributions/gcc/clang, applied to 1.10 branch too.

closed, as the remaining subtask is found at T6436

On gpg4win 4.1.0 (and GnuPG VSD 3.1.26) there are no longer password prompts for the subkeys when exporting (or making a backup from) secret keys.

After diligently reading the code I realized that this bug has long been fixed. For reference here is the patch I wrote to extend dirmngr_ldap during my tests:

Aborting does not result in a general error any more. Testet with 3.1.26

The flag has been implemented in 2.4 but as long as this version has no approval it does not make sense to do anything more. Let's re-open this task if we have a real request for this.

Your quick support solve my problem, I am thanking you :)
Bye bye

I added a remark to the print function. Thanks for the suggestion.

You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".

Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.

if your'e asking me, i'd suggest just let it be fixed going forward unless someone else complains

Thank you for the report.
Fixed in master. Let us consider if it will be backported to 1.10 (or not).