I see no reason to move required computations from the server to the client.

Release done.

I found a solution for master and 2.1.19 which minimizes the risk of regressions:

In case you use gpgme we have a flag which can be queried to see whether a redraw is required:

allow-loopback-pinentry in gpg-agent.conf is actually the default. This options advises gpg-agent to accept a request for a loopback-pinentry. If you would configure no-allow-loopback-pinentry, requests from gpg to use a loopback pinentry are rejected.

That is actually a GnuPG thing. We originally did it this way to help people remember their passphrase before they start using the key. I agree it is annoying and I would like to remove it too. At the same time we should really think about making no-passphrase the default and require it only with certain compliance settings.

Fixed for 2.2.19 and master

CMS signatures do not have a expiration time. Further the meaning of the expiration time of one of the certificates also depends on the validation model (shell or chain); thus a one-to-one relationship between these times is not possible.

We will run into all kind of problems after 2038 on 32 bit boxes. 2106 is nothing to care about.

Thank you.

This is a support question. Please use one of the public support channels as listed at gnupg.org or ask for a quote at a commercial service (https://gnupg.org/service.html).

Regression due to a faulty backport. Fixed in repo; patch is F1052802
Thanks for reporting.

There is a regression in decryption with hidden recipients; see T4762.
Patch available

Okay, I can replicate that on gnupg 2.2; it works correct on master.

I am not sure what you want you are going. I see is a verify command using an unknown file or number of files without knowing its content (using globbing (*-SOMETHING) is not a good idea). Some signature is verified okay but it is not known whether the key is trustworthy. You export a ke and then you do a verify on the key - this can't work because a key-file is not a signature.

Sorry, a fix didn't made it into 2.2.18.

This is actually unused code and it will never be called with ERR == 0. Will fix it in master anway.

No bug.

The LDAP code is actually in very bad shape because @neal added it without utilizing the ldap wrapper and thus a timeout won't work reliable.

See T4760.

[ Please do not post each compiler warning as a single report. That is just just too much overhead and we do see such messages ourselves if you would provide a bit more information. ]

Unusable v6 interfaces are now detected on Windows and then not used.

The manual states that --standard-resolver is mostly for debugging. The reason you get an "not enabled" is that we can't allow direct DNS queries in Tor mode which would happen with the system (standard) DNS resolver.

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.