That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.

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

You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.

Switching to assembly for the shifts made a significant speed-up. As Minicloud is seemingly broken (can't open up ssh port) I cannot test on 64-bit big-endian or 32-bit and have thus made it 64le-only.

Changes pushed to master.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

Pushed the patch to master.

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

Yes, i always build it with PKG_CONFIG_SYSROOT_DIR but never had any issues with it until 1.38 version, your suggestion definitely fixed it. 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.

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.