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

I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)

• with SoftHSM https://github.com/opendnssec/SoftHSMv2
• with Scute

I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.

Sorry, I mistakenly closed this task. I reopen it.

Could it be the case that your implementation actually used those bits to calculate a public key?

For a device which only provides PKCS#11 driver, I decide to test with SoftHSM.

Current status:

• Gnuk Token, Yubikey, OpenPGPcard with some card readers (only w/ specific reliable card readers)
• some cards some card readers (many are not supported well)
• TPM

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

The interaction goes back to "Your decision?" after you didn't answer "y/N" to the question of "Do you really...?".
What you are asked is: 1, 2, 3, 4, 5 or m.

Some technical points: