@s7r Thanks for testing and letting us know!

Thanks Werner! Seems like an important step!

Thanks for the quick analysis.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

Last report more than two years ago.

--locate-external-keys exists since 2.2.17 and ignores the local keys.

On the ml there was another request for this use case

Read through it, thanks for the updated description!

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

Hello,
just reading the issue in detail.

Just reading this issue in detail.

@dkg while I agree with your aim of

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.

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.

How do I know that you've noticed?

@aheinecke thanks for commenting.

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

(Found while trying to answer a user question at http://wald.intevation.de/forum/forum.php?thread_id=2140&forum_id=21&group_id=11)

Okay, maybe this should just be added to the 2.2.x docs.

Thanks for your comments. It would have been cool if this restriction would have been noted
in the gpg options documentation. (Where is was missing at least where I was looking.)

Changed to Issue Tracker with 1d89f93b037d0f7cd084dbc7873f73134a8e1f1a.
@olf thanks for the hint.

@werner
It is good practive to open a public ticket for many projects, because otherwise the XMPP users don't know if the fact is already known, reported or being worked on. Alternatively: Let us document the procedure in public what someone should do, if the xmpp server ist down or the certificate is expired. What is that procedure?

As it ran out again before this issue got officially closed, I'll reopen it with an extended title.
Wasn't the idea to automate this somehow? >:)

Reading through this issue and the related documentation: Thanks for writing this all down and adding links!

Precondition: A list of pubkeys, as keyring or as keyring file with list of fingerprints.
Goal: a static file structure that can be uploaded on my webserver.
Platform: Windows, a better solution does require less additional dependencies apart from Gpg4win.

... that would be useful in many ways. I'd say we should support anyone who wants to use pythong-gnupg on windows.

@werner it is like @aheinecke writes:

Got the question about this note from a user (in a internal email) and I see the problem that users do not have enough information to decide this. They do not know what the consequences of this note are (and suspect it to be the cause of error of they see it together with other problems). So to me it is more than a 'wish' as it will generate questions and leaves users in a situation where they cannot progress by their own in most of the situations.

Hint from @gniibe: gpg --with-colons --list-config curve is a workaround.
So it still should be documented and made accessible from a non-esoteric, non-internal way. ;)

@dkg thanks for the link.

The use case that @Valodim and @dkg are thinking of probably is using a setup-code that humans use to transfer from one device do another to decrypt a symmetrically encrypted setup-package, this issue is linked from:

https://autocrypt.org/level1.html#setup-message-import

There was a second person asking for a list-packets feature to verify if a file is encrypted correctly at gnupg-devel.

Note that "Wrong name" severely misses information about that it is connection related in any way. :)
Just adding "Connection problem: TLS: " would already help a lot.

@werner sorry for asking again, I may be missing something: just saw that you've marked my comment for line 259 as "done". But in master and gnupg-2.2.5 I still see the sentence as
Export the private key and the certificate identified by @var{key-id} in using the PKCS#12 format. which does not pass my English parser. :)