Thanks, that patch works for me.

Thank you!

Applied to both (master and 1.10 branch).

Looks good to me. __CLOBBER_CC is needed as PA-RISC has carry/borrow bits in status register for add/sub instructions.

In 2.4 we have rG1383aa475 which does

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

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.

No, thank you both for the speedy responses :)

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

Ah, thanks Werner, I'll keep that in mind.

No, hardware barrier is not needed here. Compiler barrier is used here to prevent optimization removing mask generation and usage in following constant-time code.

Clarification from Dave:

Thanks, I can confirm that this patch fixes the issue. I'll let Sam decide if this is how we want to handle it downstream or wait for confirmation from gcc.

Although I don't think this is the case here one should be aware that tests mail fail due to global configuration of GnuPG (/etc/gnupg/*.conf). There is no easy way so solve this except for running a per-test local installation of GnuPG using the gpgconf.ctl feature.

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.

It seems to pass for me with gnupg-2.2.41 but fails with gnupg-2.2.42?

Fixed in 2.4.4.

There should not be an exception "Invalid crypto engine" in that call. I expect that gnupg errors out immediately if the parameter with tofu is given while instead it should print a warning and show no information. Or of it errors then Invalid Crypto Engine is definitely the wrong error for that.

I did this locally:

--- a/lang/python/tests/support.py
+++ b/lang/python/tests/support.py
@@ -46,13 +46,15 @@ def is_gpg_version(version):

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.

Thanks. Wouldn't that require OpenLDAP on every system with gnupg?

We should make building with LDAP mandatory.

Thank you for your report.

Fixed in 1.10.2.