Done. Thanks.

You may want to use a recent version of GnuPG ;-)

UserIDs are mandatory and do not see any reason to change this except maybe by specialized application in the embedded field.

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.

it is just that we won't fix that for gpg 1.4.

This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.

We use "error ..." and "failed to ..." interchangable. The German translation even uses the same term for both.
Thus I think it would be better to keep the old diagnostic but show it only in --verbose mode.

See also D475.

auto key retrieve using just the key id is dangerous because it can lead to a DoS. It is too easy to flood keyservers with several keys have the same keyid. Let's don't give an incentive to the script kiddies trying to pull down the OpenPGP keyservers.

Please add

As I already stated: Please read the source comments on why we do this

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

Sorry, we can't replicate this with the current pinentry version.

"PLAINTEXT 75 ..." means UTF-8 encoding (u) which is not not binary (b) or MIME ('m') and thus on Unix the line endings are converted from CR,LF to LF. On Windows you should see a different length. See plaintext.c#handle_plaintext()

That is due to the mitigation for CVE-2019-14855. I need to see how to find a more specific mitigation.

Thanks for the report. I fixed this for the next 2.2 release and put a not in the source file to not translate the keyword.

So you mean we should take the signer's UID (which can be part of the signature) into account when displaying the user id? Right now we display the primary UID followed by _all_ other user IDs so that the verifier has an overview of the associated user ids.

I don't think that pointing to the bug entry form is a good idea: It will make it easier to enter a bug without first checking whether this bug has already been entered. I agree with the other comments.

Dehydrated problem after the last server update: https://github.com/FlorentCoppint/dehydrated/commit/aed6f4ba06858c926042b95f1cef4a7a681ddf88

Then better do not use a curses pinentry. It can't guarantee that another process changes the tty properties. For security reasons it is better to run the pinentry in a different window (ie. a GUI based pinentry).

Please no reports for non-released devel versions.

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

That seems to be gpg 1.4 which we do not fully support.

I also think this makes the most sense.

There are some problems with the definition of --locate-key. Further discussion required.

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.