@werner, i don't understand your last remark. what "required computations" do you think the proposed patches are "moving" from the server to the client?

Oh, no worries! Just wanted to confirm, that's all.

I am about half way. Sorry for the slowness.

I've been wondering this also. I can start working on this.

Hello,
Is anyone working on this? Just want to confirm.

Last week:
Similar to werner, mostly focused on moving to the new office.

Last week:

• Moving to the new office
• Fixed a few GnuPG bugs
• Released 2.2.19

Todays topic from me:

• T4772: Release libgpg-error 1.37
• T4659: Release Pinentry-1.1.1
• T4294: Release Libgcrypt 1.9.0

Last week:

• Chasing a bug in: T4256: gpg-agent: Spurious pinentries for an already unlocked key when decryption OpenPGP in 10 threads
  • If gpg-agent's option auto-expand-secmem can dismiss the pinentry pop-up, my analysis is correct
  • fundamentally, the total fix may be possible by serializing cryptographic operations
    • simple way is only one operation at most
    • ideally, multiple operations at once by measuring amount of available resource
• scan the tasks: Mostly for pinentry and libgpg-error to consolidate common things
  • those are not high priority, though
• confirmed that: on GD32VF103
  • USART and SPI are as same as GD32F103/STM32F103
  • USB is different, it's like STM32F105

This week:

• scan the tasks
• write an invoice to g10code
• considering a proposal (2020) to Purism
  • Fully Free (PCB design, firmware) USB Keyboard
  • If it is OK, use of GD32VF103 (RISC-V) would be good

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

@werner Could you please give an update on this? Is there any blocker? Is something missing, which prevents merging (and releasing) this?

In T1287#94619, @werner wrote:

2.1 has the option --unwrap to just this.

Release done.

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.

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: