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.

Any news on this?

5 or 10 minutes are not reasonable in this case. Users are expected to attend the key generation. Your idea of having a countdown after, say 30 seconds, makes sense and should be easy to implement in the pinentries.

Thanks for explaining; this may indeed lead to a followup processing error of correct data. However, I don't expect to ever see a fixed length header of 2GiB or more because the sender would have had to buffer all that data in the first place.

Confirm gpg-error-config works... no

• Please report to https://bugs.gnupg.org with gpg-error-config-test.log

Makefile:1667: recipe for target 'gpg-error-config' failed

Please describe the problem and don't just paste compiler output.

No problem, in fact there's several issues with the cross build code, i'll report them later today.

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

After this change:

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

Thank you also for the reply, the environment / build host is Ubuntu 18.04 LTS x86-x64 GNU/Linux and target host systems are MIPS and ARM.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

Thanks for the report. It would be helpful if you can tell us your environment; in particular your build and target(host ) system.

Shall we backport this to 2.2 which is our LTS release?

It is actually used but for whatever reason only for signed and symmetric encrypted messages.

With the recent change the --sender option has an effect on the selection of the User ID used for the key validity check and the TRUST_ status lines:

Cool, thanks for fixing this!

How do I know that you've noticed?

Please don't report such things; we will notice this ourselve.

Argh, I had overlooked that you even mention a pull request.
So Apologies that I did not attribute the fix directly to you.

Thanks for the nice report. The fix was completely straightforward, I just didn't think about rich text when I implemented it.

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.

What parts of Libgcrypt 1.9 are needed? Can we consider to backport them?

Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.

MAPI Namespace has a pickFolder method which can be used here.

Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:

This was the underlying reason behind the data loss described in the wald issue.