There is a message telling you what is missing. Thus I can not consider this a bug. There are just too many dependencies which are required for cross-compiling that the README can only tell about those which we don't expect to be installed on a developer's box.

They are mandatory for gnupg but not for Libgcrypt and Libgpg-error. I guess we can fix that.

This does not look like a bug report. Please ask on a mailing list for help.

There is still useful software working only with 2.7. So it is not the time to drop this.

A page feed character is a very common and useful control character. In fact Emacs knows how to jump page by page.

A beta release is available as https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2 (https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2.sig).

How does it come that you have a Linux kernel without threads? Or maybe the better question is why does libc not support threads?

For 2.3.0 we won't be able to fix all bugs./feature requests. Instead we l will solve that in the 2.3 series.

Works for me.

dirmngr needs to be killed for this. gpgconf --kill dirmngr.

Meanwhile we introduced the keyboxd which should solve such problems. It will be marked experimental in 2.3 but I expect that it will soon be used as the default way to store keys - at least under Windows.

Won't be done because the expectations of users are different on whether they use ssh-agent or gpg-agent. And it breaks scripts

I would not all this an accident.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

We have the --unwrap option which already does this. The problem here is that an addition compression layer is not removed. Therefore I will rename this report to add a feature strip things down to a signature or literal data packet..

Eventually we will move to keyboxd which is already an experimental option in 2.3. Thus we won't do anything here.

The gpg-card is more flexible than the old gpg stuff. If there is something missing we will add it over time but it does not make sense to keep this request open.

Due to better working timeouts we have mostly soolved these problems,. Further keyservers are not anymore of great use these days.

The other patches don't make sense because of future plans for dirmngr.

Critical attributes are well known from CMS and X.509 and some have a history which can only be described as cargo cult. We should not allow them in the OpenPGP ecosystem without giving them a specific semantic aside from "we do something with it".

Done. FWIW. in 2.3 symcryptrun will be removed entirely.

We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.

Without any defined semantic it is not proper to ignore a critical bit. The software which created this keyblock seems to aim for incompatibility.

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thanks for the fix.

Actually I would be in favor of removing this portable thingy. It is and will always be the worst and most insecure way of using crypto.

Oh well, a bit surprising but I agree that it works :-)

Actually I can't see why this is only a problem in the NULL case. if you select a specific config item the string might also not be 0 terminated - it depends a bit on the size of the used buffers. In 1.8 I applied this with the the if (!what) condidion.

The problem persists when using keyboxd which returns keys in a different order.

I mentioned it several times: It is not sufficient to use some wmain as long as we don't rework the entire spawn machinery in gnupg. libassuan and gpgme. Reading Unicode from the command line would be easy the other things are the real work.

And in fact it was never possible to use 8bit filenames on the command line. The result was not stable and led to non-compatible messages due to the use of native character set instead of proper utf-8. It depended on just too much things.
gpgme-tool or gpgme-json might be useful workaround.

You can use --multifile for this. This reads the filenames from a descriptor or a file. One on the reasons to implement Unicode handling at most places was a request to allow using --multifile as a workaound for the command line limitation..

Please do not repeat you question, this won't give you anymore attention. Read my comment above and please ask on a mailing list etc.