Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.19.0.

Fixed in 1.19.0.

Fixed in 1.19.0.

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

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.

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).

Fixed in 1.47.

Fixed in libgcrypt 1.10.2.

@debohman Thank you!

＠debohman Thank you for the log. Thank you also for your testing pinentry master.

Fixed in libgpg-error 1.47.

Possibly, your problem may be gpg-error.m4 in pinentry. If so, you can replace m4/gpg-error.m4 in pinentry by src/gpg-error.m4 in libgpg-error.
Then, regenerate configure of pinentry.
(In the repo of pinentry gpg-error.m4 is already updated.)

@debohman Please describe your failure.

The functionality of gpg-error-config is replaced by gpgrt-config. However, the script of gpg-error-config itself cannot be replaced by gpgrt-config.
(As the output of configure said,) in the configure script, gpgrt-config is invoked with --libdir somewhere (/usr/local/lib/x86_64-linux-gnu, in my case above) option to work as the gpg-error-config script replacement.

Thank you for the report.

Please see T6444.

Please describe your problem in a way other people can reproduce.

Fixed in 1.10.2.

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.

Fixed in master and 1.10 branch.

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.

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

@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:

Pushed the change.

Having GPG_ERR_BAD_PUK makes sense. So, I added a tag for gpg-error.

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

Thank you for the bug report.

gpg-agent now supports READKEY --card command which creates stub file when it's not yet available on host computer.
It was implemented by rG82cbab906a3e: agent: Add --card option for READKEY.

Thank you.
Applied to both (master and 1.10).

Applied your patch (from gitlab) to both (master and 1.10).

Applied to both (1.10 and master).

You are right, there is no way to use DRBG with SHA384 by libgcrypt.

Applied to both (1.10 and master).

Applied to both (of 1.10 and master).

Note that for the OpenPGP implementations which use X25519 API, it is not possible to calculate [scalar]G with scalar having least significant three bits != 0.

CV25519 private key secret part:

• Standard MPI (big-endian) of 255-bit
• The value should have zeros for least significant three bits, its most significant bit (255th bit) should be set.
  • the value should be the one after decodeScalar25519 function in RFC7748

CV25519 public part from secret part:

• Simply calculated by [secret-part]G