For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 24 2023
May 22 2023
Ok, it seems that my reproducer isn't correct after all. The user just confirmed that the SRV lookup succeeds on their system, so it seems GPG hits some loop repeating that for no apparent reason.
Feb 1 2021
In T4735#135315, @werner wrote:Shall we backport this to 2.2 which is our LTS release?
Nov 19 2020
The problem seems to have returned in 2.2.24.
Sep 1 2020
I can confirm that the patch seems to resolve the issue for me.
Aug 31 2020
Yes, I do have a signing key (that is distinct from the primary key, primary key I don't store on the smartcard).
Oct 31 2019
No. I mean to have an option for the caller to provide apparent UID in context to the --verify option, and have that influence the result. This is important for automated software that can't rely on user rechecking the result.
Oct 30 2019
Oct 25 2019
Ping.
Sep 26 2019
Mar 3 2019
Feb 20 2019
Feb 1 2018
This can easily be solved by adding two more cases to handle_send_request_error(): for GPG_ERR_EADDRNOTAVAIL (that's IPv6 disabled via procfs) and GPG_ERR_EAFNOSUPPORT (that's missing kernel support). Normally I'd submit a patch but I don't care enough to jump through all the hoops just to get two-line change in.
Oct 26 2013
Jun 13 2012
It seems that my patch does actually break gcc... i'm not sure how to handle
this correctly anyway. It seems that the problem is actually unsolvable, and
there's no correct way to mix inline functions and external assembly definitions.