While I see that it's not the matter of actual use case (but how gpg can be immune to fuzzing), code clean up would be good here.

Thanks for the patch.
I see your point in T4975: undefined-shift in block_filter.
You are right that we have a problem of possible overflow (which could be kicked by fuzzing) here.
(The actual impact would be small, though).

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

Or this (don't allow anon keys for different usage):

diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c
index 14cbdbb0f..b8d4059cd 100644
--- a/g10/pubkey-enc.c
+++ b/g10/pubkey-enc.c
@@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek)
       if (err)
         break;

Do you mean something like this?

Fixed in rM1b840a151ad7: python: Fix how to generate documentation..

It's in master (to be gnupg 2.3).
Enjoy.

It seems that nl_langinfo(CODESET) returns US-ASCII on your system.

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

When I test it on Debian, disabling by,

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent

Pushed to master as rGa763bb2580b0: gpg,agent: Support Ed448 signing..

Update to [rGc94eea15d}.
Hash defaults to SHA512.

(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data

Update to rG4bdade5b0bea: agent: Use get_pk_algo_from_key.

The changes just follow the existing practice of Ed25519, which does:

Changes pushed to master.

Pushed the patch to master.

It's me who should say "thank you".

Or one liner patch would be enough:

IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.

Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.

Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.

Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.

I was wrong. This patch itself doesn't require libgcrypt 1.9. It works with libgcrypt 1.8 well.

I think that the changes for ECC I've done matters:
o rC050e0b4accfa: pubkey: Support a method to get data as an opaque MPI.
o rC05a7d2f262bc: ecc: Support an opaque MPI handling in mpi_from_keyparam.
rC3d5a05767b84: ecc: Fix handling of point representation in EdDSA.
o rC8fce1027c253: ecc: Return an opaque MPI by _gcry_ecc_ec2os.
rC35c1faaea2b0: ecc: String constant fix.
rCad8927f40169: ecc: Simplify _gcry_ecc_compute_public.
o rCc5a7191c1bd1: ecc: Use opaque MPI for _gcry_ecc_mul_point.
rCbbe15758c893: ecc: Fix _gcry_ecc_mont_decodepoint for data by old implementation.
rC27e848666b4a: ecc: ECDH clean up for use of ec->nbits.
rC82441bbb8290: ecc: Fix key generation for ECDH.
rC6d93812aa312: ecc: Fix debug output.
rC6a30a9a2cc48: ecc: Simplify using mpi_ec_t directly.
rC975de3879691: ecc: Fix for NBITS support.
rCe921ad5b3ad0: ecc: Add NAME member to struct mpi_ec_ctx_s.
rC488704be6e04: ecc: Add key generation support to mpi_ec_get_elliptic_curve.
rC5415bc578080: ecc: Consolidate with _gcry_mpi_ec_internal_new.
rCc2aa333dd88b: ecc: Support flags and debug print in _gcry_mpi_ec_internal_new.
rCc7b97ac9bdf9: ecc: Add new function _gcry_mpi_ec_internal_new.
rC10b8cc280a53: ecc: Simplify ecc_encrypt_raw and ecc_decrypt_raw.
rC61a051828253: ecc: More fixes for cofactor with PUBKEY_FLAG_PARAM.
rCa258ae728de6: ecc: Simply use unsigned int for cofactor, not MPI.
rC579d5d6017d6: ecc: Simplify compute_keygrip.
rC95cc9b8f4483: ecc: Clean up key generation code.
o rCff0f1782560e: ecc: Handle ephemeral key as opaque octets.
rC80cf289905ac: ecc: Consolidate encoding a point for Montgomery curve.
rCba0b31f26366: ecc: More clean-up for Ed25519 and Curve25519.
rCd66a4856eb0c: ecc: Fix hard-coded value for 25519 to allow other modern curves.