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.

Please try with the latest GnuPG version (2.2.17) - it is unlikely that we can give support for an old version with Ubuntu's own set of patches. It is also advisable to post to the gnupg-users ML because over there you have hundreds of Ubuntu users.

See https://minerva.crocs.fi.muni.cz/ for a description of the timing attack.

See also apt-get show libpam-poldi

Also in another terminal?

Do you have

GPG_TTY=$(tty)
export GPG_TTY

if you run

You should always run gpg with --verbose if you run into an unknown error. It shows more information; in your case info about the requested pinentry. The strace does not show this. You probably have no permission to launch the X version opf the pinentry because the xauth does not work. As a quick test use ssh -X root@localhost instead.

Please provide a full description of what you did. What command line did you use, have you su-ed or logged in regular.? What is the output of "gpgcof --list-dirs" ?