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

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

works in 3.1.27.0-beta44

This has been solved loooong ago.

Actually this is about improving an error message.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

works in gnupg24.

I'd say yes.

Thank you for the bug report.

@gniibe: Would you mind to look at this?

README and INSTALL now suggest to to use a build directory.

Error checking of the parameter file is usually enhanced when adding new features. Keeping this task open for this specific request does not make sense,

Fixed.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

That is not a bug but required for backward compatibility. See me/ksba.m4:

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

This isn't a support forum. You'd better ask on the gnupg-users mailing list before assuming that you found a bug.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

I agree. Something called READ... shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)