@werner Could you please give an update on this? Is there any blocker? Is something missing, which prevents merging (and releasing) this?
Fri, Dec 6
fwiw, ensuring that overflow for either field results in ULONG_MAX (rather than wrapping around) would go a long way toward this problem being something that we can reasonably put off for another 50 years.
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:
@gniibe Thank you!
In 2.2.18, this fix is not included. (partial fix was reverted)
Applied and pushed.
The last fix was in 3681ee7dc1e9d8c94fdb046d7be0bbcfeba1cfe9, on 2017-07-05.
And it is included from the release of 2.1.22.
Thu, Dec 5
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.
I think this is now resolved.
@gniibe - Thanks for your explanation. Is --pinentry-mode=loopback the same as specifying in ~/.gnupg/gpg-agent.conf: