Details
- Panel Type
- Query Panel
- Editable By
- rtatnet2 (Roufique hossain)
- Appears On
- rtatnet2's Dashboard
That sounds like you might have a different issue in mind?
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:
Todays topic from me:
Last week:
This week:
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.
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.