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.

I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.

Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.

FYIL This is delayed because there are some dependencies to internals of gnupg.

Merged. Thanks.

Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.

Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:

Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time:

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .