We will need this for 1.9

Yes please.

Yes, its on my agenda.

Your welcome.

Fixed; In master the code already uses our generic scheme parser.

DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.

My FreeBSD box is currently not up, so I can't test right now. You may want to look into gnupg/common/utf8conv.c and there set_native_charset(). For historical reasons we start off with latin-1 but then swicth to the selected charset and intialize iconv accordingly. In the case of an error we sometimes fallback to utf-8. You may want to add some debug code (log_debug ("foo bar string=%s\n", some_string);)

OpenPGP specifies the use of UTF-8 for all meta data (ie. everything except for the signed/encrypted data). GnuPG has always supported this. I don't known on which OS you are but some don't have UTF-8 support on the command line or tty so you need to tweak your environment first.

I don't know about macOS but the commonly used GNU tools state:

What do you mean by grep_options?

estream_t does not necessary work with stdio or posix calls; that is an implementation detail. For example if you use the mode flag "nonblock" Read/WriteFile are used on Windows.

You may start the gpg-agent by hand:

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?

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.

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.

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

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:

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

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.

AFAIK, Stephan evaluated it only for x86, let me ask him ...

We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.

Done.

Let's wait with this until we ship a libgpgrt. I am not sure what the best way to migrate to another library name. By current idea is start with some release installing two libraries using the two names but with identical code. Some releases later we could require a configure option to install libgpg-error in addition to libgpgrt.

Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.