The following patch works.

I use this for testing:

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

There are multiple problems described in your report. Let us handle one by one.

Thank you for your quick testing.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

On March 11 and 18, the private key file DE1AB1D22899CEC7DBB1A7863F34E6E92BFB7756.key was wrong.
I updated on March 25. Now, the endian is GnuPG (d is big endian).

Thank you for the reminder. I will update the version in configure.ac for AM_GNU_GETTEXT_VERSION, when I will confirm other developers' emvironment.

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

I extracted data from https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02 and compose x25519 key and MLKEM768 key. Here they are.
x25519 :

This rejection could be relaxed.

As a first experiment, let us use CIPHERTEXT in the format of (enc-val(ecdh(s%m)(e%m)(k%m))) (s: encrypted-session-key, e: ecc ephemeral key, k: kyber ephemeral key).

Applied to both (master and 1.10 branch).

Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.

Apply the change in: rPTH417abd56fd7b: Fix INSERT_EXPOSE_RWLOCK_API for musl C library.

It looks like hardware problem or card reader problem.
Please test with debug-ccid-driver line in scdaemon.conf to see lower-lever (driver debug) message.

Since I don't like to introduce hppa specific workaround in a way like pragma (and I have no time to fix compiler itself), I tried to improve the ec-nist.c for hppa so that register pressure can be lower.
Here is my solution.

@thesamesam Thank you for the report.

Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.

Alternatively (more narrow workaround), when I add a line:

#pragma GCC optimize("O1")

before the function _gcry_mpi_ec_nist256_mod in mpi/ec-nist.c, it works for me on panama.debian.net (Debian porterbox for hppa).

Fixed in libksba 1.6.6.

Fixed in npth 1.7.

You can get more information by applying a patch below (and also tests/json/Makefile.in):

diff --git a/tests/json/Makefile.am b/tests/json/Makefile.am
index 90fba79e..7523bb6b 100644
--- a/tests/json/Makefile.am
+++ b/tests/json/Makefile.am
@@ -106,6 +106,8 @@ gpg-agent.conf:
 # a key from a smartcard reader (error might be: Unusable secret key)
 	echo pinentry-program $(abs_srcdir)/../gpg/pinentry > ./gpg-agent.conf
 	echo disable-scdaemon >> ./gpg-agent.conf
+	echo debug-all >> ./gpg-agent.conf
+	echo log-file /tmp/gpg-agent-logfile.log >> ./gpg-agent.conf

T4820 is not related (it's a failure of t-keylist-secret in t-json), while this is failure of t-decrypt.

It looks like computation for NIST P-256 failed on hppa (32-bit big-endian, actually running on 64-bit machine, IIUC).
powerpc is similar (32-bit big-endian, actually running on 64-bit machine), but no failures.

This is a group of tasks of dirmngr and gpgsm.

I was wrong for the semantics of proxy->outtoken. It is zero when run_proxy_connect is called and enabled during the negotiation.

@hlein Thanks a lot for quick testing.

IIUC, the code for keep_alive is for negotiation of proxy. If so, something like this is the fix:

Right. I was wrong assuming the code in 2.2 branch is stable (that is: well tested).

Thank you for the report. There was a problem in: rG845d5e61d8e1: dirmngr: Cleanup the http module.
Pushed the fix in: rG04cbc3074aa9: dirmngr: Fix proxy with TLS.

In master, I applied changes for include files which don't harm current target of MinGW-64.

It's true that under $GNUPGHOME (~/.gnupg/), there are multiple things: configuration files, user-specific data files (private keys, public keys, the trust database, and revocation certificates), user-specific state files (like the lock files and random seed), possibly runtime sockets, and executable/script for card reader. Some careful handling might be needed for making backup and doing version control for that.

Thank you, applied.

Applied the change. I write the ChangeLog entry by commit message.

Thank you for the fix. Pushed the change modifying the commit log for the ChangeLog entry.

I'm afraid that your particular configuration would cause the problem of the negotiation.