Done for 2.2 and master.

Please no bug reports for the development branch. You need to have a recent libgpg-error. We do not update the requirements checked by configure for master immediately. It is better to report this to gnupg-devel if you are sure that you have the latest versions of all libraries.

Done. Thanks.

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.)

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

Here is my understanding:
--log-file option is valid for for background task like gpg-agent, dirmngr and scdaemon.
For gpg, it only works with --batch or --server.

This will be in 2.2.18, closing.

In my own opinion, it will be good when desktop environments support GnuPG as one of first class citizens, to protect user's data.
For example, currently, libscret stores secret data (such as WiFi shared secret, etc.) by its own cipher preference and method (and it is symmetric cipher by user's password). I don't think it is secure enough.
For me, it will be good if it is protected by user's gpg key using asymmetric crypto.

it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:

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.

Wow thanks for the great explanation! I've always wondered what is the relationship between gnupg and other secrets services. Personally, although Gnome's / KDE's secrets services offer better UX out of the box, I've always preferred gpg's agent because I can control it better from the command line and hence customize it's behavior. The only use I have for gnome-secrets service is for a few passwords I always want them to be cached (because I obtain them in systemd timers+services). Do you think Gnome / KDE will ever plan to _use_ gpg-agent, instead of reimplementing it?

Sorry in advance for long explanation. :-) Well, let me show my stand point at first (to avoid confusion): I don't like the concept of "desktop integration" when it makes difficult for a user to control his environment.

Works! I still wonder though: How come my system / gpg agent has all of a sudden started using the external cache? Is this a new feature of gpg-agent? And what is the meaning of this message:

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

Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

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.

This should be normal priority as we continue to receive bug reports about UIServer and the usage in GpgEX of the UIServer protocol keeps us from removing it in Kleopatra.

I did not want to move the fingerprint verification process more prominent with an entry field or something like that.

With the new version we get an even more extensive rework of the certify dialog. We now also have support for search tags.

It's probably a wrong encoding in the italian translation. Will be fixed with updating our build system to buster and NSIS-3

I removed it. Looks dead to me.

Is this resolved?

I tuned down the error message. I don't think there is a problem here anymore.

To clarify this for someone other then me:

After T4747 and T4748 are fixed this needs to be added to the installer, but sending Windowmessages is at least easy for NSIS. From the MSI installer this will be more difficult.