The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

As far as I understand the problem, all content-ids are lost during processing of an email.
This process happens during the signing/encryption of an email.

Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thank you for you responses! :)

I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.

tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.

That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

works

isn't T3456 the same issue?

my Yubikey works, too, if I disable PIV. With enabled PIV:

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.19.0.

Fixed in 1.19.0.

This problem was introduced by commit cf10c74bd9d5aa80798f1c0e23a9126f381b26b3. Perhaps that change should be backed out in the interim so that a portable fix can be considered for the original issue?

Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.

Test with GnuPG 2.4.1-beta76 failed with "error getting current key info: invalid name":

It is a bit complicated. Let me describe the situation.

Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.

I see, your issue is with the use of getrandom for FIPS. I understand now.

ENOSYS is POSIX. My point is that: getrandom was introduced in Linux kernel with flags for particular purpose (differentiate use of /dev/random and /dev/urandom), but that feature has gone.
But, for FIPS behavior, RHEL and related OS use (possibly, some would say misuse) getrandom with GRND_RANDOM. This use is RHEL specific (not for other GNU/Linux). Use of getrandom is non-POSIX.

In T6442#169419, @gniibe wrote:

Returning ENOSYS is too strict, in my opinion; It doesn't work for machines other than CentOS/Fedora/RHEL.

Returning ENOSYS is too strict, in my opinion; Because the code in question doesn't work for machines other than CentOS/Fedora/RHEL. For other machines, it would be natural to just rely on getentropy (rather standard call).

What Werner wrote was also my thought. If getrandom is mandatory for FIPS, then it must not be possible to disable it silently.

What about

Fixed in 1.47.

Fixed in libgpg-error 1.47.

Tested. I applied the above diff to libgcrypt-1.10.2, and it builds and runs.

Thank you for the report.

Here is the git diff that I used:

I just ran into this, too, on macOS.

I just ran into this issue while attempting to update the MacPorts Portfile to version 1.10.2.

Fixed in 1.10.2.

In T6388#168750, @gniibe wrote:

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.

Sorry, it took time (for me) to understand the issue, as this is not 100%-reproducible bug. And it was not clear (for me) that how passphrase were offered in the interaction, so, I was not possible to see if it's encrypted or not.

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

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.

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