simple step to reproduce : $ torify wget https://rpc.ethermine.org --2022-05-22 13:08:03-- https://rpc.ethermine.org/ Resolving rpc.ethermine.org (rpc.ethermine.org)... 1653217683 ERROR torsocks[669]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:701) failed: Non-recoverable failure in name resolution. wget: unable to resolve host address 'rpc.ethermine.org' Where the buffer is too small because the first returned address is longer. Disabling ɪᴘv6 doesn’t work because the issue happens at name resolution (where the returned ɪᴘv6 addresses are normally ignored). Of course wget supports socks proxies, but many python packages like websockets or aiohttp or web3py don’t and thus have to rely on torsocks for using tor. So there’s no workarounds : The problem is today ɪᴘv6 is far more available than it used to be… Not only do some websites like Google or Wikipedia provide ɪᴘv6 but many providers like Cloudflare provide ɪᴘv6 to all their protected websites. As a result, this prevents using torsocks with most of the web and might even make torsocks completely unusable in the future. I’m reporting it here as that specific part of the project seems to abandonware upstream.
This has been reported upstream (and in Debian) for a while https://gitlab.torproject.org/tpo/core/torsocks/-/issues/28627 / https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903 I don't think this qualifies as a fedora_prioritized_bug and I do think it must be fixed upstream. Upstream is not abandoned: https://gitlab.torproject.org/tpo/core/torsocks/-/releases/v2.4.0 There is also a valid use case for torsocks, that does not include IPv6 which is the usage against Onion Services. Meaning: While I agree that it would be great to get torsocks improved to support Ipv6 (which should happen upstream - and partially happened recently: https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40009) there are tons of other use cases that legitimate the existance of this package. I'll prepare a 2.4.0 release though soonish.
FEDORA-2022-a339f0f1e3 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a339f0f1e3
FEDORA-EPEL-2022-360a50c1f6 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-360a50c1f6
FEDORA-EPEL-2022-03ce6894db has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-03ce6894db
FEDORA-EPEL-2022-4370750911 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4370750911
FEDORA-2022-4e7d843da3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-4e7d843da3
FEDORA-2022-a339f0f1e3 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-a339f0f1e3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a339f0f1e3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-4e7d843da3 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-4e7d843da3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4e7d843da3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-03ce6894db has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-03ce6894db See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-4370750911 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4370750911 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-360a50c1f6 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-360a50c1f6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Ok, while not being abandonware, upstream lack the expected involvements level to see those kinds of bugs fixed which is why I think Fedora should maintain a separate patch. I do confirm the last update don t fix the issue. Tor .onion solving is possible through configuring tor as a socks proxy. But most python packages don t support proxies.
(In reply to ytrezq from comment #12) > Ok, while not being abandonware, upstream lack the expected involvements > level to see those kinds of bugs fixed which is why I think Fedora should > maintain a separate patch. Do you have such a patch? Did you try to submit it to upstream? Why isn't it merged upstream? Why should Fedora carry such a patch? And for how long?
I don t understand torsocks code well enough for being able to fix it. Even then their Gitlab is a permission based system where one can t create an account for posting on issues. As for how long Fedora should carry such patch, I would say maybe decades, as I don t see the bug being fixed upstream with the slowed pace of development of Torsocks.
In today's Prioritized Bugs meeting[1], we decided to reject this as a prioritized bug. We encourage you to work with upstream on this. As a general rule, Fedora does not want our packages to become long-lived forks. This is particularly important for security-sensitive software, where patches can introduce problems we might not fully understand. [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2022-06-01/fedora_prioritized_bugs_and_issues.2022-06-01-14.03.log.html#l-64
Talking to upstream is permission based, and I don t have the permission to do anything on their GitLab. This is why I opened this issue here instead. This bug is completely blocking programs like youtube-dl Fedora rpm from accessing tor. Because of Cloudflare, it is most websites which are now incompatible with torsocks.
FEDORA-EPEL-2022-4370750911 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-a339f0f1e3 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-03ce6894db has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-360a50c1f6 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-4e7d843da3 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.