Figuring out the matching user id for a new key signature. Right, --import-options repair-key is the the default and does the same. However, it was also the major cause for the recent trouble with the keyservers because it tried to verify all signatures. repair-keys was made the default (T2236) because it seemed to be nearly for free - which was a false assumption. We should not use this option by default and only consider properly placed signathures as valid. This of course also means that a userid is required.

@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: