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.

Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.

I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.

Mysteriously, I get nothing:

$ pkg-config --cflags nurses

Could you please check what pkg-config --cflags ncurses returns?
In my environment (of Debian), it returns:

@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.

Applied to 1.10 branch.

didn't seem to work with 1.9.x

Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.

Pushed the change.

Thanks for your confirmation.

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.

Could you please give us the build log with no --disable-asm?

(note: -O2 is added only for compiling powerpc vector implementation files)

I added check to configure.ac for missing -O flag and tests with -O2. If adding -O2 does not help, then powerpc vector implementations wont be build at all.

Thanks for report. Those powerpc vector implementations expect that compiler optimizations are enabled and here provided CFLAGS did not have '-Ox' parameter. This could be worked around by introducing -O2 always when building those files (confiugre.ac & cipher/Makefile.am change) or using 'optimize' attributes to required functions (cipher/*-ppc*.c change).

Thanks for report. I got similar report earlier this week from gentoo user through email and made following patch for them to test. I'll push it to master soon.

sorry, I'm a bit confused now and probably everything I wrote above is incorrect.

thanks for approving account.
build error happens in automatic configuration (when --enable-ppc-crypto-support is omitted from ./configure) and -mcpu=powerpc64le, -mcpu=power8 or power9 or -mpower8-vector flags are not passed to compiler.

On behalf of @gyakovlev (pending approval for his account):

[03:05:23]  <@gyakovlev>  AC_DEFINE(HAVE_COMPATIBLE_CC_PPC_ALTIVEC,1,
[03:05:23]  <@gyakovlev>         [Defined if underlying compiler supports PowerPC AltiVec/VSX/crypto intrinsics])
[03:05:34]  <@gyakovlev> they should definitely check for __POWER8_VECTOR__ 1
[03:05:44]  <@gyakovlev> it's not plain altivec
[03:06:52]  <@gyakovlev> that power check should check for __POWER8_VECTOR__
[03:06:52]  <@gyakovlev> not only for what they check already.
[03:08:59]  <@gyakovlev> it probably should be checked after __powerpc64__ or instead of it.

You could use --disable-keyboxd which should fix this. However, there will eventually be no more way to build w/o Sqlite and thus I would suggest not to allow disabling of sqlite.

PS I forgot to say why movement to cmake will be the best way.

I totally disagree.

Please read libgpg-error's README. For each architecture we need to have a dedicated config file - this has nothing to do with autotools. Big and little endian variants are obviously different architectures. Here is an excerpt from the README

Hello @wener, I want to say that libgpg-error is the only one (!) application that fails to cross compile using valid toolchains: "armeb-unknown-linux-gnueabi" and "aarch64_be-unknown-linux-gnu". It compiles and runs perfectly using "arm-unknown-linux-gnueabi" and "aarch64-unknown-linux-gnu", but fails with big endian. I see project are actually using "hton/ntoh" so we shouldn't see this error. What this problem is about?

For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches

Good that it works again for you.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...