- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 11 2019
Dec 10 2019
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.
Dec 9 2019
@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.
Dec 8 2019
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?
Dec 7 2019
In T1287#94619, @werner wrote:2.1 has the option --unwrap to just this.
Dec 6 2019
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.
Dec 5 2019
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: