Bug 847004

Summary:	net-proxy/torsocks-2.3.0 fails to resolve domain names where IPv6 is available
Product:	Gentoo Linux	Reporter:	ytrezq
Component:	Current packages	Assignee:	No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status:	UNCONFIRMED ---
Severity:	major	CC:	jstein, ytrezq
Priority:	High
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
Package list:		Runtime testing required:	---

Description ytrezq 2022-05-22 17:56:56 UTC

Simple step to reproduce if tor is connected to an exit node supporting ɪᴘv6 :

$ 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 than with ɪᴘv4. 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.